You are designing a new order-management service for a mid-size retailer. Four facts about the organisation come up in the first week. Which one changes what you are allowed to design, as opposed to merely making the work slower or less pleasant?

The distinction that decides it

A constraint removes designs from the menu. A cost makes the remaining ones more expensive. Both matter, and conflating them is how architects either over-react to annoyances or walk into a design the organisation cannot operate.

No out-of-hours on-call, permanently, is a constraint, because any component whose failure needs a human decision will not get one for the 15 hours between 18:00 and 09:00. That rules out designs depending on manual failover, on someone draining a queue, or on an operator choosing between two divergent replicas. What remains must fail safe unattended: automatic retry with bounded queues, a degraded read-only mode the system enters by itself, idempotent processing so an overnight backlog of 8 hours can be replayed in the morning, and alert thresholds tuned to what can wait. A system that has run in production for a year without an overnight page is not lucky; it was designed that way.

The cost is paid in the design, not in the roadmap: unattended recovery is a real engineering investment, and it is cheaper than an on-call rota nobody will staff.

Why the other options fail

• Six-week pipeline provisioning. Expensive and fixable, and mainly a reason to batch fewer services rather than to change the architecture. It becomes a constraint only if it is multiplicative: if every new service needs its own six-week wait, a design with eleven services has a year of waiting in it, and then the fact has crossed into constraint territory. Notice the test — does the cost scale with the number of design elements?
• Two engineers dislike the framework. A real management issue and not an architectural input. Treating preference as constraint is how teams end up with three stacks and no depth in any. It would matter if it were skills rather than taste: nobody in the team having written the language before is a genuine constraint on operability.
• Quarterly scope freeze. A batch-size constraint that shapes sequencing and increases the value of reversible decisions. It does not remove a design; it changes what you can commit to and when, which is a planning answer rather than a structural one.

What to do on Monday

Write the operability constraint into the design document as a stated non-functional requirement before proposing components — "no human intervention is available between 18:00 and 09:00" — and review each component against it. Anything that fails the test needs either automatic handling or an explicit, signed-off overnight degradation. Then say out loud what the organisation is buying: not five nines, but a system that does not need waking anybody.

When this is the wrong answer

When the organisation is about to change. If a funded plan exists to staff a rota next quarter, designing everything for unattended operation may sacrifice throughput or simplicity for a constraint that is expiring. Ask when it expires, get the date, and design for the shorter horizon with a stated review point.

And when a constraint is genuinely intolerable — an operation that cannot fail safe and cannot be left alone, such as a settlement cut-off at 02:00 — the correct architectural output is a refusal plus a price. The design does not exist; the cover has to be funded or the deadline moved.