Is your AI-built app ready for production?

You built a product with Lovable, Bolt, Replit, Cursor, Claude, or another AI tool. It worked — maybe even better and faster than you expected. Now there are real users, maybe the first payments, maybe data that matters to people other than you. This piece is about the question that usually shows up at that point: what, exactly, needs to be reviewed before expanding usage? It's not a fear list, it's a practical roadmap.

Working is not the same as being ready for production

A prototype is ready when it does what was asked, at the moment it was tested, for whoever was testing it — usually you. Production is different: the system has to keep working with people you don't know, data that wasn't there during testing, and usage attempts nobody planned for, including malicious ones.

This isn't a criticism of having used AI to build fast. It's recognizing that validating an idea and sustaining a product are two different problems — and that most code-generation tools were optimized for the first, not the second.

What changes when real users and data come in

While only you use the system, virtually every risk stays invisible — because volume is low and you are, at the same time, the only user and someone who trusts their own code. That changes with real users: a permission gap stops being theoretical and becomes real exposure of someone else's data; an unhandled error stops being an ignored log and becomes a customer losing a purchase.

Authentication is not the same as authorization

Authentication answers "who are you" — login, password, token. Authorization answers "what can you see or do", once the system already knows who you are. It's common for a product to have solid authentication (login works, passwords are protected) and fragile authorization (any authenticated user can, say, access anyone else's data just by swapping a number in a URL or API call).

It's worth explicitly checking: does every screen, every API route, and every database query confirm the authenticated user has permission over that specific piece of data — or does it just trust that the interface doesn't show the wrong button?

Database permissions and data exposure

Tools like Supabase and Firebase make it very easy to start fast, but they put the responsibility of configuring access rules (Row Level Security, Firestore security rules, etc.) directly in the builder's hands. Without that configuration — or with it poorly set up — any client with the public API key can, in theory, read or write data it shouldn't.

Secrets and environment variables

API keys, tokens, and database credentials should never show up in code shipped to the browser, nor in a public repository. It's an easy mistake to make when moving fast — pasting a key straight into the code "just to test" and forgetting to move it to an environment variable later. A simple check helps: open the source code that reaches the browser (what the end user can inspect) and look for visible keys, tokens, or passwords.

Separating development and production

Testing a risky change directly against the real database, with real customer data, is one of the most common ways a small mistake turns into a big incident. Having separate environments — a database and URL just for development, another for production — costs little to set up and keeps a test from becoming a problem for people already using the product.

Backups and restoration

Having automatic backups configured is different from knowing they work. The only way to be sure is to test a restore, at least once, in a non-production environment. Teams tend to discover the backup never worked exactly when they need it most — and by then it's too late.

Logs, monitoring, and alerts

Without monitoring, the way you find out something broke is a user complaining — or worse, a user simply leaving without complaining. A basic alert when important errors happen (even just an email or notification) already shortens the gap between "something broke" and "someone noticed" quite a bit.

Testing critical flows

You don't need to cover every line of code with automated tests. It helps to identify the two or three flows that, if broken, cause the biggest problem — usually login, payment, and anything that writes important data — and make sure there's a reliable way to verify they still work after each change.

Deploy and rollback

Publishing a change should be a repeatable process, not a sequence of manual steps only one person remembers by heart. And when a release causes a problem, there should be a known, tested way to roll it back — without having to rebuild everything from scratch under pressure.

Payments, webhooks, and duplication

Payment systems send events (webhooks) that can, due to the provider's own infrastructure, arrive more than once for the same event. If the system has no protection against duplicate processing, that can mean charging a customer twice or releasing a product with no matching payment. It's one of the points that deserves extra attention before expanding usage.

How to know whether to keep, refactor, or rebuild

The answer is rarely binary. Facing a quickly-built system, there are usually five possible paths for each part of it: keep it as is, protect it with additional controls, refactor a specific section, replace one particular component, or rebuild. Rebuilding is the most expensive path, and the one most often offered by whoever hasn't yet investigated what actually exists — it's worth being skeptical of that recommendation when it arrives too early.

• Map what already works well and needs no intervention.
• Separate security and data risks (high priority) from convenience improvements (low priority).
• Ask: is this specific part causing a recurring problem, or does it just look messy?
• Weigh the cost of stopping the product to rebuild against the cost of protecting and evolving gradually.

When to call an engineer

A few signals make this conversation more urgent: the product is about to take on payments or sensitive data; AI has already tried fixing the same problem more than once without success; no one is sure whether the data is protected; a small change broke something with no apparent relation; or there's a sense that any change now is risky.