A major US TV network came to ML LABS holding a quote to build a full software system for a workflow that did not require one. The technology in the quote was sound and a competent vendor would have delivered it. The mistake was upstream of all of that: nobody had asked which parts of this actually have to be built, and by the network's own reckoning the answer to that question was worth two hundred thousand dollars.
"Omar delivered in two weeks what our team estimated would take six months. The scoping session alone saved us from a $200K mistake."
— AI Program Manager, a major US TV network
That is the cost of the build-everything reflex at the scale of a whole system. The same reflex operates one level down, inside products that are already justified, and it is quieter there: a team commits to the right product and then spends its scarcest months rebuilding components the market solved years ago. Every commodity feature built by hand is time not spent on the reason the product exists — and unlike the network's quote, nobody sends an invoice that makes the loss visible.
ML LABS builds and operates Izer, a presentation product in the internal portfolio at Escape Velocity Labs, a sister practice under the same owner. Its core is unusual — a deck is a URL, not a file, so it edits in place and shares as one always-current link. Its periphery is deliberately unbuilt, and the most consequential engineering decision in the product is a thing it does not have.
Name The Core, Rent The Rest
Izer has no comment store. Per-slide comments federate to Revws, a reviews-and-ratings product in the same portfolio, and the refusal is not a judgment call made fresh each sprint — it is written into Izer's codebase as a standing rule: per-slide comments are handled by Revws, we don't build comments.
A rule in the code outlives a principle in a strategy document, because the document is not in the room where the decision actually gets made. The room is a ticket that begins "it would only take a week to…", and the answer has to already be there.
The line that rule enforces is the one every product has and few draw explicitly. The differentiated core is the reason the product exists, and it gets all the invention. The periphery is everything a competent product happens to need and no user chooses you for.
- The core gets original engineering, and none of it is outsourced — for Izer that is decks that live at a URL, edit in place, and share as one link that cannot go stale.
- The periphery is anything a good third party already solves: commenting, identity, payments. Borrow it and move on.
- The test is blunt: if building it yourself would not make the product more differentiated, you are spending your scarcest resource on someone else's solved problem.
This is the buy-versus-build decision applied at the component level rather than the product level, and it is the same decision the companion piece on building versus buying AI capability works through at the scale of a whole system. The distinction between the essential complexity that is the product and the accidental complexity that is not (Computer, 1987) is the right lens for both: pour effort into the essential, refuse to manufacture the accidental.
The Seam Is Real Engineering
Borrowing is not free. It moves the work from building the feature to designing the seam where the feature attaches, and the seam is where a composed product either feels whole or feels like a mashup.
Izer's seam is an identity problem, not a UI one. Revws has to know who is posting a comment, and Izer cannot ask a viewer to hold an account in a second product just to leave a note on slide four. So Izer mints a federated token for each viewer — a signed assertion of who this person is, issued by the product that already knows — and Revws verifies it and trusts the claim. Izer never becomes the comment store, and Revws never becomes Izer's login. The token is the entire treaty between them — a narrow, explicit contract at the one place where two models meet, which is precisely what keeping bounded contexts from leaking into each other (Fowler, 2014) asks a seam to be. The design that carries trusted identity across a boundary you do not control is that seam described from the other side, and it is real engineering rather than plumbing: a minted credential is an attack surface, and the category of identification and authentication failures (OWASP) is a standing catalogue of how composed products get compromised.
The rest of the seam is manners. A borrowed component has to be themed so it does not look bolted on, loaded so it does not stall the page it lives in, and — the part that gets skipped — contained so that its bad day is not your bad day. A comments outage should degrade to a deck without comments, never to a broken deck. The discipline of designing for graceful degradation under partial failure (Google, 2016) is what separates a composed product from a fragile one. You borrow the feature. You still own the fallback.
When Rented Drifts Into Core
Composition trades build cost for dependency risk, and the trade is real. Every borrowed component is a third party whose uptime, pricing, and roadmap belong to someone else, and a product assembled entirely from rented parts has no floor under it. That is the honest counterweight, and it defines the boundary where this whole strategy inverts.
The boundary arrives when the thing you rented drifts into your core — when the feature you did not build becomes the feature you are chosen for, or when a dependency's limitation starts deciding your roadmap. At that point the calculus flips: the component you were right to borrow is the component you now have to own. The failure is symmetrical, and both halves are expensive. Cling to a borrowed component after it has become core and a third party governs your differentiation; rebuild a component that was fine to rent and you have spent the network's two hundred thousand dollars on a smaller scale, out of a reflex to control everything.
The skill is not making the call correctly once at the start. It is re-running it as the product's center of gravity moves, and being willing to bring a component in-house one seam at a time rather than in a rewrite — the strangler-fig approach of replacing a system incrementally from its edges (Fowler, 2004) is the mechanism that makes reclaiming a rented component survivable.
First Steps
- Write your differentiated core in one sentence. Everything the sentence does not contain is a build-or-borrow decision, and the default for all of it is borrow.
- For the components you borrow, design the seam on purpose — scoping, identity, theming, and what the product does on the borrowed component's worst day. Budget the seam as engineering, because it is.
- Put the refusal somewhere it will be enforced. A rule in the codebase survives the sprint planning where a principle in a strategy document does not.
Draw The Line Before Building
The durable strategy concentrates original engineering on the core and rents the rest, then spends a serious fraction of the savings on the joins. That is what lets a focused team ship a coherent product without drowning in commodity work — not by building less carefully, but by building carefully only where building changes the outcome. A product is defined as much by the things it refuses to contain as by the things it does.
Which means the line itself is the deliverable, and it is worth buying before the build rather than discovering after it. Drawing that line — what is core, what is rented, where the seams go, and what the whole thing should therefore cost — is the entire content of an AI scoping session: a written plan with scope and a budget range, a go or no-go recommendation with the reasoning attached, and one clear next step, at $750 credited against the work if the work goes ahead. As the network above found, the recommendation is sometimes that a large part of the system should not be built at all — and if you have not yet chosen which workflow deserves a product in the first place, the companion piece on identifying your first AI use case is the question that comes before this one.
References
- Brooks, F. No Silver Bullet: Essence and Accidents of Software Engineering. Computer, 1987.
- Google. Monitoring Distributed Systems. Site Reliability Engineering, 2016.
- Open Worldwide Application Security Project. OWASP Top Ten. OWASP.
- Fowler, M. StranglerFigApplication. martinfowler.com, 2004.
- Fowler, M. BoundedContext. martinfowler.com, 2014.
