Nobody decides to spend a fortune on software subscriptions. It happens one reasonable choice at a time. A team needs a tool, the tool costs 15 dollars a user, the trial is free, and the decision takes five minutes. Multiply that by a dozen tools and a few years of headcount growth, and one day someone in finance pulls the report and asks why the company is spending more on software than on rent. This is SaaS sprawl, and it's one of the most common things I get asked to untangle. The fix isn't always custom software. But often enough it is, and the math is more favorable than people expect once you count it honestly.

Why subscriptions hide their true size

A per-seat subscription is designed to feel small. Fifteen dollars a month is a rounding error. The pricing page shows you that number, not the number that matters. The number that matters is total annual cost across your whole team, projected over the years you'll actually use it. A tool at 25 dollars per user per month, across 40 people, is 12,000 dollars a year. Over five years, that's 60,000 dollars, and that assumes the price never rises and your team never grows, neither of which is true. SaaS prices tend to climb, and the renewal email rarely highlights the increase. Then there are the multipliers nobody budgets for. The annual price hike. The new tier you get pushed into when you cross a usage limit. The add-on modules that turn out to be necessary. The seats you keep paying for after people leave because nobody audits the list. Sprawl isn't one big cost. It's many small costs that compound quietly and are designed never to be looked at all at once.

The other half of the bill: the workarounds

The subscription is only the visible cost. The bigger one is often the labor that exists because the tool doesn't quite fit. When a SaaS product does most of what you need, your team fills the gaps with manual effort. They export to spreadsheets, they reconcile by hand, they copy data into the next tool, they build fragile little processes to make the software behave. That work is real payroll, and it scales with your volume. A tool that saves you money on paper can cost you a full-time person's worth of busywork in practice. When I assess a sprawl situation, I count both: the rent you pay the vendor, and the wage you pay your own people to compensate for what the rent doesn't buy.

When custom starts to win

Custom internal software has a very different cost shape. It's a larger amount up front and a much smaller amount to maintain afterward. A subscription is the opposite: small to start, forever after. Somewhere those two lines cross, and the question is whether they cross inside a timeframe you care about. Custom tends to win when several of these are true:

• You're paying for many seats. Per-seat pricing punishes growth. A custom tool you own doesn't charge more because you hired ten people.
• The tool only fits 70 percent. If your team is doing heavy manual work to cover the gap, you're paying twice, once for the license and once for the labor. Custom can erase the second bill.
• The process is yours. If the workflow is specific to how your company operates, no generic product will ever fit it well, and you'll keep paying for that mismatch indefinitely.
• You're stitching several tools together. Sometimes one focused internal tool replaces three subscriptions and the manual glue between them. That consolidation is where the savings get dramatic.

Custom does not win when the product is cheap, mature, and fits you well. Don't build your own email service or your own video calls. Build the thing that's bleeding you, not the thing that's working.

How to estimate the payback

You don't need a spreadsheet model to get a useful answer. You need four numbers. First, the annual subscription cost of the tools you'd replace, projected with realistic growth, not today's snapshot. Second, the labor cost of the workarounds, roughly: how many hours a week does your team spend compensating for the tool, times their loaded wage. Third, the build cost, the one-time investment to create the custom tool. Fourth, the maintenance cost, what it takes to keep it running each year, which is normally a small fraction of the build. Add the subscription and labor costs together to get what you're spending now, every year, forever. Compare that to the build cost plus annual maintenance. If the ongoing spend pays back the build in roughly one to two years, building is usually a clear win, because after that crossover the custom tool keeps saving money every year while the subscription would have kept charging. If payback stretches past three or four years, buying is probably the safer call. The honest version of this estimate includes the risk that a build runs over, so I tend to pad it. Even padded, plenty of sprawl situations pay for themselves faster than the people living inside them expect.

The point isn't to build everything

Cutting SaaS sprawl is not a crusade against subscriptions. Good products are worth paying for, and renting beats building far more often than founders want to hear. The point is to look at the whole bill, the rent plus the workaround labor, and notice the few places where you're quietly paying both, year after year, for something that fits you badly. Those are the places where a custom internal tool stops being an expense and becomes a thing that pays for itself. Finding them is mostly arithmetic and honesty. If you suspect your software stack is costing more than it should and want a clear-eyed look at where a custom tool would actually pay off, reach out on WhatsApp and we can run the numbers together.