Build vs Buy Internal Tools: A Decision Framework for SaaS Teams

The build-vs-buy debate for internal tools almost always starts in the wrong place. Someone on the team gets frustrated by a Retool app that's barely held together, or a sales ops lead asks for a feature that Zapier can't quite handle, and the conversation jumps straight to "should we just build this ourselves?" before anyone has agreed on what this actually is.

That's the real failure mode. Build-vs-buy is rarely about a single tool. It's about a portfolio decision spread across a dozen workflows, where different workflows have wildly different economics, and where the right answer for the customer health dashboard is almost never the right answer for the deal desk tool sitting next to it.

A SaaS company at $20M ARR typically runs 15 to 25 distinct internal workflows — billing exceptions, support escalations, account provisioning, refund approvals, trial extensions, partner onboarding, and so on. Some of those workflows are commodity. Some are competitive differentiation. Treating them as one bucket guarantees overspending on the commodity ones and under-investing in the load-bearing ones.

The Three Categories Most Teams Conflate

The first move in any build-vs-buy decision is to put the workflow into one of three buckets, because the right answer differs by bucket and most failed decisions come from putting a workflow into the wrong one.

Commodity workflows are the ones every SaaS company runs the same way: payroll, expense reports, contract storage, basic ticket routing, password resets, generic CRM data entry. These are non-differentiating, well-served by mature SaaS vendors, and have predictable cost ceilings. The right answer here is almost always to buy. A team that builds a custom expense management tool because "ours is special" is burning engineering time on something that won't show up in a customer-facing metric for years, if ever.

Glue workflows are the ones that connect your specific systems in a way no off-the-shelf vendor knows about. Pulling subscription data from Stripe into a credit application form, then writing the result back to your product database and notifying the CSM in Slack — that's glue. It looks like a workflow problem but it's actually a data integration problem with a thin UI on top. The right answer for glue is usually to buy the engine (Workato, Tray, Zapier, n8n, Make) and build the integration logic on top of it. Building both the engine and the logic from scratch is a 6-12 month detour that returns almost no business value.

Load-bearing workflows are the ones that touch your customers' money, your unit economics, or the operational levers that determine how your company scales. The custom dunning logic that fits your specific subscription model. The plan-change flow that has to handle proration the way your finance team accounts for it. The CSM tool that surfaces health scores using signals only your team understands. These workflows are where build wins on a multi-year horizon — not because building is cheap, but because the cost of vendor-shaped constraints accumulates faster than the cost of maintenance.

The most common failure pattern is teams that buy load-bearing workflows and build commodity ones. They put their MRR forecast inside a vendor that gives them three hours of feature work and 30 hours of working around the vendor's data model, and they spend a sprint and a half rebuilding the org chart because someone got annoyed at BambooHR.

When "Buy" Is the Right Answer

Buy when at least three of these are true: the workflow is commodity or near-commodity, multiple mature vendors exist with comparable feature sets, the vendor's data model maps cleanly to yours, the cost of vendor lock-in is low (you could switch in 30-60 days if you had to), and the total cost over three years is under what a single engineer-quarter would cost you.

That last test is the one most teams skip. A buy decision isn't "this tool costs $400/mo, that's cheap." It's "this tool costs $400/mo, plus $X in admin time to maintain seats and configurations, plus $Y in integration work to wire it into our stack, plus $Z when we eventually need to migrate off it." Across three years, even modest SaaS tools commonly land at $30,000-$80,000 fully loaded, and the integration work is what blows the budget. A $99/mo vendor that needs four weeks of engineering to integrate is not a $99/mo vendor.

The other test worth running: ask whether the vendor's roadmap is going your direction. Vendors with broad customer bases tend toward the median use case. If your workflow is at the edge of their distribution — and most workflows for SaaS companies past $10M ARR are at the edge of someone's distribution — you're paying for a product that will keep getting features you don't need and miss features you do. That gap widens over time, not narrows.

A reasonable buy decision today looks like Retool, Zapier, or Workato as the foundation; Notion or Coda for documentation-shaped workflows; Linear or Jira for engineering coordination; Stripe + Chargebee for billing primitives; and Auth0, Clerk, or WorkOS for identity. None of these are differentiating. All of them are well-served by mature vendors. Building any of them in-house is a strategic error unless you have a very specific reason — and "we don't like how vendor X does it" is not a specific reason.

When "Build" Is the Right Answer

Build when the workflow is load-bearing, when the data model is yours and doesn't fit anyone else's, when the workflow logic is something you'll iterate on quarterly as the business evolves, and when the cost of being constrained by a vendor's assumptions is higher than the cost of maintaining your own code.

The clearest build signal is when a workflow has been built three times in three different vendors and none of them quite work. You start in Zapier, hit the limit, move to Workato, hit a different limit, try Retool for the UI side, and now you have three half-integrated tools and a workflow that still breaks every other week. The accumulated complexity of stitching vendors together has already exceeded the complexity of owning the workflow outright — you just haven't formally acknowledged it yet.

The second clearest signal is when the workflow touches money in a way that's specific to your business. Custom billing logic, custom commission calculations, custom credit policies, custom multi-currency handling, custom usage-based pricing — these are the workflows where a small vendor-shaped error compounds into a real revenue leak. A build cost of 8-14 weeks for a single engineer or a small team and a maintenance cost of perhaps 10-15% of one engineer ongoing is reasonable when the alternative is a quarterly revenue surprise.

The third signal is when the workflow is a competitive lever — an admin panel that lets your support team resolve cases in half the time of competitors, a customer health view that surfaces churn risk weeks earlier than your peers, an onboarding flow that gets customers to activation in days instead of weeks. The economic value of being faster than the median competitor at one of these workflows is usually larger, by an order of magnitude, than the engineering cost of building the tool.

Build does not mean building everything from scratch. A well-scoped build today uses Next.js or a similar framework, your existing identity provider, your existing observability stack, a thin custom API layer, and standard component libraries. The custom part is the data model, the workflow logic, and the UI patterns that match your team's mental model. The infrastructure is rented and standard.

The Hybrid Pattern That Actually Wins

The pattern that produces the best outcomes for most SaaS teams isn't pure buy or pure build — it's a layered hybrid where commodity workflows sit on vendors, glue workflows sit on integration platforms, and load-bearing workflows sit on a custom internal tool layer that reads from authoritative sources and writes back through existing APIs.

In this pattern, Stripe owns subscription state. Your product database owns usage and feature flags. Your CRM owns accounts and opportunities. Your support tool owns tickets. None of these get replicated into the internal tool layer — they're read on demand via a thin API aggregation layer that presents the unified view your ops team actually needs. Writes go back through the existing APIs, so data consistency is owned by the systems that are already responsible for it.

This architecture has a property that pure-build doesn't: the tools you buy continue to do their jobs, and the integration cost is bounded by the API surface area you choose to expose. It also has a property that pure-buy doesn't: the workflows that matter most live in code you control, so they can evolve with the business without waiting for a vendor's roadmap.

The hybrid pattern's typical shape at a $20M-$100M ARR SaaS: 8-15 vendor tools handling commodity workflows, 1-2 integration platforms handling the connective tissue, and a small custom internal tool layer (often a single admin panel plus 2-4 specialized tools) handling the load-bearing workflows. The custom layer is usually 10-20% of the total internal-tools surface area and 60-80% of the operational value.

The mistake that breaks this pattern is letting the custom layer grow without scope discipline. Once you have an internal admin panel, every team has requests, and the temptation is to absorb everything that could be custom into it. The discipline is to keep absorbing only the workflows that meet the load-bearing criteria — and to push the rest back into vendors or the integration layer, even when building feels easier in the moment.

How to Run the Decision

A decent build-vs-buy process at a SaaS company runs on a one-page assessment that takes about an hour to complete per workflow, not a multi-week vendor evaluation. The questions that matter are concrete and answerable; the questions that don't matter but tend to dominate the conversation (corporate strategy, vendor relationships, who'll own it politically) should be deferred until after the technical decision is clear.

The questions that matter: Which bucket does this workflow fall into — commodity, glue, or load-bearing? What is the three-year total cost of a vendor solution, including integration and migration? What is the build cost in weeks of engineering, including the ongoing maintenance percentage? How specific is our data model to this workflow — does it fit any vendor's model out of the box? How often will the workflow change as the business evolves? What happens if the vendor's roadmap diverges from our needs in 18 months?

A typical first version of this assessment fits on one page per workflow and produces a clear recommendation 80% of the time. The other 20% are the genuinely ambiguous cases — workflows that are partly load-bearing and partly commodity, or workflows where the vendor landscape is shifting fast. Those are worth a deeper evaluation, but you'll only have time for that deeper work if you've cleared the obvious cases efficiently.

The most underused tool in this process is talking to peer companies. Other SaaS companies at your stage have already made the same decisions, often with the same vendors, and they will tell you the truth about what worked and what didn't if you ask. Thirty minutes with two or three peers will surface vendor failure modes that you won't find in any vendor's case studies, and it's the single highest-ROI input you can add to a build-vs-buy decision.

What Most Teams Get Wrong

The pattern across failed internal tools decisions is consistent: teams treat build-vs-buy as a binary, evaluate workflows in isolation rather than as a portfolio, underestimate the integration cost of buying, and overestimate the ongoing maintenance cost of building once the initial version is shipped.

Build maintenance is overestimated because teams remember the painful months and forget the years where the tool just worked. A well-architected internal admin panel built today will need maybe 30-50 hours of engineering per quarter ongoing — including new feature work — which is a fraction of the time the same team would spend wrangling vendor limitations and integration breakage.

Integration cost of buying is underestimated because vendors price the license and quietly externalize the integration onto your engineering team. A vendor that costs $30,000/year often costs another $30,000-$60,000 in first-year integration work and $10,000-$20,000/year ongoing in maintenance, configuration drift, and SSO/SCIM updates. That fully-loaded cost is what should be compared against build, not the license fee alone.

The right decision framework is honest about all of this. It treats build and buy as two valid options with different tradeoff profiles, evaluates each workflow on its own merits, and produces a portfolio shape that fits the business — not a default of "buy everything" or "build everything" that tries to make one answer fit every workflow. Internal tools are infrastructure for the business, and the business doesn't have one workflow.