Intended Design · The meaning behind the code
The Intended Design holds what your application means. Code is what it produces.
People and AI agents change the Intended Design. The engine checks every change as a whole and produces ordinary code. The Intended Design states every element and every relationship, so they do not have to be inferred from the code.
What the application means: elements and relationships, checked as a whole.
What the Intended Design produces: ordinary code for your target stack that you can run anywhere.
What it is
One connected description of the application
The Intended Design is the application as people think about it: purposes, business concepts, rules and screens, and the links between them.
Written down, it holds the structure you draw in Studio and the behaviour you write in the language: business objects, forms, services, themes, roles, settings.
Elements are related to one another, so a form control is bound to a field, a button names the action it runs, and a permission protects an action.
The engine checks it, and everything else, including the code, is produced from it.
- enforced_at
- server
- ui_behavior
- Approve action disabled unless status = submitted
The same example as a graph: elements, and the relationships between them. Hover an element to see what it connects to.
The shape of every Intended Design
The shape of every Intended Design
This is what every application is made of: the types of element zAppDev knows, and the named relationships allowed between them. It is what the checks enforce and what an AI learns once.
Built from the platform’s own model files and documentation. Where a relationship is not yet confirmed, it is marked “Still to confirm”, never presented as fact.
One example, measured
The List control
In this example, the same list of orders was built two ways.
| In this example | Custom build | Native List control |
|---|---|---|
| What you write | A helper class, a row-building operation, 46 lines of logic, 8 view-model entries and 8 hand-written styles | A dataset and a list with four columns, and 24 lines of logic |
| What is produced for you | The list as written: 1,863 lines | The list, plus a server-side data source, saved views with sharing and download: 2,313 lines |
| Changing a column | Four places | One column |
| The rules and tests | Six tests pass | The same six tests pass, unchanged |
Choosing the standard control meant half the logic and no helper class, and the rules did not have to change. A custom layout is still possible when you need something the control cannot do.
Counts are for this one example, measured on the generated solution. The list features are generated, and we have not tested each one.
An example
Rename a field and see what happens
Rename Price to UnitPrice on a product, in an application with forms, a service and a report.
In a code base
- Search the files for Price.
- Decide which hits are the field and which are other things with the same name.
- Edit the class, the form, the service, the report and the tests.
- Build, and find out what was missed, including names inside strings.
In the Intended Design
- Ask where the field is used, with Find Usages.
- Rename it with Refactor, in one place.
- Validate. Anything still using the old name is reported by element.
- Build. The code is produced from the corrected Intended Design.
Illustrative. Find Usages and Refactor are in the context menu of an Intended Design in Studio.
A safety net
For every change AI makes
AI will do more of the work on your software. The Intended Design gives you somewhere to check and control it.
Validated first
The whole Intended Design is checked before a build, so an invalid change stops early and says which element is wrong.
Impact is a query
What uses this class? What would break if it changed? The Intended Design answers across forms, services and settings.
Reviewable history
Changes to the Intended Design are kept in Git, with update, commit and log in Studio. A deployment is made from committed Intended Designs.
Regenerate, do not patch
Generated files are rebuilt every time, so a fix belongs in the Intended Design and applies everywhere it matters.
Where code is the better choice
An Intended Design is not for everything
A novel algorithm, an unusual stack or performance-critical code is easier to write as plain code. zAppDev keeps that door open: logic is written in the language, and external libraries and custom libraries can be called from the Intended Design. The Intended Design carries what is structured and repeated, and code carries what is new.
Cost and speed
We believe working on an Intended Design costs less than working on a large code base. We have not measured it, so this page makes no claim about it.
Familiarity
AI knows common languages best. The application’s MCP server and the documentation give it the vocabulary of the Intended Design.
Reference book
The Intended Design in the agentic world
A short reference book on the role and purpose of the Intended Design: the concept, the comparison with working on a code base, the anatomy of an Intended Design, the agent’s workflow, governance, ownership and the limits. It includes a measurement we made and says what has not been measured. Draft 0.97, 17 pages.
In the agentic world, the Intended Design is the asset.
Ownership
You own the Intended Design and the code
The Intended Designs you create, the source code zAppDev produces from them, and your data are yours. You can download the Intended Designs and the generated solution at any time. The generated code is open and free to run anywhere.
See the Intended Design in Studio
Create a free account and open a template application to look at its Intended Design.
Create free account Read the documentation