Technology · Real code, your stack
Real code on a real stack
No black box. The engine checks your Intended Design as a whole, then produces an ordinary application you can read, build and host yourself, with every service ready to be an MCP tool.
From description to repository
Intended Design
- Business objects
- Forms
- Services
- Logic
- Themes
The engine
- Validate the whole graph
- Optimise the Intended Design
- Produce for the target
Full-stack
- .NET and Angular
- Mobile (preview)
Ordinary code
- .NET
- Angular
- Database
The same Intended Design can be produced for a different target.
YourApp.Web/ Controllers/ ViewModels/ ClientApp/src/app/pages/ Locales/ Projects/Domain/ POCO/ BLL/ DAL/
If you know Sass or TypeScript
An engine for application architecture
You already know the idea. Describe things at a higher level, have them checked, and get ordinary output you can read.
Like Sass: a higher-level source
You describe the architecture once, without the repeated plumbing. It is produced as ordinary code, and a code map leads every produced method back to its source.
Like TypeScript: a layer of checking
The Intended Design is checked as a whole: element types and the relationships allowed between them. That check is what makes machine-written changes safer.
Like a build pipeline: phases and targets
Check the graph, optimise it, then produce for a target. Each target is a program, and you can write your own.
The checks cover structure, not meaning: validation finds broken relationships, not wrong business rules, so tests still matter.
Architecture
From Intended Design to deployment
Intended Design
The source of truth. Structure drawn in Studio, behaviour written in the language.
The engine
Checks the whole Intended Design, optimises it, then produces the code for the chosen target. A target is a program that encodes the knowledge for one stack. Same Intended Design, different target. Learn more →
The stack
What gets produced
| Concern | Technology | Notes |
|---|---|---|
| Logic | The language | One language for all behaviour, produced as C# |
| Server | .NET | Controllers, business layer, data access |
| Client | Angular, TypeScript | Modern components and routing |
| Data | SQL Server | Schema produced from your objects |
| Interfaces | Exposed: REST, MCP. Consumed: REST, SOAP, GraphQL, databases, messaging | Exposed services and API adapters. A Postman collection can be downloaded. |
| Security | Forms authentication, roles, permissions | Password policy, per-action permissions |
| Delivery | Git or file-system deployment | Every deployment is a numbered version you can download |
| Quality | Unit tests you write in the language | Run in Studio and in your pipeline |
Versions follow the current release. Check the documentation for exact framework versions.
Security
Permissions in the Intended Design
Roles and permissions are part of the Intended Design. Every action can require a permission, and the produced code enforces it on the server.
Intended Design in, files out
Where each element type ends up
For the full-stack target (.NET and Angular), each kind of element produces a recognisable part of the solution.
| Element type | Produces |
|---|---|
| Business objects | Domain classes, business logic and data access, plus the matching Angular domain types |
| Forms | Controllers, view models, the Angular page for each screen, and resource files |
| Services | Exposed service projects and their controllers. MCP services become MCP tools in the generated application |
| API adapters | Client code for the systems you call and the structures they exchange |
| Automation flows | Workflow code, with schedules registered at start-up |
| Reports | Report classes that render the designed document |
| Data mappings | Transformation code between the left and right structures |
| Configuration | Roles and permissions seeded into the database, plus settings |
Traceability
From a stack trace back to the Intended Design
A code map links every generated method to the operation in the Intended Design it came from, line by line. When something fails in production, you land on the element in the Intended Design, not on a file you must reverse-engineer. A hash for each generated file also shows whether anyone edited it.
The Intended Design is the source
Generated files are overwritten on every build, so changes belong in the Intended Design.
The code is open
You can read it, build it and host it, and a person who prefers code can still review it.
Look inside before you commit
Create a free account, build the template, and open the code in your own editor.
Create free account Read the documentation