7 Signs You Need Custom Software, Not More SaaS

The signs you need custom software rarely look like a software problem. They look like a new subscription. A team hits a gap in the CRM, someone finds a tool that covers it, a card goes on file, and the gap is “solved.” Six months later there are three tools, two spreadsheets, and one person who knows how they connect.

My position: most small and mid-sized businesses don’t have too little software. They have too much software standing in for the small piece of custom work nobody would schedule. When that’s the case, another subscription doesn’t fix it. A build does.

This isn’t a fringe problem. Zylo’s 2026 SaaS Management Index puts the average company at 305 SaaS applications, with license utilization at 54% in 2025. That data comes from larger organizations, but the pattern shows up at every size: tools bought for one job and kept long after anyone checked whether they still did it.

Here are seven signs your next purchase should be a build.

1. You pay for a whole tool to use one feature

Someone bought a scheduling platform for its round-robin. A reporting tool for one dashboard. A forms product for the one form that writes to the CRM.

Each of these made sense on the day it was bought. Together they’re a monthly tax on features that are small enough to live inside the system you already run. If you can name the single feature you use, you’ve basically written the spec for it.

The test: open each subscription and ask, “If this tool vanished tomorrow, what would we actually lose?” If the answer is one sentence, that sentence is a build.

2. Somebody exports to a spreadsheet every week

This is the most reliable sign there is. Every Monday, someone pulls a report out of the CRM, pastes it into a spreadsheet, does three VLOOKUPs and a pivot, and sends it on. Or the reverse: they edit a sheet and push it back in with an import tool.

That spreadsheet is a feature your CRM is missing. Often it’s a roll-up, a cross-object calculation, or a bulk fix, all things that can run inside the org on a schedule. We wrote up how to handle the bulk-edit version in updating Salesforce records without a data loader, and the reporting version in the Salesforce reports you’ve been told you can’t build.

The weekly export is only “free” because the person doing it isn’t on the invoice.

3. A tool exists only to connect two other tools

If a chain of automations is the only thing holding your stack together, you’re paying for glue. The glue usually works until a field gets renamed, a step times out, or a retry fires twice and creates a duplicate. Then nobody can say what happened, because the logic is spread across three dashboards.

Glue tools are great for prototypes and genuinely simple handoffs. Once the connection carries business logic (dedupe rules, conditional routing, retries that matter), it’s an integration, and integrations deserve to be built and owned. We compared both paths in detail in custom Salesforce integration vs Zapier.

4. Your onboarding doc is mostly workarounds

Read your new-hire guide for the CRM. Count the lines that start with “don’t,” “make sure to,” or “the system won’t, so.”

Every one of those is a rule your team enforces by memory because the software doesn’t. “Make sure to set the region before saving” is a validation rule. “Don’t convert a lead if the company already exists” is a duplicate check. “Tell ops when a deal closes” is an automation.

Workarounds compound. Each new hire learns them slightly wrong, and the data degrades quietly until someone schedules a cleanup project. The cheaper path is to turn the doc into rules, one line at a time.

5. Per-seat pricing punishes the people who barely use it

Some tools charge per user for something two people use daily and fifteen people open once a month to check a status. You end up either paying for fifteen seats or locking people out and fielding the questions by hand.

When the thing those fifteen people need is a view, a status, or a single action, it can usually live where they already work. A record page in the CRM, a small internal page, or a digest email. Custom software doesn’t charge per seat for a status check.

6. You’ve outgrown the snapshot or template you started with

Agencies on GoHighLevel know this one well. You started with a snapshot, it got you live, and now every client needs something it doesn’t quite do. So you add tools around it, and the snapshot becomes the least differentiated thing you sell.

That’s the point where custom GHL build-outs beat another bolt-on: a custom object, a webhook receiver, a report the client actually asked for. The same logic applies on Salesforce when a managed package covers most of your process and the rest is spreadsheets. We laid out when buying still wins in AppExchange vs custom build.

7. The “small change” request has been open for months

The clearest sign is a backlog item nobody argues with and nobody does. Add a field to the renewal alert. Route leads from one state to a different rep. Flag deals without a next step.

Each request is too technical for a spare admin hour and too small to justify hiring a developer. So it sits, and the team buys a tool that does something nearby, or just lives without it. If you’re stuck here, the seven CRM tasks you should stop paying a developer for will look familiar.

When SaaS is still the right answer

None of this means “build everything.” Buy when the problem is common, the vendor carries real weight you’d never want to own (payments, telephony, email deliverability, compliance), and your process fits the tool rather than the reverse. A good subscription is a good deal.

The line I use: buy the infrastructure, build the fit. If a tool is doing something generic that thousands of companies need, keep it. If a tool is papering over the specific way your business works, that’s custom work, and it’s usually smaller than it looks. The longer version of that trade-off lives in no-code vs custom development.

Why custom used to lose by default, and what changed

For most teams, “build it” meant hiring a developer or an agency, waiting weeks, and paying for every revision. Against that, a subscription won even when it was a bad fit.

That math is what has changed. With Sentinel, your AI becomes the developer of your CRM. You describe the roll-up, the routing rule, or the integration, and your AI builds it directly in your Salesforce or GoHighLevel account. On Salesforce, changes go to a sandbox with tests first. Every change is logged and a snapshot is taken before each deploy. That doesn’t stop a wrong rule from being written; it means you can see exactly what changed and roll it back the same day, which is how the safety layer is meant to work. Pricing is flat per Sentinel and is covered on a short demo call.

Start with sign two. Find the spreadsheet someone rebuilds every week; that’s your first spec. Book a Demo Call and bring your list of subscriptions. We’ll go through which ones are really workarounds.