But this won't scale to 10k users?! How I navigate the engineering objection.

Premature scale solves an imaginary queue

A team with ten users can spend months designing for a million. The architecture becomes distributed, the local workflow slows down, operational surfaces multiply, and product learning waits behind infrastructure. The future load remains hypothetical while the current cost is immediate.

Ask what evidence would make the scale problem real. Name the active users, requests per second, data volume, tenant count, region, or processing deadline that breaks the current design. Then compare the time to reach that threshold with the time required to evolve the system.

Build the smallest system with a credible exit

Choose a simple authority, keep domain boundaries clear, and instrument the constraint. Stable identifiers, explicit schemas, idempotent jobs, exportable data, and narrow provider contracts preserve options without paying for a distributed system immediately.

Document the known limit and the migration trigger. A single PostgreSQL instance may be the correct choice when it supports the expected load, recovery objective, and team skills. Its value comes from moving product evidence forward with low operational cost.

Distinguish irreversible risk from reversible scale

Some early decisions deserve deeper investment. Weak tenant isolation, unrecoverable data, missing authorization boundaries, and incompatible identifiers can become expensive or dangerous to change. Capacity and topology are often easier to evolve when those foundations are sound.

Spend architecture effort according to reversibility and consequence. Protect security, data ownership, correctness, and migration paths. Defer capacity mechanisms until measurements show that the simple design is approaching its operating boundary.

Use load tests to price the future

A focused load test can reveal the current ceiling, first bottleneck, and likely improvement path. Record the dataset, workload shape, concurrency, hardware, and service-level target so the result remains meaningful. Repeat the test when the architecture or usage pattern changes materially.

Turn the result into a capacity runway. If growth reaches the measured threshold in nine months and the migration takes six weeks, the team has a decision window. That evidence is more useful than a general concern that the backend will not scale.

Earn the right problem

Reaching a thousand active customers proves distribution, onboarding, value, and retention that an elaborate backend cannot create. Welcome the capacity problem when it arrives. The product has earned investment, and the team can redesign with real traffic, real query shapes, and real customer priorities.