• Docs
  • Talk to an expert
Blog
Blog
BlogProductCase studiesNewsInsights
Blog

Can vibe-coded apps scale? What changes after your first real users

AIAI AgentsperformanceScalingdata
06 October 2026
Share

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:

  1. Database queries and access rules slow down as tables grow.
  2. Database connections run out during traffic spikes.
  3. Background work blocks web requests.
  4. Problems go unnoticed because there is no monitoring.
  5. AI API costs rise with every new user.
  6. Team changes become risky without reviews and test environments.

Most of these problems have targeted fixes. A full rewrite is rarely the first step.

Why do vibe-coded apps hit limits sooner?

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:

  • Missing indexes. Queries scan whole tables instead of jumping to the right rows.
  • One query per item. A page loads a list, then runs a separate query for each item on it.
  • Filtering in the browser. The app downloads a large dataset and filters it on the user's device.
  • Access rules that run on every row. Row-level security policies call a function for each row they check.
  • No connection pooling. Serverless functions open a new database connection on every request.
  • Slow work inside requests. Emails, file processing, and AI calls run while the user waits.

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.

What changes after your first real users?

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 usersData access and recoveryA user sees data that isn't theirs, or data is lostTest access rules and restore a backup
First traffic spikeQueries and connectionsPages slow down, or connection errors appearAdd indexes, pool connections and cache
First paying customersReliabilityCustomers report failures before you see themMove slow work to background jobs and add alerts
First AI-feature billModel costs and rate limitsThe API bill jumps, or requests are refusedSet per-user limits and cache responses
First teammateSafe changesNew changes break features that workedAdd code review and preview environments
First enterprise customerComplianceA security questionnaire you cannot answerAdd 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.

Do you need to rewrite a vibe-coded app to scale it?

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 placeSpecific pages or queries are slow, but the structure is soundAdd indexes, pooling, caching, and background jobs
Refactor one partOne area, such as billing or file handling, keeps breakingRewrite that module with tests, and leave the rest
RebuildThe data model is wrong, or every change breaks something elsePlan 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.

How do you find the limits before your users do?

You find the limits by testing with realistic traffic and realistic data. Three steps cover most apps:

  1. Test with production-sized data. Slow queries only appear when tables are large. A test environment with a handful of rows will pass every check.
  2. Run a load test. Open-source tools such as k6 and Locust simulate many users at once. Start with the pages real users visit most.
  3. Watch the slowest queries. PostgreSQL's pg_stat_statements extension lists the queries that take the most time. Fix the top few, then test again.

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. 

Where does Upsun Cloud fit?

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.  
 

Frequently asked questions

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.

Stay updated

Subscribe to our monthly newsletter for the latest updates and news.

Deploy possibility.
Try Upsun for free.

Build with DispatchDeploy on Cloud