A retail business needs a new category live before a seasonal peak. Engineering says the correct architecture takes two quarters. How should the trade-off be made?

The framing that produces a good decision

Not "correct architecture versus hack" but which decisions are expensive to reverse and which are not. 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, the public API contract, and 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, and anything that can be replaced behind an interface.

What must accompany the compromise

• An explicit record of what was deferred and why, with an owner and a trigger for revisiting. 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; a shortcut that three other teams have built on is architecture.
• A capacity check, because the fast version must survive the peak it was built for. Shipping something that fails during the event it was rushed for is the worst of both outcomes.

The conversation to have with the business

"We can ship in six weeks with these specific limitations, or in 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 rather than an engineering objection.

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.

The pattern that usually works

Ship the fast version for the peak, with the data model right and everything else provisional, and schedule the rework with a date and an owner before the fast version ships — not afterwards, when the pressure is off and the next deadline has arrived.