From AI prototype to production app, step by step
An AI prototype proves the idea and the interface. A production app proves the data, the accounts, the security and the running costs. Getting from one to the other is a handover, not a button: list exactly what the prototype fakes, export it into a real codebase, put that under version control, and give a developer a written list of what's left. Here's that path from an Anticode app build to a Next.js project.
What the prototype is, and isn't
Anticode's app builds are written by the model as one HTML document and run in a strict sandbox: no network of any kind, no outside scripts, and no real accounts, multiplayer, live data, payments or AI inside the app. Anything that would need a server is simulated with sample data and labelled "Demo data". Data a visitor enters is saved in their own browser. Forms for contact, enquiries, bookings or a newsletter do reach you through Anticode's form pipeline.
That's right for testing whether people understand and want the thing. Going from AI prototype to production app starts with that same list: it's what production needs.
Step 1: write the simulation inventory
Click through every screen of the prototype and fill in a table like this. It becomes the developer's brief.
| Feature in the prototype | How it works now | What production needs |
|---|---|---|
| Sign in | Simulated, labelled demo | Real accounts, password reset, roles |
| Client list | Sample data, saved in the browser | A database table, shared across staff |
| Availability | Hard-coded times | Real calendar rules, maybe a calendar sync |
| Card payment | A fake checkout screen | A payment provider integration |
| Email reminders | Not present | Transactional email and a scheduler |
| Enquiry form | Real: reaches the owner | Keep, move to the app's own route |
Mark each row: must-have for launch, later, or drop. Most prototypes carry features nobody needs on day one.
Step 2: export the Next.js project
Anticode exports a standard Next.js (App Router) project in TypeScript, with Postgres through Prisma, validation with Zod, server routes for bookings, contact, newsletter and email sign-in, and an admin area with two-factor sign-in and roles. It also covers app builds: the app's markup becomes typed components, its own code runs in the browser as before, and its content and form sending come across. The export adds customer and staff roles, an audit log and Postgres row-level security, and sends email through Resend. There's no Anticode runtime in it.
Be clear about what that means: the export gives the developer real sign-in, a database, routes and an admin area to build on. The prototype's simulated parts are still simulated in the exported code until someone replaces them with real models and routes. The README covers running it on Neon, Supabase, Docker or Vercel.
Step 3: put it in GitHub
- Push from Anticode to a repository you choose. Anticode asks for a separate GitHub permission (the
repogrant) for this, apart from signing in. - Make the repository private unless you mean to open-source it.
- Add the developer as a collaborator, and agree the branching and review rules before the first commit.
- Keep the project file. Anticode projects also have an open format,
anticode.json, with a public schema and an AGENTS.md for coding agents, useful if you keep iterating on the design in Anticode.
Step 4: plan what the developer owns
- Replacing every simulated feature on the must-have list with real data models, routes and permissions.
- Hosting, environment variables and secrets, database backups and migrations.
- Integrations: payment provider, calendar, any third-party API.
- Error monitoring, logging and uptime alerts.
- Security review of the new code, tests, and a release process.
- Privacy and terms that match what the production app really does.
Ask for an estimate per row of your inventory rather than for "the app". It makes trade-offs visible: you may launch without reminders, or with payment links instead of in-app checkout.
Decisions to make early
- Keep designing in Anticode or not
- Once the developer changes the code, round-tripping design changes gets harder. Freeze the design before the export, or agree that design changes go to the developer.
- Hosting
- Managed platforms are quicker to start; a container on your own infrastructure gives more control. The README covers both routes.
- Who holds accounts
- The business, not the developer, should own the GitHub organisation, the hosting and the database accounts.
How you know it's production-ready
Every must-have row in the inventory is real and tested, no screen says "Demo data", backups have been restored once as a test, two-factor sign-in protects the admin area, and someone other than the developer has run through the main journey on a phone.
Limits
Anticode builds the prototype, exports the Next.js project and pushes it to GitHub. It doesn't host the exported app, replace simulated features, run your database or review the developer's code. See exporting to Next.js, the developer handoff workflow and the Next.js export feature.
Questions people ask
Is the exported app production-ready?
Its foundations are: sign-in, roles, a database, routes and an admin area. The prototype's simulated features still need a developer to make them real.
Can I export an app build, not just a website?
Yes. App builds export to the same Next.js template, with the app's code and content carried across.
Do I need Anticode to run the exported app?
No. There's no Anticode runtime in the export; host it wherever suits you.