Specs before code
The business should understand what will be built before generation starts.
about metatable
We are building software generation for people who cannot safely judge code.
Metatable exists because prompt-based app builders made software feel easy to start, but hard to trust. We use specs as the source of truth so business owners can review what matters before code is generated.
prompt
"Build a supplier tracking app for our team."
spec
Roles, records, permissions, workflow states, edge cases, deployment needs.
generated stack
PostgreSQL, Rust backend, Flutter frontend, deployment path, exportable code.
01 · why we exist
The hard part was never typing the prompt.
Starting a software project with AI is easy now. The problem is knowing whether the result is complete, safe, maintainable, and aligned with how the business actually works.
That problem is sharper for non-technical owners. They can describe the workflow, but they cannot safely review a generated codebase. They need an artifact they can read before they trust the generated system.
For us, that artifact is the specification. It carries the business logic, then code is generated from it.
02 · our point of view
Software should have a source of truth a business can read.
Generated stack, not snippets
Database, backend, frontend, deployment path, and documentation need to stay connected.
Owned code, not lock-in
The output should be useful inside Metatable and exportable when the business needs it.
Focused stack
A narrower stack is easier to validate, ship, and explain than a broad set of half-connected choices.
Honest limits
Frontend generation and iteration are still maturing. That should be clear before anyone trusts the product.
03 · who we build for
For owners, operators, and builders who need working software.
Metatable is strongest when the project has real records, rules, roles, and operational consequences.
AudienceWhat they needWhat usually breaksWhat Metatable gives them
SMB business owners Custom software without building a full dev team. Scattered workflows, vendor risk, and unclear handoff. A readable spec, generated stack, deployment path, and exportable code.
Solo and micro-business owners A way to turn the process in their head into working software. Prompt tools get close, then break when the app becomes real. A structured path from requirements to an app they can run.
Freelancers and small agencies Professional client deliverables without prompt archaeology. Hard-to-maintain generated code and weak documentation. A spec clients can review plus source they can hand off.
04 · what we are building toward
A deployed app, not a tool you have to operate.
The goal is not to hand you another tool to learn. It is to give you a running, owned application that came from a spec you can read. You describe how the business works, and the outcome is software you can actually deploy and keep.
The spec is the operating document underneath that outcome. It connects your requirements to generated code, deployment, and handoff, so the app stays maintainable instead of becoming a thing only its author understands.
For how the generation works, see the features page and the how it works walkthrough. If you want to discuss fit, contact the team.
05 · proof we can say today
Field notes, not inflated claims.
These are the proof points we can say today without turning the page into theatre.
4,000+ registered users
5,000+ projects created
95% database generation success
72% backend deploy success, October 2025 funnel, 13 of 18 builds
start here
Bring the workflow. We will help turn it into a spec.
Start free, or book a short demo if you want to talk through the project first.