The conversation usually starts with a number. Someone pulled the card statement, added up the software line items, and the total was worse than anyone thought. Then comes the instinct to negotiate seats down or cancel the two cheapest tools — which saves a little and changes nothing, because next quarter another tool appears.
Sprawl is not a purchasing failure. It happens because one business process got split across five products that each own a slice of it, and people bought each product to fix the pain of the previous one. You cannot cut your way out of that. You have to look at the workflow underneath.
The audit: map tools to steps, not to departments
Most software audits are organized by owner — marketing's tools, ops' tools, finance's tools. That view hides the problem, because sprawl lives between departments. Instead, pick one process that matters, write out its steps end to end, and put every tool next to the step it serves.
| Workflow step | Tool | Seats | Features used | Monthly |
|---|---|---|---|---|
| Request comes in | Shared inbox product | 12 | Assignment only | $ |
| Request gets logged | Spreadsheet | — | Everything | Free, and the bottleneck |
| Approval | — | None of it is a feature | — | |
| Tracking | Project tool | 12 | One board, no dependencies | $$ |
| Reporting | BI product | 3 | Two dashboards | $$ |
| Moving data between the above | Automation platform | — | Nine scenarios | $$ |
Two things fall out of this table almost every time. The first is a tool whose entire job is moving data between two other tools — that one is pure overhead created by the split. The second is that the step everyone actually depends on is the free spreadsheet, which is why nothing you cancel ever seems to help.
Three buckets, and only one of them is a build
01
Keep
Commodity software that is deep, regulated, or heavily maintained by someone else: accounting and tax, payroll, email and calendar, payments, e-signature, identity. You will never build these better, and the money you would spend trying is the money that should fund the part that is actually yours.
02
Consolidate
Tools that each cover one slice of a single workflow — the queue, the board, the status view, the approval, the report. These are the ones that collapse into one app, because the value was never in any of them individually. It was in the sequence.
03
Kill
Tools bought for one feature that is now covered elsewhere, seats assigned to people who left, and automation scenarios that exist only to paper over the split. This bucket usually pays for the first phase of the build on its own.
The build-versus-buy line
The usual framing is cost, and it is the wrong one. Off-the-shelf software is almost always cheaper per month than anything custom. The real test is whether the process is differentiated.
If your process is the same as everyone else's in your industry — running payroll, filing taxes, sending invoices — buy it. Any difference you introduce is a liability. But if your process is the reason customers pick you, or if it is shaped by contracts, regulations, or physical constraints that no product anticipated, then off-the-shelf software forces you to work around it forever. That workaround is what you are actually paying for, in seats and in staff time.
Buy the commodity. Build the seam. The seam is the part that is genuinely yours, and it is the part no vendor will ever ship.
Where the money actually is
- Per-seat pricing on read-mostly users. A tool at $40 a seat where nine of twelve people only ever look at a status is the clearest case in any audit. Those nine seats exist because there was no other way to show them the status.
- Integration middleware. Scenario-based automation platforms are excellent for prototyping and expensive as permanent infrastructure. Once a data path is load-bearing, it belongs in code you own.
- Tier jumps. Watch for the tool where one feature you need sits in a plan that triples the price. You are not paying for a plan, you are paying for a single checkbox.
- Duplicate storage of the same records. Every product that holds its own copy of your customer list is a reconciliation problem you are paying to have.
The math, told honestly
A custom app is not free after it ships. Budget for ongoing maintenance — dependency updates, small changes as the business shifts, occasional support. As a planning figure, assume something in the range of 15 to 20 percent of the build effort per year. Any proposal that ignores this is understating the cost.
So the comparison is not "build once versus pay monthly forever". It is the retired subscriptions plus the recovered staff hours, against the build amortized over its useful life plus that maintenance. Cases where it does not pay are real and worth naming: small teams with genuinely standard processes, a workflow that is about to change fundamentally, or a business where nobody has time to be the internal owner of the new system.
Migrating without breaking anything
- Build the renewal calendar first. Annual contracts decide your sequence — you want the new app live a comfortable margin before a renewal date, not two weeks after you were auto-charged for another year.
- Export everything before you cancel anything. Access usually dies with the subscription, sometimes immediately. Get the full data export, confirm you can actually read it, and store it somewhere you control.
- Run in parallel for a defined window rather than an indefinite one. Long enough to cover a full business cycle, short enough that people do not settle in. Put an end date on it at the start.
- Move one team or one division at a time, and let each one bring its local habit into the configuration.
- Cancel deliberately, and downgrade before you cancel where the vendor allows it. A read-only or archive tier for a few months is cheap insurance while you confirm nothing was missed.
The mistake we see most often is cancelling on the day of go-live to make the savings look immediate. The overlap costs one or two months of a subscription you were already paying. Discovering after cancellation that four years of history is gone costs considerably more.
A reasonable first phase
Do not scope the whole consolidation. Scope the single workflow with the most retyping in it, ship that, and let the audit's second and third candidates wait until the first one has been in real use for a month. What people ask for after using the first version is consistently more useful than what they asked for before it existed.
If that workflow also touches an older system that has to stay, the pattern for that is covered in how to connect a legacy system to AI without replacing it.
Frequently asked questions
How much SaaS spend can realistically be cut?
It depends entirely on how much of your stack is covering slices of one workflow versus doing genuinely distinct jobs. The audit answers that before anyone quotes a build. In most cases the larger saving is recovered staff hours rather than the subscriptions themselves.
Which tools should never be replaced with custom software?
Accounting and tax, payroll, email and calendar, payments, e-signature, and identity. These are deep, heavily regulated, and maintained by someone else. Building them yourself takes the budget away from the part of your process that is actually differentiated.
What does a custom app cost to maintain?
As a planning figure, assume 15 to 20 percent of the build effort per year for dependency updates, small changes as the business shifts, and support. Any build-versus-buy comparison that leaves this out is understating the true cost.
What happens to our data in the tools we cancel?
Export it in full before cancelling and confirm the export is readable, because access often ends the moment the subscription does. Where the vendor offers a read-only or archive tier, downgrading for a few months before cancelling is inexpensive insurance.