An architect must choose between the correct design and the one that ships in time. How should pragmatism be exercised without accumulating unmanageable debt?

The framing

Not "correct versus hack" but which decisions are expensive to reverse. Ship fast on everything cheap to change; do not compromise on the small number of things that are not.

Do not compromise: the data model and the meaning of core entities · the tenancy or partition key · identity and permissions · a public API contract given to customers · anything a regulator will examine. Getting these wrong means a migration rather than a refactor.

Compromise freely: service boundaries, caching, queue technology, internal structure, most performance work, admin tooling, anything replaceable behind an interface.

What must accompany the compromise

• An explicit record of what was deferred and why, with an owner and a trigger. Undocumented shortcuts become permanent because nobody remembers they were shortcuts.
• A containment boundary, so the fast version does not spread. A shortcut behind an interface is replaceable; one that three other teams have built on is architecture.
• A capacity check, because the fast version must survive what it was built for. Shipping something that fails during the event it was rushed for is the worst of both outcomes.
• The rework scheduled with a date before the fast version ships, not afterwards when the pressure is off and the next deadline has arrived.

The conversation to have

"Six weeks with these specific limitations, or six months without them." Naming the limitations concretely — this will not support more than X, this will need rework before Y, this will cost more to operate — makes it a business decision with known consequences.

Engineering loses this argument when it presents a binary, because a binary against a revenue deadline always resolves the same way and engineering's credibility is spent doing it.

The judgement that distinguishes good pragmatism

Knowing which category a decision falls into, which requires understanding the reversal cost rather than the apparent importance. An architect who compromises on the schema to save two weeks and agonises over the service boundary has the classification exactly backwards — and that is the most common expensive mistake in a fast-growing company.