Vibe-coded MVP to a million users? Start with a load model.

Translate the ambition into traffic

A product built quickly with AI can be a useful starting point. But the speed of building it says little about the load its database, integrations and background jobs can handle. Before choosing a scaling architecture, ask what users will actually do.

Here is an illustrative calculation with assumed numbers, not a benchmark or a typical ratio: one million registered users, 5% active on a given day, and 20 backend requests per active user produce one million requests per day. Dividing by 86,400 seconds gives about 11.6 requests per second on average. That average says nothing about a campaign peak, synchronized scheduled jobs or the cost of an individual request.

Describe a workload that engineers can test

Define the mix of reads, writes, uploads, searches and AI tasks. Include data size and skew: one organization with a large history may expose a problem that thousands of empty test accounts do not. Separate registered users, active sessions and simultaneous requests.

Agree on acceptable latency, error rate, queue delay and cost for the important journeys. An ordinary status lookup and a long-running document analysis should not be held to the same performance target by default.

• How much traffic arrives at the busiest expected time?
• Which operations call an external API or model?
• What data size and account distribution should the test represent?
• Which operations can wait, and which must respond immediately?

Test the journey and inspect the bottleneck

Build a representative test environment and record how it differs from production. Generate synthetic data, run a small baseline and increase the workload in steps. Observe the application, database and queues together; otherwise a fast HTTP response can hide a growing backlog.

Grafana's k6 documentation describes API load testing and thresholds that determine whether a test passes. The targets still have to come from your product requirements. A passing test supports a claim about the tested configuration and workload, not every possible million-user scenario.

For paid or rate-limited dependencies, agree on test budgets and permissions. Test the application's behavior when those dependencies slow down. If you use a simulated provider for most load, label that limitation and validate the real integration under load separately, within the provider's limits.

Change what the measurements justify

A slow query may need a different index or data-access pattern. Repeated reads may benefit from caching with an explicit freshness rule. Long operations may belong in a queue with visible progress. None of these decisions requires splitting the whole application into microservices first.

When an AI feature dominates cost or latency, measure completed tasks, model calls per task and retries. Consider whether a deterministic lookup can answer part of the request. Keep a useful fallback for provider failure, and verify that capacity limits do not silently lose work.

Make the next capacity step part of continued development

After each bounded change, repeat the relevant test and record the configuration, result and remaining limit. Increase rollout scope deliberately, watch production signals and keep a recovery procedure. As traffic and data grow, the test assumptions need to grow too.

UVISION's role is ongoing engineering ownership: dedicated developers or managed projects, with at least one full-time developer per project. That includes understanding the current system, keeping useful code and developing the next capacity step. A million-user ambition becomes credible through measured evidence and continued operation, not a promise attached to a rewrite.