You shipped a prototype with Lovable, Claude, Cursor, or Bolt. Customers can use it. The build works. You are now in the gap between working and production, and the gap is bigger than the AI tool advertised. This is the day-by- day playbook we walk our customers through. Thirty working days. Most builds finish faster. None should take meaningfully longer.
A prototype is built. A production system is decided. The work is the deciding.
Week 1, the readiness audit
Before you fix anything, you have to know what’s wrong. A senior engineer reads the codebase end-to-end and writes a readiness audit. The audit is not a code review. It is a list, in priority order, of every issue that would prevent the build from being a production system. Most builds, in our experience, have between fifteen and forty findings.
Day 1.Read the codebase. Take notes; don’t fix.
Day 2. Map data flows. Where does production data come from, where does it go, what touches it. AI-generated code often has surprises here.
Day 3. Run the smallest plausible test of the unhappy paths. What happens when the API is down? When auth fails? When the database is slow? Note what breaks in interesting ways.
Day 4. Write the audit. Categorize: must-fix-before- production, should-fix-soon, can-wait. The first category should be small and ruthless.
Day 5.Review with the founder or product lead. Get explicit alignment on the must-fix list. Cut anything that isn’t. Two hours.
Week 2, the security pass
AI-generated code is, on average, slightly worse on security than human code at the same maturity level. The pattern is consistent: secrets in source, permissive CORS, missing rate-limits, weak input validation, occasionally a SQL pattern that should never see daylight.
Day 6. Sweep for secrets. Move every API key, password, and token out of source. Rotate the ones that lived in source. This is the single highest-value day of the playbook.
Day 7. Auth and identity. Confirm every endpoint either is intentionally public or requires authentication. AI tools love to default to permissive; close the gap.
Day 8.Input validation and rate limits. Every form, every API endpoint. The AI assumed clean input. Customers won’t provide it.
Day 9. Database access patterns. Look for queries built from user input via string concatenation. Replace with parameterization. This is rare in 2026 generations but not zero.
Day 10. Penetration self-test. Try to break the things you just fixed. If you can, fix again.
Week 3, the operational pass
AI-built systems often have no operational story. They were designed to run; they were not designed to run while a person sleeps. This week is about the difference.
Day 11. Logging. Every error path produces a log line. Every log line has enough context to be debugged later (request ID, user ID where applicable, the relevant input shape).
Day 12. Monitoring. At minimum: uptime check, error rate alarm, latency alarm. Wire to a real notification path; not email, ideally.
Day 13. Backups and restores. Backups exist; restores have been tested. AI-built systems sometimes have backups that have never been restored, which is the same as no backup.
Day 14. Configuration management. Every environment variable in every environment is accounted for. Production and staging are different in known, intentional ways.
Day 15.The runbook. One page. What does each alert mean? What’s the first thing to do when it fires? Who gets paged? Where’s the kill switch?
Week 4, the deployment pass
AI tools deploy. They deploy well. They deploy in a way that doesn’t survive contact with a real growth curve.
Day 16. Domain, DNS, TLS. Confirm certificate auto-renewal. Confirm DNS is pointed at infrastructure you control or trust.
Day 17. Deploy pipeline. Every shipping path goes through a single, observable, revertible mechanism. Vibe-deploys (push a button, hope) are the source of most weekend incidents.
Day 18. Rollback procedure. Test it. Verify the rollback actually returns the system to a known-good state in under five minutes.
Day 19. Performance baseline. Synthetic load test, even a small one. Now you know the cliff.
Day 20. Cost ceiling. Set hard limits on the bills that can run away, cloud, AI APIs, third-party services. AI tools love to enable elastic billing; production wants ceilings.
Week 5, the documentation pass
The system has to be operable by the second engineer. Often the second engineer is six-month-future-you, who has forgotten what the first engineer (current you, with the AI) decided.
Day 21. Architecture overview. One diagram, one page. What talks to what. Where the data lives. What the choices were and why.
Day 22. README that runs. Clone, install, run, deploy. Every command works on a clean machine.
Day 23. Decision log. What did we choose, what did we reject, why. Three sentences per decision. Six months from now, this saves a week.
Day 24. Critical paths walkthrough. The two or three flows the customer cares most about, with the code paths annotated.
Day 25. Test coverage. Not 100%. The unhappy paths and the money paths. AI tools generate tests that test what is easy to test; the work is filling the gap.
Week 6, the customer pass
The system is technically ready. Now it has to survive customers.
Day 26. Onboarding flow. New customer signs up; what happens. Walk it. Time it. Note every place that breaks emotional momentum.
Day 27. Error messages. Read every error path. AI tools write error messages for engineers; customers want messages for customers.
Day 28.Support path. When a customer is stuck, what do they do? If the answer is “email founder@,” that’s fine for the first hundred. Plan the second hundred.
Day 29.Privacy and terms. The legal pages exist. They say what they need to say. They’ve been read by the person responsible for them.
Day 30. Soft launch. Five real customers. Watch everything that happens. Fix the most embarrassing thing before the next five.
The day-31 question
Who owns this? The system is now real, and it will keep breaking, slowly, in ways AI tools cannot predict. The day-31 question is whether you have an engineer (in-house, on contract, on press) who knows this codebase and can pick up the next incident.
Three honest answers. One:in-house, you. Works for small builds; doesn’t scale past one. Two: in-house, a hire. Works once you have ten things that need an engineer. Three: on-demand, the press. Works for the in-between, which is most of where AI-built systems live.
Pick the one that fits. Decide on day 31, not day 60. The answer compounds.