From vibe-coded to production-ready: a checklist

A non-technical founder, with the help of an AI coding assistant, ships a working prototype in a weekend. It does the thing. The first users like it. And then it starts to wobble.

The wobble is rarely about the AI. It is about everything around it: auth, data, deployment, error handling — the parts of an application that nobody finds exciting until they break. Getting a vibe-coded prototype to a state a business can actually run on requires addressing each of these, not rewriting what is already there.

The mindset shift

Vibe-coded prototypes optimise for one thing: the next demo. That is exactly what they should do in week one. Production has a different goal. It optimises for the quiet Tuesday when nothing should go wrong, and almost nothing does.

1. Auth and identity

Generated apps almost always ship with a placeholder auth setup. Sometimes there is no auth at all. Sometimes there are users but no password reset, no roles, and no rate limiting on the login endpoint.

Before taking the project further: move to a real auth provider (Auth0, Clerk, Supabase Auth, NextAuth — pick one the team can support long-term). Define roles, even if there are only two. Turn on rate limiting on login, signup, and password reset endpoints. Decide what happens when a user leaves, because there needs to be an answer before a user asks the question.

2. Data and schemas

Prototypes reach for string fields and JSON blobs because they are easy to generate and extend. They are also where production incidents tend to start.

Walk through the data model and ask, for each field: is the type tight enough that bad data cannot get in? Is there a migration story when this changes? Is sensitive data identified, with access to it logged? Is there a backup, and has anyone actually tried restoring from it? That last one matters more than the others. Backups no one has tested are not backups; they are assumptions.

3. Secrets and configuration

API keys committed to the repository, environment values pasted into source code, secrets managed only in a .env file on the founder's laptop — these are common in prototypes and each one is a liability.

The fix is not glamorous. Move every secret out of source control and rotate anything that was ever committed. Pick a secret manager (most hosting providers include one). Separate development, staging, and production credentials. Document who has access and review that list at least quarterly.

4. Observability

You cannot operate what you cannot see. The prototype probably has console.log in a few places and nothing else. That is fine for one user and hopeless once there are ten.

The minimum useful setup: structured logs with request IDs, error tracking (Sentry or equivalent) wired into both frontend and backend, uptime monitoring on the public URL, and one or two product metrics that tell you whether the core workflow is functioning. The goal is not a full observability stack. The goal is not finding out about an outage from a user.

5. Deployment and CI

Manual deployment from a laptop works for one person on one project. It becomes a liability as soon as anyone else is involved.

The minimum is source-controlled deployment configuration, a build pipeline that runs on every change even if it only runs tests and a linter, automated deploys from a known branch to staging, and a rollback procedure that someone has actually executed. That last part is important. Most outages end by getting back to the last known good state quickly, and you do not want to figure out the rollback process during an incident.

6. The AI parts

If the prototype calls a model, the model code itself usually needs the least attention. What needs work is everything around the call: timeouts and retries with sensible backoff, a spending budget that will not run away in an incident, fallbacks for when the model is slow or unavailable, eval coverage for the cases that matter to the business run on every change, and logging of prompts and responses with privacy in mind.

This is the work that turns "we use AI" into "we depend on AI." Most prototypes skip it. Systems in production cannot.

7. The smallest test suite worth having

Full coverage is not the goal. The goal is tests on the handful of behaviours that, if they broke silently, would damage user trust. That is usually fewer than ten tests at first. Write those, run them in CI, and let the suite grow as the system grows.

What comes next

The order of work in a prototype-to-production project matters. Auth, secrets, deployment, and error tracking tend to come first because they stop the most pressing risks. Data work, eval coverage, and runbooks follow. The point is never to throw away what was built. The point is to put a system around it that keeps it useful as usage grows.

If you have a prototype that is starting to wobble under real users, feel free to reach out at tim@quolo.io.