A startup asks you to architect their product "to handle millions of users". They currently have none. What do you actually build?

What the interviewer is testing

Whether you can identify the real constraint. The stated requirement is scale; the actual constraint is survival, and an architect who cannot tell the difference will build the wrong thing competently.

The reframe

A pre-revenue product's dominant risk is not that it succeeds too fast to scale. It is that it never finds out whether anyone wants it, because the runway ran out while the platform was being built. Architecting for millions of users spends the one non-renewable resource — time — on insurance against a problem the company may never earn the right to have.

Say this plainly, and then show what you would build instead.

What to build

A modular monolith on a managed platform. One deployable, clean internal module boundaries, one managed relational database, a managed container service, a CDN. This will comfortably serve tens of thousands of users and can be built in weeks rather than months.

Managed everything. Auth, email, payments, search, file storage. Every one of these built in-house is weeks that produce nothing a customer values.

The two things worth doing properly from day one, because they are the expensive ones to fix:

• Module boundaries. They cost nothing extra now and they are what makes extraction possible later. This is the entire hedge against future scale, and it is nearly free.
• Data model and identity. Schema migrations under load and retrofitting a tenant model are among the most painful changes there are.

Basic observability, because you cannot fix what you cannot see, and it takes an afternoon.

What to deliberately not build

Microservices, Kubernetes, a message broker, CQRS, multi-region, a service mesh, a custom platform. Each one is operational burden carried weekly in exchange for capability that may never be needed — and every one of them slows the loop that actually determines survival.

How to say it to the founder

Not "you don't need scale". Something closer to: "I can give you a system that handles 50,000 users, ships in six weeks, and can be scaled incrementally as you grow — or one that handles two million, ships in six months, and costs four times as much to run while you have no revenue. At 50,000 users you will have the money and the data to make the next decision properly. Here is the specific list of things I am doing now so that decision stays cheap."

That last clause is what makes it an architectural position rather than a refusal.

What a strong answer adds

Naming the trigger conditions in advance: at what user count, latency or cost figure would you revisit each deferred decision? A design with written trigger conditions is a plan; one without is a bet.