AI app builders like Lovable and Bolt generate functional prototypes in hours. But they consistently deliver roughly 70% of a production-ready application. The remaining 30% (security, authentication, error handling, and infrastructure) costs $5,000-$20,000 in professional engineering. This post breaks down exactly where AI-built MVPs fall short, what the real cost looks like, and how to plan your build so you do not pay twice.
What the 70% problem actually looks like
A founder opens Lovable or Bolt.new, describes their SaaS idea in a few sentences, and watches a functional application appear in minutes. Login screen. Dashboard. Data tables. Forms. It looks done.
It is not done.
The platform reaches at most 70% of the way there, leaving you wrestling with the final 30%. That final 30% is not cosmetic polish. It is the difference between a demo and a product that handles real money, real data, and real users.
The pattern repeats across every AI builder on the market. One founder built an invoicing tool with Lovable in four days for $37: client management, invoice generation, payment tracking, Stripe integration. She launched on Product Hunt, got 200 signups in the first week. Then she needed to rebuild the payment flow. The AI-generated version could not handle edge cases that real payment processing requires.
That is the 70% problem. The first 70% is fast, cheap, and impressive. The last 30% is where the engineering actually happens.
Where AI-generated code breaks down
The failures are not random. They cluster in predictable categories that AI models consistently handle poorly. We see these patterns in every AI-built codebase that comes through our door.
Authentication and authorization
Basic email/password login works. Everything beyond that does not. Enterprise SSO, role-based access control (RBAC), multi-tenancy, session management across devices, OAuth flows with proper token refresh: these require architectural decisions that AI builders skip entirely.
We have seen cases where implementing Supabase authentication through Bolt drained millions of tokens through repeated failed fixes. The AI generates auth code, breaks it, regenerates it, and breaks it again, while charging for every iteration.
Security vulnerabilities
This is the most dangerous gap, because it is invisible until something goes wrong.
Between 40% and 62% of AI-generated code contains security vulnerabilities. Audits of vibe-coded apps typically find 8 to 14 security findings per application. Georgia Tech’s Vibe Security Radar tracked 35 new CVE entries directly caused by AI-generated code in March 2026 alone, up from six in January.
The most common issues we find in AI-built apps:
- Disabled row-level security: roughly 70% of Lovable-generated apps ship without it
- Leaked secrets: API keys and credentials hardcoded in client-side code
- Missing webhook verification: payment and event webhooks accepted without signature validation
- SQL injection: AI-generated queries that interpolate variables instead of using parameterized statements
- No input sanitization: user input passed directly to database queries and API calls
In one high-profile incident, 1.5 million API keys were leaked because a founder shipped an AI-built app without a single security review.
If your SaaS handles user data, processes payments, or operates in a regulated industry, shipping AI-generated code without a security audit is not a shortcut. It is a liability.
Payment processing
AI builders handle basic Stripe Checkout integration: redirect to a hosted payment page, receive a webhook, update a database record. That covers a demo.
Production payment processing requires handling failed charges, subscription upgrades and downgrades, prorated billing, dunning emails for expired cards, refund logic, tax calculation across jurisdictions, webhook idempotency (processing the same event twice without double-charging), and PCI compliance considerations. None of this is generated correctly by current AI tools.
The complexity cliff
Projects with 15-20+ components experience what we call “pattern loss”: the AI forgets established conventions and creates redundant, contradictory code. It is the moment where prompting stops working and the AI starts making things worse, not better.
This is not a temporary limitation that will be fixed next quarter. It is a fundamental constraint of how current AI models process context. Multi-step workflows, complex permission systems, and real-time features at scale all hit this wall.
Platform lock-in
Lovable generates React + Vite applications tightly coupled to Supabase. Bolt generates in a sandboxed environment with its own runtime constraints. In both cases, the generated codebase is not built for long-term scalability, and converting it into a maintainable architecture takes significant effort.
If you plan to iterate on your product for years (which is what building a SaaS business requires), starting with a codebase that fights against maintainability creates compounding technical debt from day one.
The real cost of the 70% problem
The sticker price of AI builders is low: Lovable Pro is $25/month. Bolt Pro starts at $20/month. But the total cost of getting to production tells a different story.
| Cost Component | AI Builder Alone | AI Builder + Engineer | Traditional Agency |
|---|---|---|---|
| Initial build | $25-$50/mo | $25-$50/mo | $50,000-$150,000 |
| Token/credit burn during iteration | $200-$1,000+ | $200-$500 | Included |
| Security audit | $0 (skipped) | $2,000-$5,000 | Included |
| Auth + payment hardening | $0 (incomplete) | $3,000-$8,000 | Included |
| Production infrastructure | $0 (platform-managed) | $500-$2,000 | Included |
| Post-launch fixes | $5,000-$20,000 | $1,000-$3,000 | $5,000-$15,000 |
| Realistic total | $5,000-$21,000 | $6,700-$18,500 | $55,000-$168,000 |
| Timeline | 1-2 weeks + months of fixes | 2-4 weeks | 3-6 months |
The AI builder column looks cheap until you factor in what happens after launch. The $25/month subscription generates the 70%. The $5,000-$20,000 in post-launch engineering is the other 30%.
As one reviewer put it: “This really won’t replace a developer. Especially if your product idea has any kind of technical complexity to it.”
When the 70% is actually enough
The 70% problem is not always a problem. There are legitimate use cases where 70% completion is exactly what you need.
Demand validation. You want to know if anyone would pay for your idea before investing in production engineering. An AI-built prototype with a working sign-up flow and core feature is enough to test that. A founder who gets 200 signups in a week has validated demand, and now knows it is worth investing in the other 30%.
Investor demos. A seed-stage pitch deck backed by a working product, even an imperfect one, outperforms a pitch deck with wireframes. AI builders produce functional demos faster than any alternative.
Internal tools. If the app is used by your team of 5-15 people, the security and scalability requirements are fundamentally different. A Lovable-built internal dashboard that tracks project status is perfectly adequate. It does not need to handle 10,000 concurrent users or comply with SOC 2.
Landing pages and marketing sites. AI builders are genuinely good at generating static and semi-dynamic pages. There is no 30% gap here: a landing page either looks right and loads fast, or it does not.
The 70% is a problem when you need the product to handle real money, real user data, or real scale. For everything else, it might be exactly enough.
How to build without paying for the 70% twice
The expensive version of the 70% problem is building the entire thing with an AI builder, launching, discovering the gaps, and then paying an engineer to rework what was already built. You pay for the AI-generated version, then you pay again to rebuild the parts that do not work.
The cheaper version is planning for the 30% from the start.
Option 1: AI prototype, then professional rebuild. Use Lovable or Bolt to validate the concept. Treat the AI-generated code as a throwaway prototype: a spec, not a foundation. Once you have validated demand, invest in a production build from scratch. This is the cleanest path but takes longer.
Option 2: AI-generated code with engineer review. Use AI tools to generate the initial codebase, then bring in a senior engineer to audit, harden, and fix the 30%. This preserves the speed advantage while addressing the gaps. The key is bringing in engineering early: before launch, not after users discover the security holes.
Option 3: AI-native development from the start. Skip the prototype-then-rebuild cycle entirely. AI-native development services use AI to generate the predictable 80% of production code (CRUD operations, form validation, API routing, component scaffolding) while engineers handle architecture, security, payments, and the decisions that determine whether your product scales. The result is production-grade code delivered in days, not an AI prototype that needs months of rework.
At Asyncdot, we built this model specifically because we saw the 70% problem destroying founder timelines. Senior engineers run the toolchain; AI takes the keystrokes; the production-grade output ships in days, not a demo that needs $15,000 in post-launch fixes. See how we run a project.
The right option depends on your stage. If you are still testing whether anyone wants the product, Option 1 costs the least. If you already know the market exists and need to launch fast, Option 3 saves the most time and total cost. For a full breakdown of every development path with costs and timelines, see The Real Cost of Building a SaaS MVP in 2026.