You vibe-coded an app. Now what? Taking an AI-built prototype to production

In February 2025, Andrej Karpathy described a new way of building software he called “vibe coding”: describing what you want to an AI tool, accepting what it produces and steering by results rather than reading the code. The term stuck because it captured something real. Founders, designers and marketers are now building working apps without a development team.

That is genuinely good news. A clickable, working prototype is the best possible way to test an idea. The trouble starts when the prototype gains real users, real data and real payments, and nobody has checked what is happening underneath.

What vibe-coded prototypes do well

• They prove that an idea can work and show it to customers and investors quickly.
• They capture the flow and feel of a product far better than a written specification.
• They make it cheap to try several directions before committing.
• They give a development team a concrete reference for what you want.

The problems we see most often

When teams bring us AI-built prototypes, the same issues come up again and again. None of them are visible in a demo, which is exactly why they matter.

Secrets in the wrong place

API keys for payment providers, AI models or email services end up inside frontend code, where anyone can read them with the browser’s developer tools, or committed into a public repository. Attackers actively scan for exposed keys.

Permission checks only in the interface

The app hides the admin button from normal users, but the server will happily perform admin actions for anyone who sends the right request. Real security has to be enforced on the server or in the database, not in the screens.

Open database rules

Hosted backends such as Firebase and Supabase are excellent, but they rely on security rules or row-level security policies to decide who can read and write which data. Prototypes often leave these open, or disabled, so any user can read or change every other user’s records.

No validation, no error handling

Inputs are trusted as they arrive, errors are swallowed or shown as raw messages, and failed payments or emails silently disappear.

No tests, no environments, no backups

Changes go straight to the live app, there is no automated check that the core flows still work, and nobody has tried restoring the database from a backup.

Tangled, duplicated code

Each prompt added a slightly different version of the same logic. The app works, but small changes break unrelated screens, and the AI tool itself starts struggling to make edits safely.

A step-by-step path to production

1. Freeze new features for a short period. Stabilising a moving target is much harder.
2. Run a security audit first: secrets, authentication, server-side permission checks, database rules and file upload handling.
3. Fix data access so every query is limited to what the signed-in user is allowed to see and change.
4. Move all secrets to server-side environment variables and rotate them.
5. Write automated tests for the critical journeys: sign-up, login, the core action of your product and payments.
6. Set up separate development, staging and production environments, with deployments through a pipeline rather than by hand.
7. Add monitoring and error tracking so you hear about problems before customers tell you.
8. Turn on automated backups and test a restore at least once.
9. Refactor the messiest areas incrementally, protected by the tests you just wrote.

Fix it or rebuild it?

Not every prototype should be rescued line by line. Sometimes the fastest safe route is to keep the design, the flows and the lessons learned, and rebuild the code on a clean foundation.

Even a rebuild is far faster with a working prototype in hand. The open questions about what to build have already been answered.

Keeping AI tools in the workflow

Production does not mean giving up the speed you enjoyed. AI tools remain useful once the foundations are in place, especially for well-scoped changes. The difference is process: changes go through review, tests run automatically, and anything touching security, payments or personal data gets a careful human look.

A pre-launch checklist

• No secrets in frontend code or the repository; all keys rotated.
• Every API endpoint and database rule checks who the user is and what they may access.
• Inputs validated on the server; uploads checked for type and size.
• Critical flows covered by automated tests that run on every change.
• Separate staging environment that mirrors production.
• Error tracking, uptime monitoring and alerts in place.
• Automated backups with a tested restore.
• Privacy policy and terms that match how data is really used.

If you have built something with AI tools and users are starting to arrive, an independent audit is a small investment that can prevent a very public problem. We regularly take AI-built prototypes, secure them and turn them into products teams can confidently grow.