Read a sample of internal design documents and count the numbers in them. Some numbers come from the business: four nines, two-week cycles, a compliance deadline. Other numbers come from somewhere stranger. They come from the tool's documentation.
The work-tracking design says eight levels of nesting because the tool supports eight levels of nesting. The review checklist has five severity tiers because the template shipped with five. The folder hierarchy goes seven deep because the file system was comfortable at seven. Ask the room why eight, and the answer is a link.
A limit described a ceiling. Somewhere between reading the docs and writing the design, it became a floor. The team measured its ambition against what the tool permitted, and the tool's ceiling quietly turned into the design's target.
How a limit becomes a requirement
The mechanism is legibility. Limits are vivid, numbered, documented, and easy to cite; requirements are vague, unwritten, and hard to cite. When a design document needs a number, the tool's number is the nearest one at hand, and citation feels like rigor.
So the number migrates. It starts as "the tool supports up to eight," passes through "we can have up to eight," and settles as "we will have eight." Each step is small. Nobody approves any of them, which is the defining feature: this is a decision that happens to a team rather than by a team. The design then grows to fill the available shape, because available shape invites use, the way a large board invites more columns and a deep tree invites one more parent.
The tell is simple, and it works on any design document: every number should trace to a question the team actually asked. Four nines traces to "what does downtime cost us." Eight levels traces to nothing. It is ambient, inherited from the tool the way defaults are inherited, and What the Spec Doesn't Decide, the Model Will names the general pattern: whatever the design leaves undecided, something else decides, and here the something is the tool's feature table. The tool's shape becomes the system's shape without ever passing through judgment.
There is a mirror error, and honesty requires holding it: sometimes a limit is the requirement. When the constraint is real, "the tool does X" is exactly the information the design needs, and designing to the tool is not weakness but fit. The failure is not using the tool's numbers; it is using them without knowing which of them are answers and which are ambient. The trace test is the whole discipline.
The deepest costs are paid downstream
Designing to limits does its damage after launch, in three installments.
First, the shape locks in. Structures built to a tool's ceiling become load-bearing: eight levels of nesting means every item carries seven ancestors, and every filing decision now traverses a chain the team never argued for. This is the mechanism behind The Roadmap and the Codebase Are Different Trees: a tracker fused into a deep chain because the tool offered one, and depth bought ahead of demand is ceremony with a maintenance bill.
Second, migration gravity. A design shaped exactly like the current tool is expensive to move to any other tool, because the shape no longer encodes the team's needs, only the incumbent's capabilities. The tool-specific design is a moat the team dug around itself, for free, facing inward.
Third, judgment atrophy. A team that designs by citation stops practicing the harder skill: deriving structure from questions. The Stack Is Not the System draws the boundary, and Good Architecture Tracks Decisions Across Unfolding States describes the alternative habit, decisions recorded as decisions, with the question attached. A design full of ambient numbers has no decisions in it to track. It is a receipt, not an argument.
What this is not
Not a case against using capable tools, nor against honest constraints. Tools should inform designs constantly; the argument is about the direction of authority. The design asks questions, the tool answers some of them, and the tool's unanswered features stay features. Fit is not the failure. Untraced fit is.
Not a demand that every number be justified from first principles. That produces its own theater. The trace test is cheap: for each number in the design, name the question it answers. Real requirements survive the naming in one sentence. Ambient numbers produce a sentence about the vendor.
And not a claim that shallow is always right. Sometimes deep structure is the honest answer to a real question about containment and ownership. Depth earned by a question is design. Depth inherited from a documentation page is sediment, and Every Taxonomy Needs a Death Rule will eventually have to bury it.
The move
Run the trace test on the next design document before it is approved:
- Circle every number and named shape: levels, tiers, fields, columns, thresholds.
- For each, write the question it answers, in one sentence, next to it. If the sentence names the team's reality, the number is a requirement.
- If the sentence names the tool, the number is ambient. Either find the real question it should answer or delete it, and let the design shrink to what was actually decided.
- Do the same pass on one existing structure. Expect to find at least one dimension of your current system that exists because a vendor permitted it.
Take-home
- Open your team's most recent internal design document and trace three numbers to their questions. The ones that trace to documentation instead of need are decisions the vendor made for you.
- Treat "the tool supports X" as an answer hunting for a question. Adopt it only when the question exists and is written down.
- Design documents should contain decisions, not receipts. A number without a question is a receipt.
Related reading:
- What the Spec Doesn't Decide, the Model Will
- The Roadmap and the Codebase Are Different Trees
- The Stack Is Not the System
- Good Architecture Tracks Decisions Across Unfolding States
- Every Taxonomy Needs a Death Rule
- Never Hand-Maintain What the System Can Derive
If your structures trace back to feature pages more often than to questions, the designs are being written by the vendors. If you want help reinstalling the question-before-number habit before the next tool locks its shape in, book a discovery call.
FAQ
Why do teams design to tool limits?
Because limits are legible. They are numbered, documented, and easy to cite, while real requirements are vague and unwritten. When a design needs a number, the tool's number is nearest, and citing it feels like rigor. The limit then migrates from "the tool supports up to eight" to "we will have eight" without any step being approved.
How do you tell a real requirement from an ambient one?
Trace every number in the design to the question it answers, in one sentence. A real requirement names the team's reality: downtime cost, compliance deadline, user volume. An ambient number names the tool or vendor. If the sentence is about the documentation you read, the number was inherited, not decided.
What does the trace test look like in practice?
Circle every number and named shape in the design document, levels, tiers, fields, thresholds, and write the question each one answers beside it. Requirements survive the sentence immediately. Ambient numbers produce a sentence about the vendor and get deleted or replaced by the real question. Run the same pass on one existing structure to find dimensions that exist only because a tool permitted them.
Is designing around a tool's capabilities ever correct?
Yes, when the capability genuinely answers a question the team asked. Tools should inform designs constantly; the issue is the direction of authority. "The tool does X" is an answer hunting for a question. Adopt it only when the question exists, is written down, and would survive the tool changing.