Constraints Shape Design
Which of your options were never really available?
The idea
Explicit constraints prevent solutions that work only in theory.
In the real world
Shared hosting favors a simple PHP deployment.
Going deeper
Constraints do not become negotiable by being discovered late. A design requiring a persistent background worker on hosting that cannot run one is not a design with a problem; it is not a design.
Stating them first converts a failure at the end into a boundary at the start, and boundaries are generative — they eliminate whole branches of the solution space quickly, which is why designers who work within tight constraints often produce better work faster. The constraints worth writing down are the environmental, regulatory and organisational ones, since technical limits usually surface on their own.
Where it stops applying
Constraints assumed rather than verified can rule out good options unnecessarily. It is worth checking which are actually fixed and which are inherited assumptions nobody has tested.
Why it matters
Stating constraints early rules out designs that only work in an environment you do not have.
Try this today
List budget, time, skill, and platform constraints.
Test yourself
A team designs a system needing a persistent background worker, then discovers the hosting is shared with no long-running processes. When should this have surfaced?
Show the answer
Before the design, as a written constraint. Environment limits do not become negotiable by being discovered late; naming them up front turns them from a failure at the end into a boundary the design is built inside.
Learn this in the feed Answering from memory, then again days later, is what makes it stick.