Boundaries before features
A feature built across a broken boundary costs more later than it saved — and why we spend two weeks on something that never appears on screen.
What slows a project is rarely the difficulty of its features. It is that they get built across a boundary nobody agreed on. Once a feature crosses a vague line, every later change becomes a negotiation.
So we spend two weeks designing boundaries before the first line: who owns which data, what happens when the other side falls over, and how a failure reads. This is not a document — it is contracts in the code.
The cost is visible and the return is not, until the first change arrives. Then the difference is between an edit in one file and a rewrite across five.
MORE
Read next
Arabic is not mirrored English
What we learned building bilingual interfaces that genuinely work in both directions.
Read moreNo model without an eval gate
How we stop a model reaching production before it proves it beats the one already there.
Read moreBoundaries before features
A feature built across a broken boundary costs more later than it saved — and why we spend two weeks on something that never appears on screen.
Read moreReady to start?
One free hour, and you leave with a scope, a cost range and a timeline.