Build vs. Buy: A Decision Framework for the Mid-Market Software Team

Every engineering organization between fifty and five hundred people eventually has the meeting. Someone has scoped a vendor product, someone else has sketched how the team could build the same thing in a quarter, and the debate settles into a groove: license cost versus engineering cost, flexibility versus speed. The meeting usually ends without a decision because the framing is wrong. Build-versus-buy is not primarily a cost question. It is an ownership question, and ownership has a shape that only becomes visible when you look past the first year.

Start with the differentiation test

The first filter is brutally simple: does this capability make your product better in a way your customers can perceive? If the answer is yes — the capability sits on the path between your team and the thing you sell — building deserves serious consideration, because you will want to change it constantly and on your own schedule. If the answer is no, you are contemplating building commodity infrastructure, and the honest version of the proposal is "we would like to run a small, unfunded software company inside this one."

Most internal tools fail the differentiation test. Ticketing, expense workflows, data pipelines between systems you did not write, dashboarding — these are places where being exactly as good as everyone else is the correct ambition.

Price the second year, not the first

The build estimate that reaches the decision meeting is almost always the cost of version one. It rarely includes the on-call rotation, the upgrade work when a dependency ages out, the re-onboarding cost every time the original author changes teams, or the slow accumulation of feature requests from internal users who — reasonably — treat the tool as a product.

A useful discipline: whatever the build estimate is, write down who specifically will own the system in year three, and ask that person whether they agree. If no name can be attached, the estimate is fiction. Vendor pricing, whatever its faults, has the virtue of being a number someone else is contractually obligated to honor.

The integration middle ground

The dichotomy itself is often false. The pattern that works repeatedly in mid-market teams is buy the engine, build the edges: adopt a vendor for the undifferentiated core, and spend your engineering budget on the thin integration layer that adapts it to your workflows — the glue code, the custom fields, the automation between the vendor product and the systems that are genuinely yours. This keeps the maintenance burden of the hard parts on the vendor while preserving the flexibility argument that usually powers the build case.

The warning sign to watch for is when the "edges" start growing inward — when the integration layer begins reimplementing vendor features because someone found the vendor's version annoying. That is a build project wearing a buy project's badge, and it should be re-decided explicitly rather than drifted into.

Reversibility is worth paying for

Whichever direction you choose, the most valuable property is the ability to change your mind cheaply. On the buy side, that means favoring vendors with real data export, avoiding multi-year commitments before the tool has survived one full planning cycle, and keeping your integration layer thin enough to re-point. On the build side, it means writing the internal tool as if you might someday replace it with a vendor — clean interfaces, boring technology, documentation that a future team can inherit.

Teams get into the deepest trouble not by choosing wrong but by choosing irreversibly: the five-year enterprise agreement for a product nobody validated, or the sprawling internal platform that three teams now depend on and no one maintains.

A one-page decision record

Close the debate by writing it down: the differentiation verdict, the year-three owner by name, the total cost of each path over three years, and the exit plan for whichever option wins. The document takes an hour and does two things. It forces the fuzzy parts of the argument into the open before the money is spent, and it gives the team that revisits the decision in two years — and someone will — the context to revisit it well. Most build-versus-buy regret is not about the choice. It is about nobody remembering why it was made.