Start with the problem, not the stack

The first meeting about a new product often turns into a debate about frameworks, clouds and databases within twenty minutes. It is a comfortable conversation — technology questions have answers. The uncomfortable questions come later, usually after the money has been spent.

We prefer a different order.

Write the problem down

Before any architecture, we write one page: who has the problem, what they do today instead, what it costs them, and what would be true if the product worked. Then we write how we would measure that. If the page is hard to write, the product is not ready to build — and that is the most valuable thing to learn early.

Find the riskiest assumption

Every product rests on a few assumptions. Users will switch. The data is available. The integration is possible. The model is accurate enough. One of them is the most likely to be wrong and the most expensive if it is. We test that one first — with a prototype, a spike, five interviews or a measurement — before anything else is built on top of it.

Then choose the technology

By now the technology question is much easier, because it has constraints: the scale we actually expect, the latency that matters, the team that will run it, the budget it has to fit. Our default is proven and boring — a relational database, a well-understood language, managed infrastructure — and we choose something novel only when it pays for itself.

Keep the first version small and real

The first version should be the smallest thing that solves the problem for real users in real conditions. Not a demo, not a mock-up behind a login. Small and real teaches more than big and imagined.

Write down the decisions

Each important decision gets a short record: the context, the options, the choice and why. Six months later, when someone asks why the system is the way it is, the answer is a link, not a memory.

This order is slower for the first two weeks and much faster for the next two years. It is also how a theory becomes a product: hypothesis, model, experiment — and only then, the build.