An AI-assisted platform that turns natural-language business requirements into a complete, validated application specification—before any implementation code is written.
Beyond Prompt-to-Code: Intended Design
From Natural Language to Agent-Ready Applications by Design
Produce modern full-stack code for business applications ready for AI agents to use, with natural language translated into an explicit design, validated as a whole across data, logic and interface before any code is written. The design then directs the coding, so the code is consistent, ordinary, and yours to download, deploy and run anywhere.
Natural language
Described by a person or an
AI agent
Answered from the Intended Design illustrative
- LogicRule: only submitted orders may be approved
- DomainOrder.status: draft, submitted, approved
- UX/UIOrderDetail: Approve is disabled unless the status is submitted
- IntegrationApproveOrder: requires the Approver role
Found by asking the design, not by reading the code.
Target stack
The Intended Design did not change
Knowledge lives in the Intended Design. Implementations come and go.
The premise
The Problem
Prompt-to-code leaves design implicit
It also leaves consistency unchecked and coding undirected.
The Shift
Intended Design makes it explicit
It directs coding through explicit design and validated consistency.
Starting point
✕Natural language prompt
✓Structured business specification
Design decisions
✕Implicit, buried in code
✓Explicit and reviewable
Consistency checks
✕After code exists
✓Before any code is produced
Source of truth
✕Generated code
✓Validated specification
Agent reliability
✕High variance, drift common
✓Precise contract, low drift
Ownership & portability
✕Tied to generated implementation
✓Design-owned, stack-independent
Concept
What Intended Design actually is
The Intended Design is the application as people think about it: purposes, business concepts, rules and screens, and the links between them.
zAppDev
A bridge between business language and software engineering
You describe the application the way a domain expert would: the entities that matter, the rules that govern them, the roles that act on them, and the screens people need.
The platform translates that description into a structured, layered specification covering the database, the server-side logic, and the user interfaces. It then runs cross-layer consistency checks so that nothing is left implicit.
Only after the specification is complete and validated does code generation begin. The result is an agent-ready, line-of-business application you fully own and can run anywhere.
Intended Design
01Database Layer✓Schemas · Constraints · Relationships · Integrity
02Server Layer✓Business rules · APIs · Authorization · State
03Interface Layer✓Screens · Fields · Actions · Navigation
Cross-layer consistency checks · nothing left implicit
What defines an Intended Design
An Intended Design is…
- 01
Described in six views
Intent, domain, logic, interface, integration and data each have their own vocabulary.
- 02
Connected
Elements link across views, so you can always ask what depends on what, and why.
- 03
Modular
Change one view without rewriting the others. Swap the target stack and keep the Intended Design.
- 04
Strategic
The Intended Design carries purpose, so people and AI work against the goal, not just the syntax.
Platform
Where Intended Design happens
Studio is the browser workspace where the specification is created, checked and turned into code.
How the code is produced
The engine checks the whole Intended Design, then produces an ordinary application you can read, build and host yourself. AI helps you create the Intended Design; the engine checks it.
Describe
Intended Design
- Entities
- Rules
- Roles
- Screens
Check, then produce
The engine
- Checks the whole design across every layer
- Applies your architecture, with nothing inferred
- Produces the code for each layer
Your repository
Ordinary code
- .NET
- Angular
- Database
The code it produces
The same Intended Design can be produced for a different target.
- Full-stack.NET · AngularAvailable
- MobileExpo · React NativePreview
- Your ownAny stack you can describe
Process
How it works
Five deliberate steps from business language to agent-ready specification.
- 01
Describe the business
Speak in the language of your domain—entities, workflows, roles, rules, and screens. No need to invent technical architecture first.
“Add an approval step to orders.” - 02
Generate the layered specification
The system produces a structured design covering data schemas & constraints, backend logic & APIs, and user interfaces & interactions.
IntentDomainLogicUX/UIIntegrationData - 03
Validate across layers
Automated checks confirm every field has a data definition, every action has authorization and side effects, and business rules are enforceable at the correct layer.
Every field has a data definitionEvery action has authorizationRules enforceable at the right layer - 04
Review and refine
Inspect the complete design. Adjust where needed. Approve only when the specification matches the intended business outcome.
Approve✓ - 05
Generate with confidence
Hand the validated specification to coding agents or developers. They implement against a precise contract. The result remains faithful to the original intent.
.NETAngularDatabase
An excerpt of an Intended Design for an order system: an entity, a rule and a screen.
order-management.specification
// Excerpt from a validated Intended Design specification
Entity: Order
attributes:
- id: UUID (primary)
- status: Enum[draft, submitted, approved, fulfilled, cancelled]
- total: Decimal(10,2)
- customer: Ref(Customer)
Rule: Only submitted orders may be approved
enforced_at: server
ui_behavior: Approve action disabled unless status = submitted
Screen: OrderDetail
fields: [status, total, customer.name, lineItems]
actions: [Submit, Approve, Cancel] — gated by role + status
Entity: Order
attributes:
- id: UUID (primary)
- status: Enum[draft, submitted, approved, fulfilled, cancelled]
- total: Decimal(10,2)
- customer: Ref(Customer)
Rule: Only submitted orders may be approved
enforced_at: server
ui_behavior: Approve action disabled unless status = submitted
Screen: OrderDetail
fields: [status, total, customer.name, lineItems]
actions: [Submit, Approve, Cancel] — gated by role + status
A disciplined process that forces completeness and consistency before implementation
Intended Design is not a prompt template.
- 01
Structured Business Specification
Natural language is transformed into an explicit, machine-readable design that captures entities, attributes, relationships, constraints, workflows, roles, permissions, and screens.
- Every concept has a clear definition
- Ambiguity is resolved early
- The specification becomes the source of truth
- 02
Cross-Layer Validation
Before any code is produced, the platform verifies that the three layers are coherent with one another.
- Every UI field maps to a data definition
- Every action has defined authorization and side effects
- Business rules are enforceable at the correct layer
- State transitions and edge cases are explicit
- 03
Human Review Gate
The complete design is presented for inspection. You refine and approve only when the specification accurately reflects the intended business outcome.
- No silent assumptions
- Changes remain cheap
- Ownership stays with the team
- 04
Agent-Ready Output
The validated specification becomes a precise contract that coding agents (or developers) can implement against. Hallucination and architectural drift are dramatically reduced.
- Portable across stacks
- Regenerable at any time
- Durable source of truth
What gets checked before any code is written?
Every reference must resolve and every layer must agree. The checks cover structure and relationships.
✓Every reference exists
✓Every layer agrees
✕Screen uses a field that does not exist
Example: caught before any code is produced.
AI helps create it
Intended DesignOne specification
EntitiesRulesScreensPermissions
The
single source of truth. The code follows from it.
✓
Checkedevery reference
resolvesevery layer agrees
DatabaseServerScreensProduced as source code you own
The outcome
Full-stack applications with robust architecture and native agent compatibility
InterfaceServerDatabase
Full-stack
Database, server and interface produced together from one Intended Design.
Interface✓Server✓Database✓
Robust architecture
Your architecture applied to every element, and checked across every layer.
AI agentApplication services
Native agent compatibility
Every service can be used by AI agents, under the same rules and checks as a person.
Agent-ready
Applications that AI agents can use
Same rules and checks for agents as for people.
AI agents
Approve a request
Check a stock level
Raise an invoice
Examples
Agent-ready app
RequestsStockCustomersInvoices
Same rules and checks for everyone
People
Screens and forms
Dashboards
Reports
use servicesuse screens
Access is by a token scoped to one application and revocable at any time. Every change is checked before anything is produced.
AI and MCPDeployment
Run it anywhere
Each deployment is kept as a numbered version, and goes only from committed Intended Designs.
-
Cloud
Azure, AWS or any provider you already use.
-
On premises
Your servers, your network, your rules.
-
Containers
Standard builds you can package and orchestrate.
A clear way out. The runtime library is open and free, and your application runs
on your own servers with no call home to zAppDev. You can download the generated code and the Intended Design
files.
Technology overview
Benefits
What you get
Applications that are business-native, agent-ready, and truly owned.
-
Business-native
Specifications expressed in the language of your domain, not framework jargon.
-
Cross-layer consistency
Data, logic, and interface are proven coherent before a single line of code exists.
-
True ownership
The specification—not the generated code—is the primary artifact. Regenerate or retarget at any time.
-
Agent readiness
Downstream agents receive a complete, already-validated contract. Hallucination and drift drop dramatically.
-
Portability
Run the resulting applications anywhere. The design is independent of any particular cloud or framework.
-
Maintainability by design
Future changes start from the same clear source of truth instead of reverse-engineering opaque code.
Proof
Demonstrated on a real business application
491 screens, 3.6 million lines, built and checked as one.
Database Layer0business
entitiesSchemas · Constraints · Relationships · Integrity
Server Layer0operationsBusiness rules · APIs · Authorization ·
State
Interface Layer0screens
and formsScreens · Fields · Actions · Navigation
✓ Cross-layer validation0Mlines of code produced from the specification
Counted from one real application (build 801), excluding libraries and build output. The checks cover structure and relationships, so testing remains necessary.
See what an Intended Design looks likeAudience
Who it’s for
Teams building line-of-business applications that must remain correct, evolvable, and owned over years—not just demos that look good on day one.
Product leadersEngineering teamsDomain
expertsPlatform architectsOrganizations preparing for agents
Pricing
Start free. Grow when you are ready.
You pay for Studio. Running what you produce needs no paid zAppDev service.
Free
£0To learn and explore.
- Full Studio
- Template applications
- Community support
Popular
Personal
£55 / user / monthFor individual builders.
- Everything in Free
- Production builds
- Priority support
Professional
Contact usFor teams that build together.
- Everything in Personal
- Shared workspaces
- Roles and review
Enterprise
CustomFor large organisations.
- Everything in Professional
- Private deployment
- Dedicated support
The runtime library is open and free. Your application never depends on a paid service to run.
Questions
The short answers
What is Intended Design?
A formal description of what an application must do, written before any code exists and in a form that can be checked. The specification, not the prompt, is the source of truth.
How does this differ from prompt-to-code tools?
Prompt-to-code tools generate code first and leave verification to review and testing. zAppDev checks the design first and then produces the code from it.
Are developers still needed?
Yes. zAppDev does not replace engineers. Business experts and engineers work from one shared, checked description.
Does it replace testing?
No. The checks cover structure and relationships: that every reference resolves and the layers agree. They do not show that a business rule is correct, so automated and manual testing remain necessary.
Does the organisation own the code?
Yes. The code is ordinary and readable. It can be downloaded, kept in your own repository and run on your own servers.
zAppDevIntended Designdescribe it,
produce it, own it
White paper
Take the whole story with you
A white paper on the approach and the tools: why AI needs a checked specification, the programming language, and the engine that produces your code. Written for technical decision-makers and developers.
Version 1.0, October 2026. PDF, A4.
Specify first.
Validate before coding.
Build for the agentic era.
The applications that last will not be the ones generated fastest from a prompt. They will be the ones whose design was made explicit, checked, and owned from the beginning.
Begin with your first specification