You are starting a greenfield platform. How do you establish what the architecture must satisfy before designing anything?

Separate three different things first

Requirements can be traded against one another. Constraints cannot — a design violating one is not a trade-off but a failure. Assumptions are things being treated as constraints without confirmation, and confirming them frequently unlocks a much better design.

Conflating these wastes weeks exploring options that were never available.

Discover the constraints, because they are not volunteered

Work through the categories deliberately:

Regulatory — data residency, retention, auditability, sector rules. These bound the solution space more sharply than any technical consideration and are ruinous to retrofit.

Organisational — approved technologies, existing vendor agreements, the skills of the team who will operate it, procurement lead times, the release calendar.

Technical — systems that must be integrated with and cannot change, protocols fixed by a partner.

Commercial — budget, timeline, commitments already made to customers.

Turn quality attributes into scenarios

"Performant", "secure", "scalable" cannot be designed for, tested, or traded off. Scenarios can.

Build a utility tree: quality attributes as branches, refinements beneath, and concrete scenarios as leaves — each with a stimulus, an environment and a response measure. "During the annual sale, at five times normal traffic, checkout completes within 500 ms at p95."

Rate each leaf on business importance and technical difficulty. The high-importance, high-difficulty ones are where architectural analysis is worth spending, and there are usually fewer than ten.

Filter to what is architecturally significant

The test: would satisfying this change how the system is decomposed, deployed or connected? If not, it is an implementation concern.

Architectural attention is scarce. The set that actually drives the design is typically five to fifteen items — a few key quality attributes, the non-negotiable constraints, and a handful of functional requirements whose difficulty is structural.

Surface the conflicts explicitly

The utility tree makes them concrete rather than vague: security controls that add latency; availability mechanisms that weaken consistency; auditability that constrains data deletion; low latency that conflicts with data residency.

Resolve these with the business, not in engineering. They are priority decisions, and making them silently in a design is how an architecture ends up satisfying no stakeholder.

Close the loop so the work does not become an artefact

The scenarios become the acceptance tests, fitness functions and SLO definitions. That is what stops a requirements exercise producing a document nobody revisits.

And record the decisions with rationale, in ADRs — including the options rejected and why, because the rejected options are what future readers actually need.