Key takeaways
- The build vs buy question is almost always asked too broadly. Most businesses need to answer it for one specific workflow or tool, not their entire software stack.
- A five-question framework surfaces the right answer in most cases: workflow cost in staff time, fit between the workflow and the SaaS tool's assumptions, data ownership requirements, integration middleware cost, and 36-month total cost of ownership.
- SaaS total cost of ownership compounds in ways the initial pricing page does not show. Seat growth, add-on modules, and vendor repricing regularly produce a 36-month cost two to four times the original estimate.
- Custom software earns its cost when the workflow is genuinely idiosyncratic, when the data is a core business asset, or when the SaaS tool is the documented bottleneck in a revenue-generating process.
- The practical approach for most founders is targeted: replace one or two high-friction tools with custom software while keeping the rest of the SaaS stack in place.
The build vs buy decision sits at the intersection of product strategy, operations, and finance. It is one of the most consequential decisions a founder makes about their technology stack, and one of the most commonly made with incomplete information.
Most of the bad decisions happen when the question is framed wrong at the start. This piece gives you a framework for framing it correctly, the math you need to run, and a clear picture of when the answer changes.
The question most founders ask too early
Most founders ask 'should we build or buy?' as a binary, strategic question applied to the entire software stack. This framing produces two predictable failure modes.
The first failure mode is asking the question too early. A company that has not reached product-market fit, or that is still discovering the shape of its own operations, has no reliable basis for designing a custom software system. Custom software built for today's process becomes expensive technical debt when the process changes in eight months, which it will.
The second failure mode is asking the question too broadly. Answering 'we should build' for the whole stack, rather than for one specific tool or workflow, leads to underestimating scope and cost. Answering 'we should buy' for the whole stack, without examining which tools produce the most friction, leaves measurable operational drag in place indefinitely.
The useful version of the question is specific: which one tool in the current stack produces the most measurable operational cost, and does the math justify replacing it with a custom-built alternative? That version is answerable with evidence.
The Custom Software vs SaaS: When to Build Your Own piece on this site covers the broader decision logic in more detail, including the decision tree for the overall SaaS vs custom comparison.
A five-question framework for the decision
Five questions are enough to surface the right answer in most cases. Work through them in sequence, because each one builds on the last.
Question 1: What does the workflow actually cost in staff time per month?
Map the process before evaluating any tool. Every time a staff member adapts to a SaaS limitation, by exporting and manually reformatting data, by doing in a spreadsheet what the tool does not support, or by maintaining a second system to compensate for the first, that adaptation costs time.
Count the hours per month, multiply by the fully loaded cost per hour for the staff involved, and the result is a measurable monthly figure. This is the cost the custom alternative has to beat over time. For small teams, the number is often lower than expected. For teams above 20 people running one workflow repeatedly, the number is often larger than anyone has named before.
Question 2: Does your workflow fit the tool's built-in assumptions?
Every SaaS tool is built around assumptions about how a business operates. A CRM assumes that deals move through linear stages and that contacts map to accounts in a predictable hierarchy. If the actual sales process does not match that shape, the team is paying for a tool they fight every day.
Workflows that fight the SaaS model's assumptions produce the highest ongoing operational cost. Workarounds compound over time. Staff develop their own compensating routines, which then diverge from each other. The tool's customization surface (field mapping, automation rules, workflow triggers) gets overloaded with patches that break whenever the vendor updates the platform.
Question 3: Who needs to own the data, and how much does that matter?
Data ownership is a genuine business concern in two specific contexts. First, in regulated industries (healthcare, legal, finance, insurance), where the location and processing of data is a compliance requirement the SaaS vendor may not satisfy. Second, where the data itself is a core business asset, and the dependency on a single vendor's export format creates switching cost that compounds over time.
For most businesses outside regulated industries, data ownership is not the deciding factor. For businesses in regulated industries, or for businesses whose model depends on proprietary data sets, it belongs in the analysis.
Question 4: What does the integration middleware actually cost?
Modern SaaS stacks are connected by integration middleware: Zapier, Make, Workato, and custom webhooks. The visible cost is the monthly subscription. The invisible cost is the engineering time spent maintaining integrations that break when either connected tool updates its API.
A representative mid-size company running 12 SaaS tools with 20 active integrations between them might spend $800 to $2,000 per month on integration platform subscriptions and 10 to 20 hours per month on maintenance. Over 36 months, that is $29,000 to $72,000 in direct subscription cost alone, before accounting for the staff time. A custom application with a unified data model can eliminate most of this cost by removing the need for most integrations.
Question 5: What is the 36-month total cost of ownership?
This question requires the full calculation in the next section. It is the one that most often changes the outcome of the analysis when founders run the numbers for the first time.
Total cost of ownership: the math most pricing pages hide
The SaaS pricing page shows the per-seat monthly cost at the tier the company starts on. It does not show the actual 36-month cost for a company that adds seats, upgrades modules, crosses a usage threshold, and absorbs a vendor repricing event during that period.
A realistic example. A company of 20 people adopts a project management SaaS at $15 per seat per month ($3,600 per year). At month 12, they are at 28 seats ($5,040 per year). At month 18, they add a resource management add-on ($6,000 per year). At month 24, the vendor reprices the base plan to $22 per seat ($7,392 per year for 28 seats). At month 30, they are at 35 seats ($9,240 per year). Total 36-month cost: roughly $28,000 to $35,000. The original pricing page implied $12,960.
For tools in the CRM, ERP, HR, and project management categories, the 36-month total cost of ownership at mid-market scale typically runs two to four times the number on the pricing page at purchase.
Custom software has a different cost structure. Development cost is front-loaded. A focused custom workflow application for a 20-person team, built by a boutique studio in 2026, costs $30,000 to $100,000 depending on complexity. Ongoing maintenance runs $1,000 to $3,000 per month. Infrastructure costs $50 to $500 per month at that scale. The full pricing picture, including MVP and full product ranges, is covered in the How Much Does Custom Software Cost in 2026? piece on this site.
Over 36 months, the custom software total cost of ownership in that same scenario is roughly $90,000 to $210,000. At 20 seats, custom software is more expensive than the SaaS alternative in this example.
The math shifts at scale. At 50 or more seats with complex workflow requirements, the SaaS 36-month cost in the same category often exceeds $150,000. The custom alternative's cost does not scale with seat count. The crossover point depends on tool category and company size, but it is worth calculating before any decision of this magnitude.
When SaaS is genuinely the right answer
SaaS wins the comparison in the majority of cases. The clearest situations where SaaS is the correct choice:
The workflow is standard. If the sales process is conventional, the HR workflow matches what the tool was built for, and the project management approach fits the tool's default stages and views, the tool is providing genuine value. There is no case for replacing it.
The team is small or the business model is still changing. A team under 15 people is almost always better positioned on SaaS, even with friction. The fixed cost of custom software development competes with the variable cost of staff time spent on workarounds, and at small scale the math rarely justifies a build. More importantly, at early stage the workflow is likely to change before the business stabilizes. Custom software built for today's process is often out of date within a year.
The vendor's roadmap addresses the problem you have. If the friction is a known limitation the vendor has committed to fixing in the next 12 months, building a custom replacement before that fix arrives is almost never justified. Track the roadmap, hold the vendor accountable at renewal, and wait.
The friction is minor and intermittent. Not every SaaS limitation warrants a build decision. If the workaround costs two hours per month and the workflow is not growing in volume, the business case does not clear the bar for custom development.
When custom software earns its cost
Custom software earns its cost in four specific situations. Outside these four, SaaS is usually the stronger choice.
The workflow is genuinely idiosyncratic. Some businesses run processes that no SaaS vendor has built for, because the market is too small or too specialized to justify a product. A quoting tool for a project type that fits no existing CPQ data model. A case management workflow for a firm operating in a narrow regulatory area. A production tracking system for a manufacturing process no vertical SaaS covers. In these situations, SaaS either does not exist or requires so much configuration that the tool barely resembles its original form.
The data is a core business asset. When the business model depends on proprietary data, and the business needs to query, combine, and act on that data in ways no SaaS tool supports, a custom-built data layer is the structurally correct choice. The value is not primarily in avoiding subscription costs. The value is in owning a system the business controls entirely, that can be extended without asking a vendor for permission.
The regulatory requirements are not met by the vendor. In healthcare, legal, and certain financial services contexts, the vendor's data processing agreement, security certifications, and access controls may not satisfy applicable regulations. When a compliant vendor does not exist for the required category, a custom build is the only viable path.
The tool is the identified bottleneck. When one specific SaaS tool is the documented reason that a revenue-generating process is slower, more error-prone, or less scalable than it needs to be, and the vendor has declined to address the problem, the business case for a custom replacement is clearer than in any other scenario.
The hybrid path most businesses actually take
Very few companies make a wholesale switch from SaaS to custom software. The real pattern is more targeted: identify one or two tools producing the most friction, replace those with custom-built applications, and leave the rest of the SaaS stack in place.
This approach has a practical budget advantage. A targeted custom application for a specific workflow costs $20,000 to $80,000 at a boutique studio in 2026. A full custom replacement for an entire tool category (a CRM, an ERP, an HR suite) runs $100,000 to $500,000 depending on scope. The targeted approach lets the business test the custom development model on a lower-stakes project before committing the larger budget.
The integration question is simpler in the targeted approach. A custom application built to replace one specific SaaS tool can be designed with an explicit API that connects cleanly to the rest of the existing stack. Replacing a tangled set of integrated tools simultaneously is a far harder coordination problem with a much wider failure surface.
The businesses that struggle most with this transition try to do too much at once. They run a single large engagement to replace several tools simultaneously, find scope growing during development, and end up with a partially completed system that costs more than the SaaS stack it was meant to replace. The targeted approach limits that downside.
A reasonable approach: pick one tool that meets two criteria. It should be the one producing the most measurable operational cost, and it should cover a workflow contained enough to design, build, and test within 12 to 16 weeks. Build that. Measure the outcome. Decide whether a second project is justified based on what the first one actually delivered.
When to revisit the decision
The build vs buy decision is not permanent. Three conditions should prompt a reassessment.
Significant scale change. A company that was too small to justify custom software at 15 people may have crossed the threshold at 50 or 75. Seat-count SaaS pricing that was manageable earlier may now be one of the largest software line items in the budget. The 36-month TCO calculation is worth running again whenever headcount crosses a meaningful threshold or whenever the SaaS renewal cost has grown by more than 30 percent year-over-year.
Vendor behavior change. SaaS vendors reprice, acquire competitors, discontinue features, shift their target customer segment, or decline. A tool that was the right choice three years ago may not be the right choice today at the current price, under the current security posture, or at the current development pace. The annual renewal is the correct trigger for a TCO review.
Workflow maturity. Businesses in the first 18 to 24 months of operating a specific workflow are still learning what the workflow actually requires. Custom software built for an immature workflow needs redesigning when the workflow stabilizes. At the 18 to 24 month mark for a stable, well-understood process, the evidence is solid enough to build against. The decision made at that point is far more durable than one made at the start.
