Your vibe-coded app, ready for production
What do we check in an AI-built prototype?
The same items every time, in a report you can read without being technical. This one is an example on a typical prototype: for each item, its status, what happens in production and what we do about it.
Example report
Authentication
Status: Critical
Login works, but who can see what is only enforced in the interface.
In production Anyone who knows the right URL can read or change other users' data.
What we do Permissions enforced on the server and in the database, row by row, with tests for every role.
Data and database
Status: Critical
The data model grew prompt by prompt: duplicated tables, no constraints, no migrations.
In production Inconsistent data that gets very hard to untangle once real customers are in.
What we do A cleaned-up schema with constraints and indexes, versioned migrations and a plan to move the existing data.
Secrets and keys
Status: Critical
API keys shipped in the code that reaches the browser, or committed to the repository.
In production Anyone can use them on your bill, or get to your data.
What we do Keys rotated and moved server-side into environment variables, access reviewed one by one.
Tests
Status: Needs work
No automated tests: any generated change can quietly break something elsewhere.
In production Customers find the bugs, often at the moment they try to pay.
What we do Tests on the journeys that make money, such as sign-up, booking and checkout, run on every change.
API costs
Status: Needs work
Calls to AI models with no limits or caching, always to the largest model.
In production A bill that grows faster than your customer base, or one abusive user who blows it up overnight.
What we do Per-user limits, caching, the right model for each task and an alert when spend climbs.
Performance
Status: Needs work
Everything loaded in the browser, heavy images, the same queries run again and again.
In production A sluggish experience on phones, users dropping off, pages Google struggles to read.
What we do Server-side rendering where it counts, tuned queries, measurements on real devices.
Accessibility
Status: Needs work
Generated components with no labels, low contrast and no keyboard support.
In production People who simply can't use the product, and a harder sell to business customers.
What we do Semantic HTML, labels, contrast and keyboard navigation checked screen by screen.
Deployment and backups
Status: Critical
One-click publishing from the tool's own platform, and no backup anyone has tested.
In production One mistake or one suspended account, and your customers' data is gone.
What we do Automated releases from a repository, separate environments, nightly backups with an off-site copy and a restore we've actually tried.
Interface and flows
Status: Fine
Clear screens and main journeys that work: this is where these tools shine.
In production Nothing wrong in itself. It's the part to protect while the rest gets fixed.
What we do We keep it, tidy it where needed and put solid foundations underneath.
We write the real report on your prototype, using whatever code and data the tool lets you export.
Why isn't an AI-built prototype a product yet?
Because AI tools are brilliant at making the demo work and far less good at anticipating what happens when something goes wrong: a malicious user, a payment that fails halfway, a thousand people at once.
Developers say as much. In Stack Overflow's 2025 survey, the most common frustration with AI, cited by 66% of respondents, is solutions that are “almost right, but not quite”. You won't notice in a prototype. Your first customers will.
How do you take a prototype to production?
In four steps, in the same order every time. First close what's dangerous, then improve the rest.
Audit
We read the code, data and configuration and write the report: what's critical, what needs work, what stays.
Lock-down
We close the critical items straight away: permissions, keys, backups. The product stays live while we do it.
Rewrite where needed
Only the parts that won't hold, from the data model to payment logic, with tests that pin down how they should behave.
Release
Deployment from a repository with separate environments, monitoring, and a maintenance plan after launch.
Keep, refactor or rewrite: how do you decide?
Part by part, never for the prototype as a whole. Rewriting everything is almost always the longest way round.
| Part of the prototype | Keep it if… | Refactor it if… | Rewrite it if… |
|---|---|---|---|
| Interface and components | the flows work with real users | components are duplicated or hard to use with assistive tech | every screen is a one-off and changing a detail means touching dozens of files |
| Data model | tables and relations match your domain | constraints, indexes and migrations are missing | the same data lives in several places and none of them is the source of truth |
| Authentication and permissions | it uses a reliable provider and checks run on the server | roles are only checked in the interface | login is home-made, with no standard behind it |
| Business logic | pricing, rules and bookings live in one place | the logic is scattered but correct | the same rule is written twice, in the browser and on the server, with different results |
| Payments and integrations | they rely on webhooks verified with the provider | error handling and retries are missing | payment status is decided in the browser |
| Infrastructure | code and data can be exported | releases are manual | code or data are locked into the platform: time to migrate |
Which tool did you build it with?
Lovable, Bolt, v0, Replit, Cursor, FlutterFlow, Bubble or something else: the first question isn't the tool, it's whether the code and data can be exported. If they can, we start from there; if not, we plan a migration that doesn't take the product offline.
The standard we aim for is the one we hold our own products to. On Athleex, our SaaS, the database is backed up nightly with an off-site copy and every change goes through automated CI; more in the case study. Our stack choices are on the technologies page.
Questions about going to production
Can a vibe-coded app go into production?
Yes, after an audit. The interface and flows can often stay; authentication, data, keys and backups need checking before real customers arrive, because that's where prototypes are weakest.
Do we have to rewrite everything from scratch?
Usually not. We decide part by part: keep what holds, refactor what's correct but messy, and rewrite only what's dangerous or impossible to maintain. A full rewrite takes longer and throws away what already works.
How much does it cost to take a prototype to production?
It depends on what the audit finds: how many critical items there are, how much needs rewriting, and whether code and data can be exported. We don't have a price list; after the audit you know what needs doing and why. What drives the cost is on our pricing and timelines page.
Do you work with Lovable, Bolt or FlutterFlow prototypes?
Yes. We start from whatever code and data the tool lets you export; if the platform keeps them locked in, we plan a migration that doesn't interrupt the product or its users.
Can I keep building with AI afterwards?
Yes, and it's a great way to try new features quickly. The difference is that whatever goes to production passes through review, tests and a controlled release. If you need someone to keep those rules in place over time, that's what a fractional CTO is for.
Further reading
Send us your prototype.
A link and a few lines on who uses it today are enough to start.
Ask for an audit