Architecture is a product decision

Architecture usually gets framed as the part that comes after. The product is decided, then someone technical works out how to build it. For the small decisions that is roughly true. For the ones that matter, it is exactly backwards.

The choices that shape a product’s future are not really about technology. They are about what should be cheap to change, what should be hard to get wrong, and where the business wants to move fast next. Those are product questions. They just happen to be answered in code.

Take a concrete one. The core of Tenderoo is a score: how well a public tender fits your business, from zero to a hundred. I could have got a good-looking number out of a single model call and moved on. Instead the score comes from a fixed rubric, six factors, each judged and weighted the same way every time. That is slower to build and less clever. But it decides something a demo never shows: whether “show me why this scored 78” can ever exist. A black box can’t be audited. A rubric can. The architecture and the product feature are the same decision, made once, early, and hard to reverse later.

The decisions that matter most are product decisions wearing a technical costume.

That is the pattern. Where you put the seams decides which changes are a morning’s work and which are a rewrite. Choosing to keep a source under every answer, or to let a system refuse when it has no grounds, is not a technical nicety. It is a decision about what the product is allowed to say, and it belongs to whoever owns the product.

So make those decisions in product terms. Start from the outcome and work back to the smallest set of choices that get there. Ask what you expect to change, and make that cheap. Ask what would be expensive or dangerous to get wrong, and make that deliberate. The diagram falls out of those answers, not the other way round.

A clean design a team can't own is worse than a slightly messy one they can.

There is one more thing that never makes it onto the diagram: the people. A clean architecture the team can’t actually own and run is worse than a slightly messy one they can. The delivery model, who builds it and how they work, is part of the architecture whether you drew it or not. That is its own essay.

None of this means architecture stops being technical. It means the important calls are made in service of the product, revisited as the product’s needs change, and never handed off as though they were someone else’s problem. Architecture is a product decision. The sooner it is treated like one, the fewer expensive surprises later.