Build your own tool or buy one off the shelf? How I run the numbers
Building your own is tempting because the first version looks cheap. Buying is tempting because it works tomorrow. Both instincts can be wrong. These are the five costs I check before I decide anything.
Who it’s forFor CTOs, tech leads and founders who need to decide whether to build an internal tool themselves or buy it as a service.
Most of the “build or buy” conversations I’ve been part of start with the same comparison: a year’s subscription versus two weeks of a developer’s time. On paper, building almost always wins. In practice, it almost never ends at two weeks.
The five costs I count
1. The first version
This is the only cost everyone counts. Usually too low, because we estimate the happy path: no permissions, no error handling, no data migration from the old system.
2. Maintenance
Your own tool has to be updated, patched, monitored and documented. My working rule: every year, maintenance eats roughly a fifth of the effort that went into the first version. That’s not a law of nature, just a heuristic from my own projects. But even if it’s half that, it changes the math.
3. Opportunity cost
The time the team spends on an internal tool doesn’t go into the product. I always ask this directly: what won’t we do during those weeks?
4. Integration and fit
An off-the-shelf tool has costs too: rollout, integrations, training people, and adapting your processes to the tool instead of the other way around. If a process is what sets the company apart, that adaptation may be too expensive.
5. Exit cost
What will it cost to walk away from the solution in three years? With a bought tool: data export, migration, rewriting integrations. With your own: usually less, but only if you take care of a clean data model from day one.
How I put it together
I don’t build an elaborate spreadsheet. A simple three-year table, filled in honestly for both options, is enough.
| Cost over 3 years | Build | Buy |
|---|---|---|
| First version / rollout | team time | rollout time + integrations |
| Maintenance | approx. 1/5 of the first version per year | subscription × number of years |
| Opportunity cost | high | low |
| Fit with the process | full | partial |
| Exit cost | low, if the data is clean | medium or high |
When I build
I build when the tool touches what sets the company apart, when off-the-shelf options would force us to change a process that works well, or when the data is sensitive enough that I don’t want to hand it to an outside vendor.
When I buy
I buy anything that counts as “business infrastructure”: invoicing, email, calendar, a basic CRM. There’s no advantage to build there, only a cost to absorb.
- Decision
- I buy, unless the tool is directly tied to what sets us apart.
- Why
- Maintenance and opportunity cost almost always outweigh the savings on the subscription.
- Costs
- We adapt some of our processes to the tools. We pay subscriptions that grow along with the team.
- Revisit when
- the subscription stops being proportional to the value it delivers, or the vendor blocks access to our data.
The short version
Before you decide, answer one question: who will be maintaining this tool two years from now, and what will they stop doing in the meantime? If you don’t know the answer, you should probably buy.