How do you take a vibe-coded app to production?
To take a vibe-coded app to production, add the layer your AI coding tool did not build because nobody asked for it: secrets kept on the server, authorisation on every request, a deployment you can repeat and undo, health checks and alerts, limits on anything that costs money, and tests around the flows people depend on. Work in order of what can hurt you first: security and recovery before launch, visibility and cost in the first month, capacity and structure as usage grows.
What changes when strangers start using it
The preface of From Model to Product starts where many builders now are: open Cursor, VS Code with Copilot or another coding assistant, and a prototype runs within hours. Then it names the catch. A prototype that works once is the easy part; keeping it working is the real job.
Chapter 1, The AI Product Mindset, separates exploratory work from production work. Exploratory work optimises for learning, fast experiments and interesting demos, and AI coding tools have made it faster than it has ever been. Production work optimises for user value, reliability and sustainable operation. A production system has to earn trust again and again, handle ugly inputs and keep working when no one is watching closely.
For an app you built with AI tools, the shift is concrete. You were the only user; now strangers sign up, and a few will try things you never imagined. Test data becomes customer data you cannot lose. A bug becomes an incident someone reports while it is happening. Every call to a paid API is now a bill for someone else's usage. None of this means the code is bad. It means the app has moved to a world that asks different questions.
Why AI coding tools leave the same gaps
An AI coding tool writes what you ask for. What it rarely adds is what you did not ask for. A prompt such as ‘let users upload invoices and see a summary’ describes a feature on its happy path. It does not say who may see which invoice, what happens when the summary service times out, how to undo the next change if it breaks something, or who is told when the app fails at two in the morning. Those answers are not features, so they seldom appear in a feature request.
The preview hides the gap. It has one user, clean data, your own credentials and no traffic, so everything that depends on many users, hostile input or failure never runs. The app passes every check you can see and has never faced the ones you cannot.
Chapter 1 describes the same blind spot in people building AI products. Beginners picture three clean pieces, data, model and interface, and miss the operational layer underneath them. None of that layer is glamorous, and all of it matters the moment something goes wrong.
The encouraging part: the same tool will write most of this layer when you ask precisely. You need to know what to ask for, and in what order.
The hidden operational layer, translated for your app
Here is the chapter's list of what that layer contains, item by item, as it applies to an app built with AI tools. The third column is the triage: first what can hurt users or lose data on day one, then what lets you see trouble, then what lets you grow.
| Item | What it means for your app | When |
|---|---|---|
| Version control | Every change committed to a Git repository you own, so an AI edit that touched twenty files can be undone in one step | Before launch |
| Secret management | API keys and database credentials kept on the server in environment variables, never in browser code or the repository | Before launch |
| Environment configuration | Separate settings, and a separate database, for development and production, so experiments cannot touch real data | Before launch |
| Deployment processes | One repeatable way to ship, the same every time | Before launch |
| Rollback plans | A known way back to the previous version within minutes, and a database backup you have restored at least once | Before launch |
| Testing | Automated checks on sign-up, login, payment, permissions and the core action | Before launch, then growing |
| Health checks | An endpoint an uptime monitor can call to confirm the app and its database respond | First month |
| Alerting | A message to you when the app stops responding, errors rise or spend jumps | First month |
| Incident response | A short written plan: who looks, how to roll back, how to switch off a failing feature, what to tell users | First month |
| Retries | Timeouts on every external call, and retries with backoff only for calls that are safe to repeat | As you grow |
| Queueing | Slow work such as email, imports and long model calls moved out of the request into background jobs | As you grow |
| Scaling policies | Rules for adding capacity, which only work once the app keeps no state in server memory | As you grow |
| Service boundaries | Clear modules inside one app first; separate services only when a part needs different scaling, hardware or release cycles | As you grow |
Before launch: what to do this week
These protect your users' data and give you a way back. Most are small changes an AI tool can write if you ask precisely and check the result.
- Put the code in a Git repository you own and commit before every AI-generated change. Version control is your first rollback plan, and the one that saves you when an agent rewrites half the codebase in one turn.
- Find every secret. Search the client code and the repository history for API keys, tokens and database passwords, and move them to server-side environment variables. Anything the browser downloads can be read by anyone, so rotate every key that has ever shipped to a browser or been committed. What AI tools miss on security covers where else keys leak.
- Check authorisation on every endpoint that reads or changes data. Being logged in is not the same as being allowed. Sign in as two different users and try to open, edit and delete each other's records by changing an ID in the request; fix every attempt that succeeds.
- Cap anything that costs money per call. Add per-user rate limits to sign-up, login and every endpoint that calls a paid API such as a language model, and set a budget alert, plus a hard spending cap where your provider offers one.
- Validate input on the server. Check every request against a schema of the fields, types and sizes you expect, and reject the rest. Checks in the browser are a convenience, not a protection.
- Separate development from production. Give production its own database and its own keys, keep your AI tool's working environment pointed at development, and back up production in a way you have tested by restoring it.
- Make deployment repeatable and reversible: know exactly how a change reaches production and how to return to the previous version in minutes. Deploying a vibe-coded app properly covers environments, CI and leaving an AI app builder's hosting.
The first month: make problems visible
Chapter 1 calls observability the eyes and ears of the product: if you cannot tell whether latency is rising, failures are increasing or costs are drifting, you cannot operate responsibly. In the first weeks with real users, the aim is to hear about a problem from your monitoring before a customer tells you. Monitoring a vibe-coded app covers the layers to watch and how to alert without drowning in noise. Start with these.
- A health check endpoint that confirms the app and its database respond, polled by an uptime monitor.
- Error tracking that records the stack trace, the route and a request ID for every unhandled error.
- Alerts on the few signals that need action: the app is down, errors stay above their normal level for several minutes, or daily spend on a paid API passes a threshold you set.
- A daily look at usage-based bills for hosting, database and model APIs. They grow with users, and one runaway loop or abusive client can multiply them overnight.
- A test for each bug you fix, so the same fault cannot return unnoticed.
- A one-page incident plan: who is alerted, how to roll back, how to switch off a failing feature, and where to tell users what is happening.
As you grow: capacity and structure
Chapter 1 gives the classic example of what growth exposes: a usage spike raises response times, upstream callers start retrying, the retries add load, and timeouts spread until a system that looked healthy starts wobbling. Nothing in the code got worse. The architecture lacked operational resilience.
In an app built with AI tools, look for these four patterns. The first three work with one user and fail with many; why vibe-coded apps break with real users covers the fixes, from retries with backoff to queues, caching and load testing. The fourth slows you down rather than your users.
- External calls with no timeout, or retried immediately and without limit.
- State held in server memory or on local disk, such as sessions, uploads, rate-limit counters or job progress, which breaks when a second instance starts or the first one restarts.
- Slow work done inside the request, such as sending email, processing files or waiting for a long model response, which ties up the server while the user waits.
- Structure that makes every change slower and riskier than the last. Rewrite or refactor helps you decide whether to improve the code in place or replace part of it.
Readiness is a spectrum, not a launch day
Chapter 1 is explicit that production readiness is not binary. A system can be ready for one scale or use case and unready for another, so an app that is ready for fifty friendly beta users may not be ready for a public launch or a paying customer's whole team. Decide which level you need now, and do the work for that level.
Launch is not the finish line either: the operational layer is what lets you keep changing the app safely once people depend on it. For why AI projects in general stall between demo and production, see why AI projects fail to reach production.
This hidden layer is where mature engineering earns its value. It is how teams maintain control. It is how they recover from surprises. It is how they keep shipping without turning every release into a minor act of courage.
Questions
What is the operational layer of an app?
It is the part of an app that keeps it running safely rather than adding features: how it is deployed, configured and rolled back, where its secrets live, how failures are retried, detected and handled, and how it is tested and scaled. Users never see it, which is why it is so easy to skip.
Can an app built with AI coding tools be production ready?
Yes. Production readiness is a property of the running system, not of who or what typed the code: whether it protects data, handles failure, can be deployed and rolled back, and tells you when it is unhealthy. AI-written code can meet that bar once the operational layer is added and checked. It rarely meets it by default, because the prompts that produced it described features.
What should I fix first before launching a vibe-coded app?
Fix what can hurt users or lose data on day one: secrets in client code or the repository, missing authorisation checks, unlimited access to paid APIs, unvalidated input, a production database shared with development, and no way to roll back. Monitoring comes next, then capacity and code structure.
Can I keep using AI coding tools once the app has real users?
Yes, with guard rails. Work on a branch, commit before each change, read the diff before merging, run the tests and deploy to a staging environment before production. Keep production credentials out of the tool's environment, so an agent that runs a migration or a clean-up script can only touch development data.
Do I need an engineer before launching a vibe-coded app?
Not always. Bring in an experienced engineer for a review if the app handles payments, health records or other sensitive data, if customers will rely on it for their work, or if parts of the code do things you cannot explain. Ask them to start with authorisation, secrets, data storage and deployment.
What changes when a vibe-coded app calls a language model?
Two concerns are added. Model output can be wrong while sounding confident, so keep decisions in backend logic, validate what the model returns and have a safe response when it fails; see making LLM API calls reliable. And every call is billed, so route calls through your server with per-user limits; LLM cost per user shows how to estimate the bill.