An organisation's stated principle is "do not build what you can buy". In review it is used to reject an in-house rate limiter for the public API. The vendor option meets every functional need and adds a 40 ms round trip to a request path with a 120 ms p99 budget, and it cannot express the per-tenant burst rules the product sells. The principle is not withdrawn. What did the principle buy the organisation, and what is it now costing?

What the principle bought

Speed, and it was worth paying for. Before it existed, every build-or-buy conversation restarted from first principles, took two weeks, and was decided by whoever argued longest. The principle replaced that with a default, and a default is the cheapest governance instrument there is: it moves the burden of proof onto the person proposing the unusual thing, which is correct most of the time because most of the time buying is right.

What it is now costing

A third of the request budget on every request forever, in exchange for avoiding a component a competent engineer builds in a fortnight. A token-bucket limiter with per-tenant configuration is a few hundred lines and a Redis counter. The trade the principle is forcing is 40 ms of p99 against roughly two weeks of build and an ongoing maintenance obligation — and it is forcing it without anyone having compared the two numbers, because the principle arrived at the review already decided.

The second cost is worse and slower. A principle used as a veto stops being consulted and starts being routed around. Teams learn that the way to build something is not to call it building: they wrap a vendor product they barely use, or they ship the component inside another project where nobody will ask. The principle stays on the wall with a 100% compliance rate and zero influence.

Why this happened: the missing two thirds

A usable principle has three parts, and this one has one. It has a statement. It has no rationale — the reason buying is preferred, which here is that undifferentiated capability should not consume engineering capacity. And it has no implications or exceptions — the conditions under which the rationale does not hold.

Without the rationale, nobody can reason about a case the authors did not foresee, so the only available move is literal application. The rate limiter is exactly such a case: it is on the latency-critical path, and it encodes a rule the company sells, which makes it differentiating by definition.

What I would change, and how I would argue it in the review

Not the statement. Add the other two parts, and make the exception a test rather than a judgement:

Statement. Prefer buying over building. Rationale. Engineering capacity spent on undifferentiated capability is capacity not spent on the product. Exceptions. Build when the component sits on a latency-critical path and the bought option consumes more than 20% of the request budget; or when the component encodes a rule the company sells; or when the vendor's availability target is below the SLO of the service that depends on it.

Then the review is a short factual conversation: 40 ms of 120 ms is 33%, over the threshold, exception applies, build it. The point of the numbers is not that 20% is the correct threshold. It is that a threshold can be met, and a preference cannot.

When holding the line is right

If the same team asked to build an identity provider, a message broker or a metrics store, the principle should hold against every argument they bring, because those are enormous multi-year commitments whose full cost is invisible at proposal time. The size of the thing is what flips it: an exception clause that admits a fortnight of work should not admit a platform.

Common weak answers

• "Delete the principle, principles are bureaucracy." This removes the default and returns the organisation to two-week arguments. The problem is the principle's shape, not its existence.
• "Grant an exception this once." An exception with no stated condition teaches everyone that exceptions are available to whoever escalates hardest, which is a worse governance model than the veto.