Recently I started looking at the SaaS bill for Qandaba and asking a question I’ve been seriously thinking about. Not “is this too expensive” (always), but “are we actually maximizing the use of any of this?”

Some of these applications are prohibitively expensive, even on a per-seat basis. Multiplied across the team and across the year, the line items add up to enterprise-software money for tools the team has had to bend itself around to use. That alone is worth pausing on. But the cost question is only half the picture. The other half is utilization.

The honest answer was somewhere between five and ten percent. We were paying for the full feature set of a time tracking and payroll platform, the full feature set of a work item tracker, the full feature set of a finance system, and using a thin slice of each one. The slices didn’t even line up with how we worked. We had quietly adapted ourselves to the software, not the other way around.

That used to be the deal. Building custom software cost six figures plus, and a year of your life, so you took the closest off-the-shelf option and contorted your team to fit. The trade was clear: rent at five percent utilization, save yourself the cost of building.

AI has changed that math. Quietly, but completely.

What you’re actually using

Walk through almost any small or mid-sized business and you find the same pattern. A time tracking and payroll platform with elaborate scheduling, leave management, and compliance reporting, where the team uses a small slice. A work item tracker with workflows, status maps, and dashboards, that the team has wallpapered over to use as a glorified to-do list. In bigger companies I have worked in, the list grows: HR systems where most of the talent and performance modules sit unused, document control repositories with versioning and approval flows that nobody actually walks through. The shapes change. The pattern does not.

This is not a fault of the vendors. Off-the-shelf tools are built for the average of ten thousand companies, and your business is not the average. The closer you get to running things your way, the more the software gets in your way.

So you do one of three things. You build manual workarounds in spreadsheets and email threads. You accept the misfit as a pet peeve and stop talking about it. Or you pay another consultant to bend the tool a little further toward your workflow, and pay them again every time the vendor ships a release that breaks the customization.

I’ve done all three. Many leaders I know have.

The new math

Here is the question I would ask anyone running a business in 2026. Would you rather pay licenses for software where you use five percent of what is there, or build the five percent of what you actually need and use one hundred percent of it, while saving money?

That used to be a rhetorical question. The answer was always “rent,” because building from scratch was prohibitive. With AI-assisted development, the answer is no longer obvious. For a meaningful share of internal workflows, a small custom system built in days or a few weeks is comparable in cost to a multi-year SaaS contract, sometimes lower, and it fits the team the way the team actually works.

I am not arguing that you build everything yourself. Some categories do not make sense to recreate. Email. Calendaring. Payment processing. Identity providers. The infrastructure that benefits from being commoditized and universally interoperable is exactly the infrastructure you should keep renting. That is not where the leverage is.

The leverage is in the long tail. The internal workflows unique to your business, the ones no tool fits cleanly, the ones you have been holding together with spreadsheets and email threads and a “wouldn’t it be nice if” you stopped saying out loud years ago. That is where building starts to win.

What we actually built

Qandaba is a small consulting business. We do not have a Salesforce budget. We do not need one, either. But we do need to track potential clients, follow up at the right time, and not let anyone slip through the cracks.

For months we did this manually. Spreadsheets. Notes in email. The kind of system that works until it does not, and then you lose a conversation because you forgot to follow up on the right week. So we built a small client tracker, sized exactly for our team and our pipeline. It does the things we need it to do, in the language we use to describe our work, and nothing else.

That pattern has now repeated across the business. Our social media content workflow is custom. Our time tracking and payroll, which used to live on a SaaS platform, now runs on tooling we built. Our AI usage reporting and monitoring system is custom, because no off-the-shelf tool tracks the things we care about across the model providers we actually use. A growing share of our internal IT runs through a stack we built rather than a stack we rented.

None of these are enterprise-grade products. They are not meant to be. They are sized for our team, our workflow, our edge cases. And because we built them, when something does not quite fit, we change the software instead of changing the team.

Collectively, they have become something I did not set out to build on purpose: a company OS. The operating layer that holds the business together.

Where this leaves SaaS

SaaS is not going away. The category of software that benefits from network effects, from interoperability across millions of businesses, from being maintained by a vendor with deeper domain focus than you will ever have, is fine. I still rent my email. I still rent my accounting platform. There are problems I will happily delegate to a vendor whose entire company is built around solving them better than I can.

But the assumption that every internal workflow has to be a vendor relationship is the assumption worth questioning right now. The cost curve has moved, and most companies have not noticed yet.

If you’re a founder, or you manage a SaaS budget at your company, I would encourage you to do the audit. Pull up the SaaS bill. For each line item, ask what percentage of the product your team actually uses, and how much of your daily friction comes from the gap between what the tool does and what your business needs.

If the answers make you uncomfortable, that is the signal. That is where building something small, custom, and fitted to your business stops looking like a luxury and starts looking like the most sensible thing you could do.

We are doing this for ourselves at Qandaba. We are starting to do it for clients too. If that conversation sounds useful, the door is open.