Build vs. Buy: When an Internal Tool Beats Commercial Software
"Build vs. buy" gets argued as a matter of taste. It isn't. It's a decision with a defensible answer most of the time, if you ask the right questions in the right order.
Start with what's actually core
Buy the things that are hard, commoditized, and not your differentiator — email, the operating directory, the database engine. Nobody should be writing their own identity provider. The question is only ever about the layer on top: the glue, the workflow, the integration that's specific to how your organization actually runs.
Three questions that decide it
- Does a product fit the workflow, or would we bend the workflow to the product? Bending the org to fit a tool is a cost most buyers never price in.
- What's the real total cost of the commercial option? License plus implementation plus the services to keep it configured. For a lot of governance and automation tooling, that's six figures a year and a multi-month rollout.
- Can a focused internal build cover the part that matters in weeks, not quarters? If the valuable 80% is a well-scoped integration, building it is often cheaper, faster, and a perfect fit.
The hidden asset: you own it
When you build, the institutional knowledge stays in-house, the roadmap is yours, and there's no renewal negotiation where leverage quietly shifts to the vendor. The flip side is real: you own the maintenance too. So build things that are stable in scope and central to your operation, and buy the things that churn or sprawl.
A bias toward building — with discipline
My instinct leans toward building, because the things I tend to need are exactly the org-specific glue that products fit poorly. But the discipline matters: build narrowly, document clearly, and be honest about what you're signing up to maintain. Done that way, an internal tool isn't technical debt — it's leverage.