You described your idea to an AI tool, and a weekend later you had a working app. Screens, a login, a database, maybe even a checkout. That is vibe coding, and it is now mainstream: Collins named it Word of the Year for 2025, and on October 15, 2026 Figma announced that Figma Make can now scaffold a Payload backend, with a CMS, database, auth and admin panel, describing it as turning a prototype into a production app.
The hard question comes next: can real customers use this? Can it take payments, keep data private and survive a busy Monday? This guide is for founders and business owners holding a vibe-coded app, whether it's an MVP, an internal tool or a client portal. It covers what usually breaks between “works on my screen” and “safe to launch”, and how to decide whether to harden, refactor or rebuild.
Why this matters right now
Two pieces of recent evidence show the gap between code that runs and code that is safe.
- AI-written code still fails security checks often. Veracode's 2026 GenAI Code Security Report found that roughly 44% of AI code generation tasks introduced a known security vulnerability when the models were given no security-specific guidance. The average security pass rate was 56%, barely changed from 55% in its first report, even though the code is almost always syntactically correct. Cross-site scripting was one of the weakest areas, with a 15% pass rate.
- Leaked API keys cost real money, fast. In October, the AI coding tool OpenCode said an attacker reached a legacy part of its hosted Console, and it told affected users to revoke the AI provider keys they had stored there. TechCrunch reported that some users saw unauthorized charges in the hundreds of dollars, and a few described totals above $1,000. As The Hacker News explained, a provider key is a bearer credential: anyone holding a copy can run billable requests until it is revoked.
Neither of these means vibe coding is bad. It means the prototype is the start of the work, not the end.
What vibe coding gets right
It's worth being fair. A prompt-built prototype is a very cheap way to test an idea, show investors something real and find out which screens users actually touch. It also gives a development team a far better brief than a document ever could. Plenty of good products start this way. The trouble starts only when the prototype quietly becomes the product, without anyone checking what is underneath.
The production-readiness checklist
These are the areas an engineer should review before real customers, real data or real money touch your app. You don't need to fix everything on day one, but you do need to know where you stand on each one.
1. Secrets and API keys
- No keys in front-end code, in the repository or pasted into chat tools. Search the code for anything that looks like a key.
- Each service gets its own key, stored in environment variables or a secrets manager, so one leak is easy to trace and revoke.
- Spend limits and billing alerts are set with every AI and cloud provider you use.
2. Authentication and permissions
A working login screen is not the same as working security. Check that users can only see and change their own records, and that this is enforced on the server or in the database rules, not just hidden in the interface. Try changing an ID in the URL or an API request. If you can see another customer's data, so can anyone else. Admin accounts should use multi-factor authentication.
3. Input handling
Everything a user types, uploads or sends to your API should be validated on the server and safely escaped when it is displayed. Given how weak AI models still are at preventing cross-site scripting, this deserves a careful manual review, not just another prompt.
4. Database, backups and migrations
- Indexes on the columns you filter and sort by, so pages don't slow to a crawl as data grows.
- Automatic backups, and one restore you have actually tested.
- Schema changes made through versioned migrations, not by editing the live database by hand.
5. Payments and webhooks
If you take money, use your payment provider's hosted checkout or official SDK. Verify webhook signatures, handle repeated or late events without double-charging or double-crediting anyone, and keep a clear record of every subscription change and refund.
6. Errors, logs and monitoring
When something breaks at 2 AM, you should find out before your customers tell you. That means error tracking, uptime monitoring and logs that record what happened without storing passwords or personal data in plain text.
7. Tests and a safe release process
Vibe-coded apps often have no tests, so every new prompt risks breaking something that used to work. Start with a handful of automated tests for the flows that make you money (sign-up, login, checkout, the core feature), and run them automatically before every release. Keep a separate staging environment so changes are tried there first.
8. Hosting, scaling and costs
Know where your app runs, what it costs at ten times your current usage, and what happens when a hosted tool changes its pricing or limits. If your AI features call a model on every page load, cache the results or move the calls to background jobs.
9. Ownership and portability
- The code lives in a repository your company owns, not only inside a builder tool or one freelancer's account.
- Domains, hosting, app store, payment and AI provider accounts are in your company's name, with at least two admins.
- Someone other than the original prompter can read the code and explain how it works.
10. Privacy and compliance
Write down what personal data you collect, where it is stored and who can access it, and publish an honest privacy policy. If you handle health, financial or children's data, or serve customers in the EU or UK, get advice early. Those rules are much cheaper to design for than to retrofit.
Harden, refactor or rebuild?
After a code review, most vibe-coded apps fall into one of three groups:
- Harden. The structure is sensible and the stack is mainstream (for example, Next.js with a managed database). Fix the checklist gaps, add tests and monitoring, and keep going. This is usually the cheapest path.
- Refactor. The core works, but key parts such as permissions, the data model or payments were generated in a tangle. Rewrite those modules properly while keeping the screens and flows users already know.
- Rebuild. The app is locked into a tool you can't export from, the data model can't support where the business is heading, or fixing one bug keeps breaking others. In that case, treat the prototype as a detailed specification and rebuild on a clean foundation. You lose far less than it feels like, because the hard product decisions are already made.
Be wary of anyone who recommends a full rebuild without reading your code first, and equally of anyone who says it's fine without testing it.
What does it cost to make a vibe-coded app production-ready?
It depends on the size of the app, how much of the checklist is missing and whether payments or sensitive data are involved. Our typical initial project is USD 3k–15k+, and production hardening is scoped after a code review, as fixed-price milestones rather than open-ended hourly billing. If the right answer turns out to be a rebuild, see our SaaS development and web development services, or our guide to SaaS development cost in 2026.
Plan for running costs too:
- Hosting, database and any builder-platform subscriptions.
- AI model usage, which is billed per request.
- Ongoing updates and security patches. Our maintenance & support retainers cover this after launch.
A practical four-week hardening plan
- Week 1, audit. Move the code into your own repository, rotate every key, and review it against the checklist above. Rank the findings by risk.
- Week 2, fix the dangerous parts. Permissions, input handling, secrets, payments and backups come first.
- Week 3, add safety nets. Tests for the money flows, a staging environment, error tracking and uptime monitoring.
- Week 4, launch carefully. Release to a small group of users first, watch the logs, then open the doors.
Larger apps take longer, but the order stays the same: security first, safety nets second, new features third. You can keep using AI tools throughout. They are excellent at drafting code once an engineer is reviewing what they produce.
Frequently asked questions
Is vibe coding good enough for an MVP?
For testing an idea with friendly early users, often yes. Once you take payments or store other people's personal data, have an engineer review it first.
Can I keep using AI tools after you take over?
Yes. Most teams, including ours, use AI coding tools every day. The difference is that a person who understands the system reviews and tests what goes live.
Do you work on apps built with Lovable, Bolt, Replit, Cursor or Figma Make?
If we can get the code out and it runs on a mainstream stack, we can review it. If it can't be exported, we'll tell you plainly and help you plan a rebuild.
We're an agency with a client's vibe-coded prototype. Can you help?
Yes. We can do the hardening under your brand. See how our white-label development works, or hire Next.js developers to join your team.
Got a prototype you're not sure about?
We're a software house in Multan working with founders and agencies in Pakistan, the US, the UK and beyond. Tell us what your app does and what it was built with, and we'll tell you honestly whether it needs hardening, refactoring or a rebuild. Send us a brief and we'll reply within one business day.
Report figures and product announcements were checked on the publishers' own pages in October 2026.