PostgreSQL database
Schema, relationships, records, and query shape generated from the approved spec.
features
One specification. A full software stack generated from it.
Metatable turns business requirements into a structured spec, then generates the database, backend, frontend, deployment path, and exportable source code from that source of truth.
specification.prd source of truth
Inventory Operations App
roles
Owner, warehouse manager, purchasing editor, read-only accountant.
records
SKU, warehouse, supplier, purchase order, stock movement, reorder rule.
rule: create purchase order when stock falls below threshold.
permission: only owners approve supplier changes.
01 · source of truth
Start with the spec, not a prompt trail.
Roles, records, workflows, permissions, and edge cases live in a reviewable specification before code is generated. The spec is readable by the business, not only by developers.
Product Requirements Document approved
1. Product overview
Replace spreadsheet-based vendor tracking with a running application.
2. Primary workflow
Capture request, assign owner, validate data, approve, report status.
3. Access rules
Editors update operational records. Owners manage users and approvals.
4. Edge cases
Duplicate supplier, expired contract, missing approver, delayed renewal.
02 · generated stack
The output is a real application stack.
Metatable does not stop at screens. It generates the application structure around a real database, backend, frontend, deployment path, and exportable code.
Rust backend
Typed APIs, business logic, auth paths, and deployment validation.
Flutter frontend
Generated interface for the workflows, records, and roles in the spec.
Deployment path
A running application path with source export when you need to move it.
03 · the engineering that makes it reliable
Why the generated code actually runs.
Turning a spec into working software is not one prompt. It is a pipeline that orders the work, runs it against a real database and compiler, and fixes its own errors before you ever see the build.
Context engineering
Only the relevant spec, schema, and dependencies are fed to the model at each step, so output quality holds up as the project grows instead of degrading in a long prompt.
DAG dependency ordering
Generation follows a dependency graph. Tables, APIs, and screens are built in an order that actually compiles, not whatever the model happens to emit first.
Execution-based validation
SQL is run against a real database engine and Rust is actually compiled. Errors are found by running the code, not guessed from static analysis.
Self-fixing loops
The system reads the real compiler and database errors, then fixes its own output and runs it again until the build holds.
04 · generated outputs
What you get after the build.
The build produces more than a demo. You get a set of artifacts that make the application easier to run, review, export, and improve.
release checklist v1 build package
- Structured PRD
- Database schema
- Backend APIs
- Frontend app
- Deployment status
- Source export
- Living documentation
05 · honest fit
Built for business software, not every possible app.
When you are ready to compare capacity, see pricing. If you want a fit check first, send us the workflow.
Best fit
CRMs, internal tools, inventory, portals, trackers, approval flows, and operational dashboards.
Use with review
Customer-facing workflows where the data model, permissions, and handoff matter more than visual novelty.
Not best yet
Highly custom consumer interfaces, games, or products where frontend polish is the main product.
Honest limit
Frontend generation is still maturing. The strongest fit today is structured business software.
start here
Have a workflow that should become software?
Start from the spec and see whether Metatable can turn it into a running application.