Build vs. Buy: A Decision Framework for Internal Tools

Every growing company eventually hits the build-vs-buy question. Your team outgrows the spreadsheet. The off-the-shelf tool doesn't quite fit. Someone says "we should just build our own" and the debate begins.

I've been on the building side of this equation for years, making custom internal tools for companies between 20 and 500 people. (If you're curious about our stack, we wrote about modern web development tools separately.) I have a bias toward building, and I try to be honest about that. Because most of the time, buying is the right answer. The cases where building wins are specific and predictable.

When buying wins

If the problem is common and your workflow isn't unusual, buy. Project management, basic CRM, email marketing, HR management, accounting. If your requirements are standard, the off-the-shelf tools have years of iteration, hundreds of integrations, and dedicated support teams you'll never match with a custom build.

I've watched companies spend $200K building a custom project management tool that was worse than Asana. Not because their developers were bad. Because they underestimated how many edge cases a project management tool needs to handle and how much ongoing maintenance it requires.

If speed matters more than fit, buy. Custom software takes 6-12 weeks minimum for anything useful, and 3-6 months for anything substantial. SaaS tools are running today.

If the tool isn't a competitive advantage, definitely buy. If better project management won't differentiate you in the market, don't spend engineering time on it. Use those cycles on things that actually move the needle for your customers.

When building wins

When the tool IS your competitive advantage. If your unique workflow is what makes your company better than competitors, encoding it in custom software locks in the advantage. No off-the-shelf tool will replicate it because no off-the-shelf tool was designed for your specific approach.

We built a custom candidate matching system for a recruiting company that scored candidates against job requirements using AI and their proprietary methodology. No ATS on the market could do this. The scoring model was their secret sauce. Building it turned a manual process that took 4 hours per job posting into something that took 30 seconds.

When the integration tax exceeds the build cost. Sometimes the "buy" option means buying 3 tools and spending months wiring them together with APIs, Zapier, and manual workarounds. When the integration effort starts approaching the cost of building one unified tool, building is the better investment. Especially for workflows you'll run thousands of times.

When off-the-shelf tools force painful compromises. Every SaaS tool embeds assumptions about how work should flow. When those assumptions match your reality, great. When they don't, you're constantly working around the tool instead of with it. If your team spends more time fighting the tool than using it, that's your signal.

When data ownership matters. Certain industries and data types require control that multi-tenant SaaS can't provide. Healthcare, financial services, defense. Or any situation where your data is too sensitive to live on someone else's servers.

The framework we use

For each build-vs-buy decision, we score five things.

First, uniqueness of workflow on a 1-10 scale. How different is your process from the industry standard? Below 4, buy. Above 7, seriously consider building. Most companies overestimate their uniqueness here. "We have a very specific approval process" usually means "we have an approval process with some extra steps," not a fundamentally different paradigm.

Second, strategic importance. Does this workflow directly impact your competitive position? Customer-facing tools and revenue-generating workflows score high. Internal admin tools score low.

Third, expected lifetime. How long will you need this tool? If the answer is "until we're 3x bigger and then we'll need something different," buying makes more sense. You're just renting a solution for a growth phase. Custom software has high upfront cost and low marginal cost. SaaS has low upfront cost and recurring marginal cost. The crossover point is usually 18-24 months.

Fourth, maintenance capacity. Can your team maintain what you build? This is the factor most companies underestimate. Building the tool is maybe 40% of the total cost. Maintaining it (fixing bugs, updating dependencies, adding features, handling edge cases you didn't anticipate) is the other 60%. You need at least one person who owns the tool long-term. If you can't identify that person, think hard.

Fifth, integration requirements. How many other systems does this tool need to connect to? Custom tools with 2-3 integrations are manageable. Custom tools that need to sync with 10 other systems become maintenance nightmares.

The hybrid answer

There's a third option that's often the best one: customize a platform. Use an off-the-shelf tool as the foundation and build custom functionality on top of it. Supabase as a backend with a custom frontend. HubSpot with custom integrations. Retool for internal tools that need custom logic but don't justify a full build.

You get 80% of the speed-to-market of buying and 80% of the customization of building. Not perfect for either. But good enough, shipped this month, usually beats perfect, shipped in six months.

What the question is really about

After dozens of these decisions, I've noticed the build-vs-buy question is usually a proxy for something deeper: does this company take its operational infrastructure seriously enough to invest real resources in it?

Companies that treat internal tools as an afterthought tend to accumulate operational friction that slows everything else. Companies that recognize the quality of their internal tools directly affects the quality of their output tend to make better build-vs-buy decisions. Not because they always build. Because they're asking "what gives us the best workflow?" instead of "what's cheapest?"