When Should You Replace SaaS With Custom Software?
By Aldridge Dagos, operations software engineer
A subscription can be expensive and still cost less than ownership. You should replace SaaS with custom software only when one important workflow justifies the full cost and responsibility of running the replacement.
I have built a practice-controlled patient callback system in place of a rented form. The public case is a completed build, not a claim of measured savings. What it proves is narrower: a company can control its domain, fields, access rules, database, and routing without pretending the service becomes free.
The short version: Compare the current service with the whole owned system over the same period. Count the subscription, usage charges, administration, connections, and exit work on one side. Count discovery, build, migration, hosting, security, support, maintenance, change, and recovery on the other. Build when that comparison survives realistic stress cases and the workflow is important enough to deserve a long-term owner.
Is high SaaS spend enough reason to build?
No. A portfolio benchmark can tell you to inspect the bill. It cannot decide whether one product should be replaced.
Vertice reported in July 2026 that SaaS spend among the organizations in its data reached $9,324 per employee in Q2, up from $9,200 in Q1. That benchmark describes Vertice’s managed spend, not every company.
Zylo’s January 29, 2026 release says its index analyzed more than 40 million licenses and $75 billion in spend under management. It reports a $9,455 median annual spend per employee and an average 36 percent of licenses unused against its usage benchmark. That is 36 percent of licenses, not 36 percent of dollars. It also describes Zylo’s sample, not your ledger.
These numbers support a portfolio review. Start by removing seats nobody needs, consolidating duplicate tools, correcting the plan, and negotiating the renewal. Replacing a product because the wider software portfolio looks expensive can turn a procurement problem into a software project.
The deciding unit is one workflow. Price what that service does today, who relies on it, what would stop without it, and which constraints a replacement must carry.
What do you own when you own the software?
Ownership is a bundle of rights and duties. It is not one switch.
Hosting the database does not by itself decide who owns customer data. The contract, applicable law, product terms, export tools, retention rules, and technical design decide what each party can do. Ask practical questions instead:
- Access: Can you retrieve the records when the service or account is unavailable?
- Portability: Can you export complete, usable data with stable identifiers and history?
- Deletion: What remains after cancellation, and who can verify its removal?
- Control: Who sets fields, permissions, routing, and retention?
- Continuity: Which parts still depend on hosting, identity, messaging, or payment providers?
An owned application can improve those answers. It can still rely on cloud infrastructure and outside services. You may own the code and database design while paying several providers to keep the system reachable.
Compliance works the same way. A qualified vendor can accept defined contractual and regulatory duties. It does not take every obligation away from the customer. In its cloud guidance, the US Department of Health and Human Services says a cloud provider that handles electronic protected health information can be a business associate with direct duties, while the covered entity or business associate still has to conduct its own risk analysis and risk management. That is a HIPAA example, not a rule for every industry. It shows why “the vendor handles compliance” is too broad.
The people doing the work need a place in this decision. A tailored system can remove duplicate entry and fit their real sequence. It can also hand them an immature tool with weak support. The owner gets more control only when the operator gets a reliable path, clear permissions, and somebody accountable for failures.
What belongs in a build-versus-buy comparison?
Use the same period and the same business result on both sides. A subscription quote compared with a development quote is incomplete before the first calculation.
Decision worksheet 01
Compare the whole service with the whole build
-
01 Price the service - Subscription and usage
- Your figure
- Admin and connected-tool time
- Your figure
- Renewal scenarios
- Your figure
- Exit and migration
- Your figure
-
02 Price ownership - Discovery, build, and migration
- Your figure
- Hosting and paid services
- Your figure
- Security, support, and recovery
- Your figure
- Changes and rebuilds
- Your figure
-
03 Test the decision - Three-year total
- Your figure
- Five-year total
- Your figure
- Base and stress cases
- Your result
- Named operating owner
- Name the owner
Decision gate Build only when the economic case survives the stress case and someone can own the service after launch.
For the current service, include the base plan, seats, usage, add-ons, administration, connected tools, renewal scenarios, and the work required to leave. If a vendor handles backups, uptime, updates, or support inside the price, keep that service in the comparison.
For ownership, include discovery, design, build, migration, parallel operation, hosting, storage, paid services, monitoring, security work, support, maintenance, incident response, and expected changes. Name the person who owns each continuing duty. If nobody has the time or authority, the row is not zero. It is unresolved.
Opportunity cost belongs here too. A builder working on an internal replacement cannot spend that time on a customer feature, a revenue system, or another operating problem. Use the best realistic alternative, not an imaginary perfect project.
Run at least three cases:
- Base case: The best current estimate for usage, change, and support.
- Low-growth case: The subscription stays flat or the vendor grants a better renewal.
- Ownership stress case: Maintenance, support, or a major change costs more than planned.
A forecast will not predict each future bill. The point is to learn which assumption can reverse the decision.
How does the five-year math work?
Consider an illustrative workflow used by 40 people. The subscription is $75 per person each month, or $36,000 in year one. The model assumes the subscription rises 13 percent each year. That 13 percent is a scenario input, not a forecast for the market or the next renewal.
The replacement costs $70,000 to build and $14,000 each year to run, support, secure, and maintain. Treat both figures as selected inputs. They are not typical prices.
| Year | Subscription that year | Ownership that year | Cumulative subscription | Cumulative ownership |
|---|---|---|---|---|
| 1 | $36,000 | $84,000 | $36,000 | $84,000 |
| 2 | $40,680 | $14,000 | $76,680 | $98,000 |
| 3 | $45,968 | $14,000 | $122,648 | $112,000 |
| 4 | $51,944 | $14,000 | $174,593 | $126,000 |
| 5 | $58,697 | $14,000 | $233,290 | $140,000 |
Under those inputs, cumulative ownership becomes lower during year three. The five-year difference is about $93,290. That result belongs only to this model. It does not include financing, tax treatment, a major rebuild, lost productivity during migration, or a value for capabilities one option provides and the other does not.
The $14,000 annual row is not a promise that ownership stays flat. It is a planning allowance. If the system adds users, handles more data, faces a new rule, or needs a larger support window, the cost changes.
What happens when the assumptions change?
Small changes can move the answer by years or remove the crossover from the five-year period.
| Scenario | Five-year subscription | Five-year ownership | First lower cumulative year |
|---|---|---|---|
| 13% subscription growth, $14,000 yearly ownership cost | $233,290 | $140,000 | Year 3 |
| 0% subscription growth, $14,000 yearly ownership cost | $180,000 | $140,000 | Year 4 |
| 13% subscription growth, $40,000 yearly ownership cost | $233,290 | $270,000 | None within five years |
The first sensitivity case keeps the subscription at $36,000 a year. Cumulative subscription cost reaches $108,000 after year three, still below the $112,000 ownership total. The crossover arrives in year four.
The second keeps the 13 percent subscription assumption but raises annual ownership cost to $40,000. That produces a $270,000 ownership total after five years. The build does not cross within the period.
A model should also test the build price, migration delay, support hours, usage growth, and a planned change. Do not bury all uncertainty inside one “contingency” row. Separate inputs show which risk changes the decision.
When does SaaS remain the better choice?
Keep the service when it already handles a common function well and the business gains little from changing the underlying rules. Email, payment processing, and general accounting often benefit from specialist operations, broad connections, frequent updates, and support shared across many customers.
A small user count usually weakens the financial case because the subscription total starts lower. It does not make a build irrational by itself. One specialist using a tool to control a costly or safety-sensitive process may justify more investment than 100 people using a minor convenience.
SaaS also wins when the workflow is changing faster than the company can define it. Renting gives the team room to learn before encoding a temporary practice. A provider may also offer a network, certification, data source, or regulated service that would be impractical to recreate.
There is a human reason to rent. The vendor carries much of the update, availability, and support work. A team without an owner for those duties is buying service, not merely software.
When does a custom build earn its place?
Build when the workflow is stable enough to describe, important enough to improve, and distinct enough that available products keep forcing the wrong work. The economic case should survive a flat-renewal scenario and a higher ownership-cost scenario.
Control must produce a concrete gain. That could mean a data boundary the current service cannot provide, one record moving through several departments without re-entry, a permission model tied to the real organization, or an operating rule that off-the-shelf tools repeatedly break.
The patient callback build offers that kind of bounded example. It gives the practice direct control over the public fields, domain, database, access list, and routing. Its published status is Build complete. It does not prove lower lifetime cost or production adoption.
A broader workforce platform build connects applicants, onboarding, training, time, and department work in one role-scoped product. Its public case also says Build complete and ready for operational validation. Any claim about lower tool costs or adoption still needs measured production use.
Those limits matter. Software ownership begins at delivery. The strongest build case includes the person who will operate it, the budget that keeps it reliable, and the evidence that will decide whether the investment worked.
If the case depends on every subscription increase arriving, every maintenance year staying cheap, or every planned benefit appearing, keep renting and improve the contract. A build earns approval when the conservative case still works.
Frequently asked questions
Is it cheaper to build custom software or buy SaaS?
It depends on the workflow, time period, migration, support, and continuing ownership cost. Compare complete three-year and five-year totals, then test a flat subscription and a higher maintenance case. Either option can remain cheaper for the full period.
Does a SaaS vendor own customer data?
No single answer follows from hosting alone. Check the contract, product terms, applicable law, export format, retention, deletion, access, and continuity rules. An owned application can increase control while still relying on outside infrastructure and services.
Can a small team justify custom software?
Yes, when the workflow has a large consequence, creates a distinct capability, or cannot be handled safely by available products. A low seat count usually makes the cost comparison harder, but seat count alone does not settle the decision.
Does using a specialist SaaS vendor transfer compliance responsibility?
No universal transfer exists. A vendor can accept defined contractual and regulatory duties, while the customer may retain duties for risk analysis, configuration, access, use, and oversight. Check the rule and agreement that apply to the specific work.
What is the break-even point for replacing SaaS with custom software?
It is the point where cumulative ownership cost becomes lower than cumulative service cost for the same result. The worked example crosses during year three under its base assumptions, in year four with no subscription growth, and not within five years when annual ownership cost rises to $40,000.