For most software needs, the right answer is to buy.
Off-the-shelf SaaS is faster, cheaper, and easier to support than anything a small team could build. For a clear, common, well-served problem, it's rarely worth even considering a custom alternative.
The interesting question isn't when to buy. It's when to stop buying, and what to build instead.
Organizations that wait too long to revisit this decision end up paying for the SaaS, paying for the workarounds, and paying for the opportunity cost of work they can't do because the SaaS won't let them. Organizations that revisit it too eagerly end up with bespoke software that should never have existed.
This article is about the signals that actually matter when this decision is in front of you, and how to weigh them honestly.
When SaaS Is the Right Answer
SaaS wins, decisively, when:
- The problem is common and well understood
- The workflow matches the SaaS model with minor adjustments
- The cost is reasonable relative to the value
- The integration points are simple
- The data lives mostly inside the tool, not across systems
- The organization is happy to adapt to the SaaS, rather than the other way around
Under those conditions, no custom build will pay back its cost.
Most organizational needs fit here. Most of the time, the answer to "build or buy" is buy.
When the SaaS Model Quietly Stops Working
The case for SaaS weakens slowly. It rarely fails outright. The signals look like this:
- The team has built a spreadsheet to handle the part the SaaS doesn't
- A non-trivial part of someone's job is reconciling data between systems
- The SaaS keeps surfacing fields and features that don't match the actual workflow
- The team has paid for plans they don't need to get the one feature they do
- Internal processes have shaped themselves around the SaaS, rather than the other way around
- The integration cost between the SaaS and the rest of the stack is growing each year
None of these is a crisis. Together, they indicate that the SaaS is no longer fitting the organization.
This is the moment when "build" deserves a real look.
The Hidden Costs of Staying
The continuing cost of an ill-fitting SaaS rarely shows up cleanly on a budget.
- The license fee is visible
- The integration work is partially visible
- The shadow-IT spreadsheets are mostly invisible
- The opportunity cost of the workflows nobody attempts is entirely invisible
By the time the total cost is acknowledged, the organization has paid for it many times over.
The honest question isn't "is the SaaS expensive." It's "what is the total cost of running our actual operation on this tool, including what we work around, what we duplicate, and what we can't do?"
The Real Cost of Building
The "build" side of the equation has its own honest accounting.
- Initial development cost
- Hosting and infrastructure
- Maintenance and updates
- Security and compliance work
- Support during business hours
- Documentation and onboarding
- Evolution over time
A custom app isn't a one-time cost. It's an asset, with an annual carrying cost.
The right comparison isn't "license fee vs project cost." It's "total cost of running on SaaS vs total cost of running on custom, over five years, including how the workflow can evolve in each case."
Where Custom Reliably Wins
Custom software beats SaaS when:
- The workflow is genuinely specific to the organization
- The data shape doesn't fit the SaaS's model
- Integration with other internal systems is the point, not a side feature
- The organization needs control over evolution and timing
- The SaaS is being used for less than half of what was bought
- The workarounds have become a permanent part of the operation
These conditions describe a meaningful share of organizations between fifty and a few hundred employees. SaaS was the right answer at twenty employees. It's no longer the right answer at two hundred.
Where Custom Reliably Loses
Custom software is the wrong answer when:
- The need is well-served by existing tools
- The organization underestimates the long-term carrying cost
- The team doesn't have a clear owner for the system
- The motivation is "we want it our way" rather than "the operation needs something the market doesn't provide"
- The build is being chosen because nobody likes the current SaaS, rather than because the SaaS no longer fits
A custom build chosen for the wrong reasons becomes a heavier SaaS replacement with worse support.
The Compounding Argument for Custom
Custom software has one property SaaS doesn't.
It improves on the organization's timeline.
- New workflows can be added when needed
- Reporting can be unified across systems
- Edge cases can be supported without political negotiation
- The system evolves in step with the operation
This compounds over time. Three years in, a well-built custom app is usually noticeably ahead of where SaaS would have been, in the workflows that matter most to the organization.
This is the same dynamic described in Why October CMS Works Better for Long-Lived Products.
A Practical Framework
Five questions tend to make the build-vs-buy decision honest.
- What share of the SaaS are we actually using? If it's under 40 percent, the cost per useful feature is higher than it looks.
- What is the annual cost of working around the SaaS? Include reconciliation work, manual data movement, and shadow tools.
- How many workflows have we abandoned because the SaaS doesn't support them? These are real costs even though they're invisible.
- Is the integration with other internal systems improving or degrading? A degrading integration story is a strong signal.
- If we keep the SaaS, what does the operation look like in three years? If the answer is "more or less the same," SaaS may still be right. If the answer is "a heavier patchwork than today," it isn't.
These five questions, asked honestly, usually resolve the decision.
What Mature Organizations Actually Do
The pattern that works best in practice is hybrid.
- Buy SaaS for common, well-served needs
- Build custom for the workflows that define the organization
- Connect them carefully, with clear ownership
- Revisit the boundary every couple of years
This avoids the two failure modes: running an entire operation on SaaS that doesn't fit, and building everything from scratch when a SaaS would have been fine.
The interesting decisions are at the boundary, not at the extremes.
A Simple Rule of Thumb
If your operation works around the SaaS more than the SaaS works for your operation, the decision has already been made. The only remaining question is how long the organization is willing to keep paying both costs.
Final Thoughts
The build-vs-buy decision isn't about ideology. It's about fit.
SaaS is right when:
- The problem is common
- The workflow matches the tool
- The cost is reasonable
- The integration is simple
Custom is right when:
- The workflow is specific
- The data shape is specific
- The integration is the point
- The total cost of working around the SaaS has crept past the cost of replacing it
The organizations that get this right aren't the ones that pick a side. They're the ones that revisit the question regularly and act on the answer when the signals are clear.
The right answer changes as the organization grows. The decision deserves to grow with it.
If your organization is working out whether the time has come to replace a piece of SaaS with something custom, this is exactly the kind of decision we help operations and engineering leaders think through. Book a short consult.
