
A vibe-coded app often feels finished on launch day. Then real users arrive, the data grows, and a page that once loaded instantly starts to lag. That moment raises the question behind this blog.
Vibe coding means building software by describing what you want to an AI tool and accepting the code it writes, often without reviewing it line by line. Andrej Karpathy coined the term in February 2025.
Yes, most vibe-coded apps can scale. They rarely struggle because an AI wrote them. They struggle on the same bottlenecks as any app, and vibe coding makes those bottlenecks more likely because nobody reviewed the patterns. The problems usually appear in this order:
Most of these problems have targeted fixes. A full rewrite is rarely the first step.
AI tools write code that works on the data in front of them. A test database with 50 rows hides problems that appear at 500,000 rows. The same few patterns cause most of the trouble:
None of these patterns is unique to AI. A human developer can write all of them. The difference is that a person often reviews the code before release, while a vibe-coded app may ship without that review. For the security side of the same problem, see the guide to taking a vibe-coded app to production.
Scaling is not one event. It is a series of firsts, and each one exposes a different weakness. The table summarizes the usual order.
Stage | What breaks | How you notice | First fix |
| First real users | Data access and recovery | A user sees data that isn't theirs, or data is lost | Test access rules and restore a backup |
| First traffic spike | Queries and connections | Pages slow down, or connection errors appear | Add indexes, pool connections and cache |
| First paying customers | Reliability | Customers report failures before you see them | Move slow work to background jobs and add alerts |
| First AI-feature bill | Model costs and rate limits | The API bill jumps, or requests are refused | Set per-user limits and cache responses |
| First teammate | Safe changes | New changes break features that worked | Add code review and preview environments |
| First enterprise customer | Compliance | A security questionnaire you cannot answer | Add audit trails and choose a certified host |
1. First real users: is your data safe?
Real users bring real data, and mistakes now affect real people. Test each access rule by signing in as a second user and trying to read the first user's data. Then schedule backups and restore one, because an untested backup may fail when you need it.
2. First traffic spike: why do pages slow down?
Slow pages usually come from the database, not the server. Supabase's own tests show how large the gains can be. Adding an index to the column used in an access rule cut one query from 171 ms to under 0.1 ms. Rewriting auth.uid() as (select auth.uid()) in a policy cut another from 179 ms to 9 ms.
Connections are the second limit. Every database accepts a fixed number of connections. Serverless functions can open many short-lived connections at once, so Supabase recommends a connection pooler for them.
3. First paying customers: will you know when something breaks?
Paying customers expect the app to work, and they notice failures quickly. Move emails, file processing, and AI calls out of web requests and into background jobs, so a slow task does not block the user. Then add error alerts that reach a person, so you hear about failures before customers do.
4. First AI-feature bill: what does each user cost?
If your app calls a model API, every active user adds cost. Heavy users can cost far more than light ones. Set a usage limit per user, cache answers to repeated questions, and use a smaller model where quality allows. Track cost per user, not just the monthly total.
5. First teammate: can you change the app safely?
One person can keep the whole app in their head. Two people cannot. Add code review, run automated tests, and try each change in a preview environment before release. The same rules apply when AI agents write the code; tools such as Upsun Dispatch add human approval steps to that work.
6. First enterprise customer: can you prove the app is secure?
Larger customers send security questionnaires. They ask where data is stored, who can access it, and how changes are approved. Answering them takes audit trails, clear data residency, and a host with recognized certifications.
Usually not. Most scaling problems live in a few queries, settings, or functions, and fixing those is faster and safer than starting again. Use the signals below to decide.
Approach | Choose it when | Typical work |
| Fix in place | Specific pages or queries are slow, but the structure is sound | Add indexes, pooling, caching, and background jobs |
| Refactor one part | One area, such as billing or file handling, keeps breaking | Rewrite that module with tests, and leave the rest |
| Rebuild | The data model is wrong, or every change breaks something else | Plan a new version and migrate the data in stages |
Be cautious of advice that jumps straight to a rebuild. A rebuild takes months, and the new version can repeat the same mistakes without good tests. Start with the fix that removes the current bottleneck, then measure again.
You find the limits by testing with realistic traffic and realistic data. Three steps cover most apps:
The first step is often the hardest, because copying production data into a test environment takes effort. Some platforms automate it. On Upsun Cloud, each Git branch can get a preview environment that clones production apps, services, and data, so a load test runs against the same data volume users create.
Upsun Cloud suits vibe-coded apps that have outgrown a simple setup and now need to grow in a controlled way. It helps at several of the stages above:
For a small static app, a simpler host is enough. The comparison of hosting platforms for vibe-coded apps explains when each option fits.
What is vibe coding?
Vibe coding is building software by describing what you want to an AI tool and accepting the code it produces. Tools such as Lovable, Bolt, Replit, v0, Cursor, and Claude Code are commonly used for it.
Can a Lovable app handle thousands of users?
Yes, if the database is designed for it. Lovable apps store data in a Supabase-based backend, so capacity depends mostly on indexes, access rules, and the database plan. Test with production-sized data before a launch or campaign.
Does Supabase scale?
Supabase runs on PostgreSQL, which handles large workloads well. Scaling a Supabase app usually means optimizing queries and access rules, using a connection pooler, and moving to a larger compute size when needed.
Is AI-generated code slower than human-written code?
Not inherently. The risk is quality, not speed. A CodeRabbit analysis of 470 pull requests found about 1.7 times more issues in AI-written code, and performance problems are one type of issue.
How much does it cost to scale a vibe-coded app?
Costs depend on traffic, data size, and AI usage. The largest increases usually come from database capacity and model API calls. Platforms with resource-based pricing let you pay for the resources each part of the app actually uses.
When should I bring in a developer?
Bring in a developer when the same problem returns after several fixes, when the app handles payments or personal data, or before you sign a large customer.
Can I keep vibe coding after launch?
Yes. Keep using AI tools, but add code review, automated tests, and preview environments, so each change is checked before users see it.