You make a build-vs-buy call on a Tuesday afternoon. The team debates for an hour, someone draws a comparison matrix on a whiteboard, and you commit. Six months later the decision is load-bearing infrastructure. Nobody remembers why you chose it, but everyone assumes someone did the math.
Here is the part nobody warns you about: the math changes. Usage patterns shift. Your team doubles or shrinks. The vendor updates pricing. The internal tool that was "good enough" starts eating two days of engineering time a month in maintenance. Build-vs-buy is not a decision you make once. It is a decision you keep making, whether you realize it or not.
The initial build-vs-buy conversation happens under specific conditions: a known team size, a rough estimate of load, a current vendor landscape, and a set of assumptions about what "done" looks like. Every one of those inputs has a shelf life.
Think of it like signing a lease. The apartment was right for you when you moved in — close to the office, enough space, reasonable rent. A year later you work remotely, you have a second kid, and the landlord raised rent 20%. The apartment didn't get worse. Your context changed.
The same thing happens with engineering decisions. You built an internal notifications system when you had three event types and one channel. Now you have twelve event types, four channels, and a backlog of delivery reliability bugs nobody wants to own. The original decision was sound. It just expired.
Most teams only revisit build-vs-buy when something breaks — an outage, a surprise invoice, or an engineer rage-quitting over a codebase nobody wants to touch. By that point switching cost is high and the conversation is emotional rather than analytical.
The less obvious cost is the re-evaluation you never schedule at all. The internal tool keeps working, sort of, so it never triggers a crisis. Meanwhile the team spends a slow drip of hours on maintenance, workarounds, and onboarding new engineers to a bespoke system. That time is real. It just never shows up as a line item.
Bought solutions have a mirror version of this problem. You sign an annual contract, the vendor ships features you don't need, deprecates features you depend on, and adjusts pricing. You absorb each change individually because none of them is bad enough to trigger a migration. But the cumulative drift adds up.
You don't need a committee. You need a calendar event and three questions.
1. What changed since the last evaluation?
Look at four inputs: usage volume, team capacity, total cost of ownership (including engineering hours), and the current vendor or open-source landscape. If none of them moved meaningfully, keep going. If two or more shifted, dig deeper.
2. Where is the maintenance burden landing?
Built solutions concentrate maintenance on your team. Bought solutions concentrate dependency on someone else's roadmap. Neither is inherently better. But you should know which engineers are carrying the load and whether that load is growing. If your best people are spending their sharpest hours babysitting infrastructure a vendor handles as a commodity, that is a signal.
3. What would we choose if we were starting today?
This is the most clarifying question and the hardest to answer honestly. Sunk cost makes the current path feel inevitable. Strip that away. If a new team inherited this system tomorrow with no history, would they keep it or replace it? If the answer is "replace it," you have identified tech debt — even if the original decision was correct.
Quarterly is too often for most components. Annually is too infrequent for anything that touches customers directly. A reasonable default: revisit high-impact build-vs-buy decisions every six months, and trigger an unscheduled review whenever usage doubles, the team changes by more than 30%, or the vendor changes pricing or ownership.
Put it on the calendar. Assign an owner. Spend 90 minutes. Write down what you decided and why. That written record is half the value — it means the next review starts with context instead of archaeology.
Frequent re-evaluation does not mean frequent migration. Most reviews should end with "stay the course." The point is to make that a conscious choice rather than an accident of inertia.
The teams that handle this well share a trait: they treat technical decisions like hypotheses, not commitments. A hypothesis stays valid until the evidence changes. When the evidence changes, you update the hypothesis — not because the original was wrong, but because you learned something.
Yesterday's right call becomes today's tech debt quietly, gradually, and without announcing itself. The only defense is to keep asking the question.
Be the first to comment.
0 comments
Loading comments...