How does knowing a company's business model change your architectural choices?

What is being tested

Whether you can connect commercial context to technical decisions rather than optimising in the abstract.

The same situation, different correct answers

A growth-stage business optimising for market share should favour time to market, accept deliberate debt, buy rather than build aggressively, and tolerate manual processes that would be unacceptable at scale. Optimising unit cost here is optimising the wrong variable.

A margin-focused business at scale should invert most of that: unit cost matters, efficiency work has a direct return, and the same infrastructure decision is evaluated completely differently.

A regulated business has hard constraints — residency, auditability, exit plans — that outrank most technical preferences, and discovering them late is expensive.

A business with a known annual peak should pre-provision, because the date is known years ahead and capacity has lead time. One with unpredictable load must be elastic. Same technical problem, opposite strategy.

A business competing on reliability invests differently from one competing on feature velocity, and the SLO targets should differ accordingly.

What to actually know

• How money is made. Which products, which customers, which margins. Cost per transaction against revenue per transaction is a number an architect should be able to state.
• The current strategic priority, which changes.
• What would seriously damage the business — a regulatory breach, a data loss, an outage at peak, a lost enterprise customer. That list determines where reliability and security investment belongs.
• The seasonality, which is known in advance and changes capacity strategy fundamentally.

How to acquire it

Read the annual report or the board deck. Sit in on sales and support calls — both are dense sources of what customers actually experience. Ask finance how the unit economics work. Ask product what they are optimising for this quarter.

None of this is technical work, and it improves technical decisions more than most technical study would.

What it enables

Arguing in the organisation's currency. "Reduce p99 by 200 ms" is an engineering statement. "Reduce checkout latency, which our funnel data suggests moves conversion by roughly 1% per 100 ms, worth approximately £X" is a business case.

Same work. Only the second gets funded.