From prototype to production

A text-to-app prototype proves that an idea can work. Production means it keeps working: for strangers, under load, when something fails, and after the next change. The distance between the two is a known list of engineering tasks, and AI can do most of them, but none of them happen unless someone asks.

Work through the list in order. The early items make the later ones possible.

1. Get the code into a repository you control

Before anything else, export the project or connect it to GitHub, clone it, and confirm it runs on your own machine. Until that works you have a subscription, and no codebase of your own.

Check what did not come with the export. The database, sign-in service, file storage and environment variables often live on the builder’s platform. List each one and decide whether to keep paying for it there or move it.

2. Lock down who can read and write what

This is the most common serious flaw in generated apps. A prototype usually lets any signed-in user, and sometimes anyone at all, read or change any row.

• Every table or collection needs an explicit rule for who can read and who can write. If your database supports row-level security, as Postgres does, turn it on and write a policy for each table.
• Enforce rules on the server. A check that exists only in browser code is a suggestion.
• Test it the blunt way: sign in as one user and try to load another user’s data by changing an ID in the URL.

The OWASP Top 10 has ranked broken access control as the number-one web application risk since 2021.

3. Move secrets out of the code

Search the code for API keys, tokens and passwords. Anything shipped to the browser is public. Secrets belong in environment variables on the server. Any key that has ever been committed should be revoked and reissued, not just deleted, because Git keeps history.

4. Add tests around the core flow

You do not need full coverage. You need the three or four paths that would cost money or trust if they broke: sign up, the main action, payment, and deletion. End-to-end tests that click through the real app catch the most for the least effort.

Tests matter more with AI in the loop. They are how a model finds out that its latest change broke something. Without them, you are the test suite.

5. Make deploys boring

• A staging environment that mirrors production.
• Automatic checks on every change: build, type-check, tests.
• Database changes as versioned migrations, never hand edits.
• A way to roll back.
• Error tracking, so you hear about failures before your users tell you.

6. Handle the unhappy paths

Go through each screen and ask what happens with no data, with a thousand rows, with a slow connection, with a double-click, and with the back button. Prototypes are built for the demo path, and users will take every other one.

7. Decide who does the work

Every item above can be written as a task and handed to a coding agent: “enable row-level security on every table and add a test that proves user A cannot read user B’s bookings”. Coding agents suit this stage well because the tasks are specific and checkable, and there are many of them.

The human job is to choose the tasks and review the results.

Our pick · we make it

For working through the list: run the tasks in parallel with Emdash

This is the stage Emdash, our product, is built for. Each item on the checklist becomes a task for a coding agent such as Claude Code or Codex. Emdash runs them side by side in isolated workspaces and gives you each result as a diff and a pull request to review. Emdash Classic, the desktop app, is free and open source; the cloud version for teams is in early access. You still need a model subscription or API key for the agents, and you still need to review what they produce.

See Emdash →

A realistic expectation

A focused prototype can be made production-ready in days, not months. The condition is that someone treats this list as real work. The failure pattern is skipping straight from “the preview looks right” to “launch”.

If you are still deciding which kind of tool to build on, start with AI app builders vs. coding agents.

Frequently asked questions

Is an app built with text-to-app AI safe to launch?

Not by default. Generated apps commonly have loose database access rules, missing input checks and secrets exposed to the browser. They can be made safe, but someone has to review access control, secrets and dependencies before launch, the same as with any other software.

When should I move off a hosted AI app builder?

Move when the platform starts deciding things for you, for example when you need an integration, a host or a compliance guarantee it does not offer, when the monthly allowance keeps running out during debugging, or when more than one person needs to work on the app at the same time.

Do I have to rewrite the prototype?

Rarely all of it. The screens and flows usually survive. The parts that tend to be rewritten are data access rules, authentication, and anything tied to the builder's own backend services.