Every operations leader eventually faces the same fork in the road: the existing tools no longer fit the way the business actually runs, and someone has to decide whether to buy a packaged platform or build one in-house. The decision feels binary, but it rarely is—and treating it as a religious war between “build everything” and “buy everything” is how organizations end up with either an unmaintainable pile of internal code or a tangle of subscriptions that nobody can integrate.
What follows is a framework, not a verdict. The right answer depends on what the software is for, and most companies need a mix.
Start With the Question Behind the Question
Before comparing vendors or estimating engineering hours, get precise about what the platform is supposed to do. “We need a better way to track projects” is not a requirement—it’s a symptom. The real questions are sharper:
- What specific workflow is breaking, and what does “fixed” look like?
- Is this capability something customers see, or purely internal plumbing?
- Will the requirements be stable for three years, or will they evolve weekly?
The answers map directly onto the build-vs-buy axis. Stable, well-understood, non-differentiating problems are usually a buy. Fluid, business-specific, competitively meaningful problems lean toward build. Everything else lives in the gray zone where most real decisions actually sit.
Total Cost of Ownership Is Not the Sticker Price
The most common mistake is comparing a SaaS subscription fee against the cost of one engineer’s time. That comparison is almost always wrong on both sides.
Buying carries costs beyond the license: implementation, data migration, admin overhead, per-seat creep as you scale, integration work to connect it to the rest of your stack, and the eventual switching cost if you outgrow it. A “cheap” tool that needs three integrations and a part-time administrator is not cheap.
Building carries costs far beyond the initial sprint. Internal software is a liability the day it ships. It needs hosting, security patching, on-call coverage, documentation, and a roadmap. The original author leaves; the knowledge leaves with them. A useful rule of thumb: the first version is roughly a third of the lifetime cost. The other two-thirds is maintenance you’ve signed up for indefinitely.
Model TCO over three to five years, not the first invoice. The curves often cross in non-obvious places.
Time-to-Value Versus Long-Term Fit
Buying wins on speed. A mature platform can be live in weeks, with a vendor absorbing the cost of edge cases you haven’t even imagined yet. When the problem is urgent and the solution is commoditized, that head start is worth a lot.
Building wins on fit. Software shaped exactly to your workflow removes the friction of bending your process to someone else’s assumptions. But that fit is only valuable if the workflow is genuinely yours—if you’re building a custom CRM that behaves like every other CRM, you’ve paid a premium for nothing.
Ask honestly: is the speed of buying worth the compromise in fit, or is the fit of building worth the delay? There’s no universal answer, only an honest one for your situation.
Differentiation Versus Commodity
This is the principle that resolves more debates than any other: buy the commodity, build the differentiator.
Commodity capabilities—email, payroll, ticketing, file storage, standard accounting—are solved problems where dozens of vendors compete on price and polish. Building these in-house is almost always a waste of scarce engineering attention. You will spend years catching up to features you could have rented.
Differentiators are different. They’re the workflows, data models, and automations that make your operation faster, cheaper, or smarter than competitors. If a capability is a source of advantage, handing it to an off-the-shelf tool means accepting the same constraints your competitors accept. That’s exactly the work worth owning. Our perspective on building these advantage-bearing systems is laid out in our digital platforms practice.
The trap is misclassifying. Teams routinely convince themselves that a commodity is special (“our invoicing is unique”) and that a true differentiator is generic. Pressure-test the classification with an outside view.
Integration and Lock-In
No internal platform lives alone. The deciding factor is often how cleanly a tool fits the rest of your stack.
When buying, scrutinize the integration surface before the feature list. Does it have a real API, or just a handful of webhooks? Can you export your data in a usable format, or is it hostage to the vendor? Lock-in is rarely about a single product—it’s about the accumulated cost of rewiring everything that depends on it. A platform that’s hard to leave should clear a higher bar to enter.
When building, you control the contract but inherit the responsibility for keeping every integration alive as upstream systems change. That’s a real, ongoing tax.
The Maintenance Burden Nobody Budgets For
It bears repeating because it’s so consistently underestimated: internal software does not stay built. Operating systems update, dependencies deprecate, security advisories land, and the business changes its mind. Every line you write is a line someone must understand and maintain for as long as it runs.
Before committing to build, confirm you have not just the capacity to create the platform but the standing capacity to operate it. If the answer is “we’ll figure that out later,” that’s a strong signal to buy.
The Hybrid Third Path
The most pragmatic answer is frequently neither pure build nor pure buy: build on a platform.
Modern API-first SaaS, low-code backends, and composable infrastructure let you buy the commodity foundation—authentication, storage, billing, base CRUD—and build only the thin, differentiating layer on top. You get the speed and maintenance offload of buying for the boring parts, with the fit and ownership of building for the parts that matter.
This is where most well-run operations land. It demands clear architectural boundaries so the custom layer doesn’t entangle itself irreversibly with any single vendor, but done well it captures the best of both columns. It’s the model behind the internal platforms and products we build, and it’s usually the right default when the answer isn’t obvious.
A Decision Checklist
When you’re in the gray zone, run the candidate through these gates:
- Differentiation — Is this a source of competitive advantage? If yes, lean build.
- Stability — Are the requirements stable for years? If no, lean build or hybrid.
- TCO over five years — Including maintenance and switching costs, which is genuinely cheaper?
- Operating capacity — Can you maintain it forever, not just ship it once?
- Integration — How clean is the path in—and the path out?
If the answers point toward commodity, urgency, and a thin team, buy. If they point toward advantage, evolving needs, and real engineering capacity, build—or build on a platform.
The goal isn’t to build less or buy more. It’s to spend your scarce engineering effort only where it compounds into advantage, and to rent everything else. If you’re weighing a specific decision and want an outside read, we’re happy to talk it through.
Comments