Constraints
Seven questions decide the design more than most requirements do: how much time, how many users, how much data, which technologies I know, which I must use, what budget, what law. Ask them before the diagram, because a design made without them is made for a project that does not exist.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
What do you need to know about the situation — not the problem — before any design decision is honest, and what happens to a design that skips those questions?
The store's requirements are on the canvas. You start sketching the architecture and every choice has two good answers: managed database or self-hosted, one service or three, a framework you love or one the team knows. Nothing in the requirements breaks the tie, and you pick by taste.
Design the "right" architecture: the one you would build with no limits, the one that would survive growth, the one from the conference talk. Constraints feel like compromises to be applied afterwards, when reality intrudes.
The right architecture takes longer than the time there is. Three services, an event bus and a proper CI pipeline are correct and take four months; the founder needed a store in six weeks; the compromise is made under pressure in week five, badly.
- The right architecture takes longer than the time there is. Three services, an event bus and a proper CI pipeline are correct and take four months; the founder needed a store in six weeks; the compromise is made under pressure in week five, badly.
- It is built in a technology one person knows. When that person is away, nobody can deploy it; when they leave, the store is a liability with a domain name.
- It ignores the law. Customer addresses and card data are handled the convenient way, and the first question from a regulator, a bank or a marketplace partner cannot be answered.
- It costs more to run than the store earns. A managed everything at every tier is an excellent architecture for a business with revenue, and this one has none yet.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Before choosing anything, ask seven questions about the situation the design will live in, and write the answers next to the requirements: how much time until it must work; how many users, now and plausibly; how much data, and does it grow with users or with time; which technologies the people building it actually know; which technologies are imposed — by a contract, a partner, an existing system; what budget, to build and to run; and which laws, regulations and security obligations apply to the data and the money. Each answer removes options, and a design with fewer options is easier to make and easier to defend.
- Treat each answer as a fact that decides something specific, not as a mood. "Six weeks" decides that anything needing more than six weeks is not V1. "Two developers who know Postgres" decides the database unless something else overrides it. "Customers in one country" decides that multi-region is refused with a trigger. Write the decision next to the constraint that made it.
- Separate hard constraints from soft ones. A hard constraint cannot be negotiated — a launch date tied to a contract, a law, a partner's API. A soft one is a preference dressed as a constraint — "we must use the framework I know" is soft if there is time to learn; "we must use the payment provider we have a contract with" is hard. Knowing which is which tells you where to push back and where to comply.
- Revisit the constraints when they change, because they will. The team grows, the budget arrives, the user count jumps, a second country appears. A design that wrote its constraints down knows which decisions were made because of which constraint, and can change the right decision rather than everything.
Seven questions and what each decides
The matrix is the store's constraints as they went onto the canvas. The last column is the one that turns a list into a design input — a constraint that decides nothing is not yet understood. Hard and soft are marked because the two are treated differently: hard ones are complied with, soft ones are negotiated.
| Constraint | The store's answer (source) | Hard / soft | What it decides |
|---|---|---|---|
| Time | Working store in six weeks (launch tied to a trade show) | Hard | Monolith; framework admin scaffolding; nothing that takes longer than the deadline is V1 |
| Users | Tens a day at launch, plausibly hundreds (marketing plan) | Soft — an estimate | One server, one database; scaling refused with a measured trigger, not a planned one |
| Data | Hundreds of products, orders grow with time, images are the large thing (the existing product list) | Soft — will grow | Images to object storage from the start; everything else in one database |
| Known technology | TypeScript backend and Postgres, both developers; one knows the chosen frontend framework | Soft — can be learned | TypeScript and Postgres; the framework with a week of learning for the second developer, written as a risk |
| Required technology | Payment provider fixed by an existing contract | Hard | Hosted checkout fields; the provider's webhook model shapes the payment states |
| Budget | A small monthly hosting ceiling until revenue exists | Hard for now | Smallest managed database tier, one application server, object storage; anything else needs a revenue trigger |
| Legal / security | Customer data under one jurisdiction's data-protection rules; card data never on our servers | Hard | Addresses stored in-jurisdiction; a deletion path in V1; hosted card fields — cannot be retrofitted cheaply |
The constraints nobody could answer yet
Some of the seven come back as "we don't know". That is fine as long as the unknown becomes a question with an experiment or a conversation, because a constraint that stays vague is a constraint that is silently decided by the default. The board shows the store's three.
- ✓Six weeks, hard, from the founder.
- ✓Payment provider fixed by contract; hosted fields available in its test mode.
- ✓Card data must never touch our servers.
- ~Customers are in one jurisdiction in V1 — written so that a second country is a constraint change, not a surprise.
? How many users?
becomes What is a plausible daily order count in the first month, and what traffic does one order imply — and at what measured traffic does the single server stop being enough?
experiment Take the marketing plan's number, halve it, and load-test the walking skeleton at ten times that to find where the server actually bends; set the scaling trigger there.
? What is the budget?
becomes What monthly hosting cost is acceptable before revenue, and does that ceiling include the payment provider's fees or only infrastructure?
experiment Cost the smallest managed tier of each piece the design needs and put the total in front of the founder as a number, not a category.
? What does the law require?
becomes Which data-protection rules apply to storing customer addresses and order history in this jurisdiction, and do they require a deletion or export path in V1?
experiment Half a day reading the actual rules that apply, then a list of the data fields the store holds and the obligation attached to each — reviewed by whoever owns legal for the business.
None of the three delays the walking skeleton. Each has an experiment small enough to run this week, and each decides something the design will need before launch.
Hard, soft, or not a constraint
The decision below is what to do with each answer once it exists. The three options are not ranked; the criteria are what matter, and the cost column is what each choice commits you to.
Is this a hard constraint, a soft one, or a preference?
when It comes from a contract, a law, a partner's system or a date the business cannot move; relaxing it is not within the team's power.
cost Options removed for good; a design that must fit rather than one that is preferred. The gain is a smaller decision space and a defensible reason for every choice it forced.
when It comes from an estimate, a preference or a current state that could change — a user count nobody has measured, a framework one person likes, a budget that revenue will lift.
cost A conversation, and a decision that carries a risk note; the gain is room that a team treating everything as hard never finds.
when It decides nothing specific about the design, or it was inherited from another project's situation — "we always use the cluster" when there is no cluster.
cost Admitting that a habit was not a requirement, which some people find harder than complying with it.
How to do it
Most important first.
- Add the seven constraints to the canvas beside the requirements, one line each, with a source: who said six weeks, where the user estimate came from, which law was checked (The Unknowns Board holds the ones nobody can answer yet).
- Next to each constraint, write what it decides. If a constraint decides nothing, it is either not a constraint or you have not thought about it enough.
- Mark each as hard or soft, and for soft ones write what it would take to relax it (Time, Users, Data, Known vs Required Technology).
- Check every architectural choice against the list before making it: does the time allow it, does the team know it, does the budget run it, does the law permit it (Constraints Shape Architecture).
- Put a date on the constraints and re-read them when the project changes shape. A constraint that has lapsed is still deciding things until it is crossed out.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The store's seven answers. Time: a working store in six weeks, because the founder has a launch tied to a trade show — hard. Users: tens a day at launch, plausibly hundreds; the founder's marketing plan says so — soft, an estimate. Data: a few hundred products, orders growing with time, images the biggest thing — measured from the product list they already have. Known technology: two developers, both comfortable with a TypeScript backend and Postgres, one knows a particular frontend framework. Required technology: the payment provider is fixed by an existing contract — hard. Budget: a small monthly hosting ceiling until revenue exists — hard for now. Legal: customer data in one jurisdiction with its data-protection rules; card data must never touch our servers — hard.
- What each decided. Six weeks: no separate services, no event bus, no custom admin — a monolith and the framework's admin scaffolding. Tens of users: one server, one database; scale refused with a trigger. Data: images to object storage from the start because they are the only thing that will be large. Known technology: TypeScript and Postgres, because both developers can deploy and debug it; the frontend framework one of them knows, with a note that the other has to learn it in week one. Required provider: hosted checkout fields, which also settles the card-data law. Budget: managed database at the smallest tier, one application server, object storage — costed against the ceiling. Legal: addresses stored only in the jurisdiction, a deletion path for customer data in V1 because the law requires it and it cannot be retrofitted cheaply.
- The soft ones were pushed on. The frontend framework preference: the developer who knows it argued for it; the constraint was soft, the time was hard, and one week of learning was affordable, so it stayed — written as a decision with a risk. The user estimate: nobody believed the marketing plan, so the trigger for scaling was set on measured traffic rather than on the plan.
- The design that came out is unremarkable, and that is the point: a monolith, one database, object storage, a hosted payment page, deployed on one server with backups. Every piece of it can be traced to a constraint, and every constraint that decided something has a date beside it.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Seven constraints are written beside the requirements, each with a source and a hard/soft mark.
- Every architectural choice can be traced to at least one constraint, and the tie-breaks that were "taste" have become decisions with reasons.
- At least one soft constraint was pushed on and either relaxed or kept deliberately.
- The design is less ambitious than the one you would have drawn without the list, and you can say which constraint removed which ambition.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?How much time, how many users, how much data, which technologies do we know, which are imposed, what budget, what law — and what is the source of each answer?
- ?What does this constraint decide, specifically — and if it decides nothing, is it really a constraint?
- ?Which of these are hard, which are preferences in disguise, and what would it take to relax a soft one?
- ?Which decisions in the current design were made because of a constraint that has since changed?
What can go wrong
- Constraints are collected and then the design is drawn anyway. The list is decoration; the architecture is the conference one; the compromise comes in week five as before.
- Every preference is recorded as a hard constraint. "Must use the framework I know" and "must launch by the trade show" are given equal weight, and the team cannot tell where it has room to move.
- The constraints are frozen at the start. The budget doubles, the team triples, and the design still refuses a second server because a lapsed constraint was never crossed out.
- The move is applied as an excuse. "The constraints forced it" is used to defend a design that was in fact chosen by taste and rationalised afterwards; the tell is that the constraints were written after the diagram.
- A design shaped by constraints is less impressive than the one from the talk, and some engineers experience that as a loss rather than as fit.
- Asking about budget and law before designing produces conversations with people outside engineering that many teams would rather postpone — the postponement is what the reflex buys.
- Constraints written down are constraints that can be argued with; a design made by taste has no list to point at, which makes it harder to challenge and easier to defend badly.
- "Constraints are what stop us doing it properly." Constraints are the description of the situation; "properly" means "fits the situation". A four-month architecture for a six-week project is not proper, it is late.
- "Constraints and requirements are the same list." A requirement says what the system must do; a constraint says what the situation permits. The Software Engineering & Design domain's Constraints lesson treats them as inputs to shaping code; this lesson is about surfacing them at all.
- "Once the constraints are known the design is determined." They remove options; they do not pick one. Two designs can fit the same seven answers, and the choice between them is where judgment and Trade-Off Thinking come in.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALTime, users, data, known technology, required technology, budget and law are the constraint set for any project; for a library or an internal tool "users" becomes "callers" and "law" is usually "the organisation's policies", and the move is unchanged.
- TEAM-SPECIFICA solo learner with no deadline and no budget has only two hard constraints — known technology and law — and the move is mostly about not inventing the others; a team under contract has all seven hard, and the move is about finding the room that remains.
- ILLUSTRATIVEThe six weeks, the trade show, the two developers and the hosting ceiling are invented to show what each constraint decides; a real store has its own answers and its own sources.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The requirement canvas at /thinking/canvas has a constraints field beside the requirements — fill it before the architecture, not after.