Is Your AI-Built App Production Ready? The 12-Point Check (Score It in 20 Minutes)
Twelve checks a founder can run on a Lovable, Bolt, Replit, v0 or Bubble app with a second account and no engineer, what each failure means, a score that says harden, take over or rebuild, and what each route costs at KUMO's published bands.
Oct 27, 2026
An app built with Lovable, Bolt, Replit, v0 or Bubble is production ready when a second user cannot see the first user's data, no secret ships to the browser, the database enforces who may do what, the schema survives growth, every money path has a test, and a bad change can be rolled back in ten minutes. Those are six of the twelve checks below; a founder can run all twelve in about twenty minutes with a second account and no engineer. The score tells you which of three jobs you are buying: hardening (from $15,000, 4 to 6 weeks), a takeover ($20,000 to $50,000, 8 to 12 weeks) or a rebuild of the core ($50,000 to $100,000). Most apps with real users need the first; the dangerous ones are the apps that look fine because nobody has run check 1.
Key facts (updated 26 October 2026; Lovable product details read 2 October 2026 from lovable.dev and docs.lovable.dev)
- 12 checks, each pass or fail, no tools needed beyond a second login and your backend dashboard
- Three or more failures: hardening; six or more, or any failure on checks 1 to 3 with real customer data: takeover; a no on check 12's follow-up question: rebuild
- The builders can host production apps (Lovable states SOC 2 Type 2 and ISO 27001 for its infrastructure); readiness is a property of your app, not of the host
- KUMO bands: hardening $15,000 to $30,000; takeover $20,000 to $50,000; core rebuild $50,000 to $100,000; ongoing engineering $5,000 to $10,000 per month if you have no engineers
- Send your score and three lines about the app and get a scoped estimate in two working days
Who this is for
A founder or owner whose AI-built app has paying users, a signed customer, or an investor asking who maintains it, and who wants to know whether the app is safe before someone else finds out. If you have an engineer, hand them this list; they will finish it faster. If you do not, run it yourself; the checks are written for that.
The 12 checks
Use a second account that is not an admin. Write pass or fail next to each.
1. Data isolation. Log in as user B. Open user A's record by changing the id in the URL or the API call. Pass only if you get an error. This is the check that produces the incident customers write about.
2. Secrets in the browser. On the live site, view the page source and the network calls; search for "key", "secret", "token" and "sk_". Pass only if nothing that unlocks payments, email or a model is visible.
3. Authorisation at the data layer. As user B, call an admin action directly (the API route, not the button). Pass only if the server refuses, regardless of what the screen shows.
4. Schema shape. Open the tables. Fail if money or quantities are stored as text or floating-point numbers, if there are no foreign keys, or if one table holds what should be three.
5. Uniqueness. Create two records with the same email or order number. Pass only if the second is rejected.
6. Tests on the money paths. Ask whether sign-up, payment and the core job have automated tests that run on every change. Fail if the answer is "we test by hand".
7. Integrations are real. Find where the CRM, email or payment sync happens. Pass only if it runs on a server function you can see logs for, not from the browser and not as a placeholder.
8. Uploads. Upload a 200 MB file and a file with a .exe extension to any upload field. Pass only if both are refused.
9. Cost per user. Open the backend and model billing pages. Fail if cost grew faster than users over the last 30 days or if a model is called on every keystroke.
10. Audit trail. Ask who changed a specific customer record and when. Pass only if there is a log that answers without reading email.
11. Rollback. Can you deploy the previous version in under ten minutes without the builder's chat? Pass only if someone has done it.
12. Ownership. Are the repository, the backend project, the domain and the payment account in an account your company controls? Fail if any lives in a personal or a contractor's account. Follow-up question for the rebuild decision: can the current data model carry the next customer (multi-tenant, payments at volume, a partner portal, compliance)? If the honest answer is no, the score does not matter.
What the score means
| Score | What it is | What to buy | KUMO band | Time |
|---|---|---|---|---|
| 0 to 2 failures, none on 1 to 3 | Healthy for its stage | Nothing yet; re-run the checks after every big change | none | |
| 3 to 5 failures | Normal for an AI-built app with users | Hardening: fix the failures, add tests on the money paths, a deploy pipeline and a readiness report; keep building in the builder if you want | $15,000 to $30,000 | 4 to 6 weeks |
| 6 or more, or any failure on 1 to 3 with real customer data | The code cannot be trusted | Takeover: hardening plus schema migration, real integrations, monitoring, handover of a repository you own | $20,000 to $50,000 | 8 to 12 weeks |
| "No" to the check 12 follow-up | The architecture cannot carry the next customer | Rebuild of the core, reusing the validated product and the UI where it is good | $50,000 to $100,000 | 12 to 20 weeks |
Want the number for your own scope? Send a short brief: what takes your team the most manual time, which systems are involved, roughly how many people touch it. A senior engineer replies within two working days with a band and the questions we would ask on a call. No call needed. Or get a range in a minute from the AI development cost calculator.
The honest order is hardening first, because it is cheaper and it tells you whether the other two are needed. The Lovable takeover guide walks through what breaks first and what a takeover keeps and rebuilds.
What each route includes and what sits on top
Included in every route: the readiness review on your real app, a written keep-and-rebuild list, the work, tests on real flows, a runbook, and handover of code, infrastructure access and documentation to an account you control. On top: the builder and backend bills you already pay, model usage if the app calls one, and ongoing engineering at $5,000 to $10,000 per month if nobody in-house owns the code after launch.
Proof, labelled
KUMO has not published a takeover case study yet, so the proof here is adjacent and specific to production builds: FLIN is a mobile credit app built for regulated workflows from scoped brief to launch; Equipp is a production rental platform with auditable ledgers; CampaignHQ is KUMO's own product, in production since 2022, where the deploy, test and monitoring patterns run first. KUMO's founders built Volopay's first production version as its founding engineers, a finance product where every approval and every payment had to be traceable. KUMO is a software engineering studio that builds custom AI agents, workflow apps and portals for 10 to 100 person companies, and a Registered Partner in the OpenAI Partner Network.
Questions founders ask
Is a Lovable or Bolt app production ready out of the box? The hosting is; the generated app usually is not. Row-level security, secrets, auth at the data layer, schema and tests are the five places it fails first, which is why checks 1 to 6 come first.
How much does it cost to make an AI-built app production ready? $15,000 to $30,000 for hardening when the product is right and the five failures are the problem; $20,000 to $50,000 for a takeover with handover; $50,000 to $100,000 when the core has to be rebuilt.
Can I run these checks without an engineer? Yes. Each check needs a second login, the backend dashboard, or a question to whoever built it. Checks 1, 2, 3, 5, 8 and 11 take two minutes each.
Do we have to leave the builder? Not for hardening. A takeover moves the code to a repository you own and the builder becomes optional; a rebuild replaces the generated core.
What if we fail check 1 right now? Treat it as an incident: restrict access or take the affected feature down, then fix the policies before anything else. A takeover estimate can wait a day; exposed customer data cannot.
What should I send to get an estimate? Your 12-point score, what the app does, and how many users and transactions a month. Read-only access to the repository and the backend tightens the number, but the first estimate does not need it.
Send the score and three lines here for a scoped estimate in two working days, see how KUMO takes vibe-coded apps to production, or book a 30-minute call.
The numbers in one file. The Build vs Buy Price Book, October 2026 has the published prices of 40 business tools read in October 2026, what they cost a 40-person company, and the four tests that say whether a custom build is worth it. Download the PDF (8 pages, free, no form).
