Table of contents
SaaS pricing assumes broad adoption.
In practice, most teams use a narrow slice. When that happens, “buy” turns into “renting a bundle you don’t consume.” The line item looks reasonable because it’s compared to other bundles, not to the value of what you actually use.
This shows up in day-to-day work. Harvard Business Review reports that workers toggle between apps roughly 1,200 times a day, and spend close to four hours a week reorienting themselves between tools.[1]
This post lays out a simple way to quantify the waste — then an alternative: build the few workflows you actually need, and publish them with governance.
Why do SaaS bundles feel expensive even when the line item looks reasonable?
A lot of B2B software is priced like you’re buying a whole system. In reality, most teams buy a bundle to solve a small set of recurring jobs. The result:
- You pay for breadth.
- You use a narrow slice.
- Adoption levels off after the first quarter.
Bundles also hide cost. It’s easy to benchmark a procurement platform against other procurement platforms. It’s harder to benchmark it against the three workflows you actually run on it.
How do you calculate the real cost of an underused SaaS tool?
The simplest model has three inputs.
1. Annual cost. Include license fees, platform fees, and any mandatory add-ons. Don’t forget implementation.
2. Used features. Count the features your team uses weekly, or that are critical during close, onboarding, audits, or launches. Shelfware doesn’t count.
3. Effective cost per used feature.
Effective cost per used feature = annual cost / used features
It’s not a perfect metric. It is still useful, because it forces an uncomfortable question:
Are we paying a reasonable price for what we actually use?
What does SaaS shelfware look like in practice?
Here’s a workflow every ops/finance team recognizes:
- cross-functional (Ops, Finance, IT)
- governed (approvals, audit trail expectations)
- a small number of repeatable steps
Company: 100-person B2B services firm. Teams involved: Operations and Finance (6–8 core operators), plus requesters and approvers across the company. Job to be done: route vendor onboarding requests, collect documents, enforce approval thresholds, and post updates to Slack.
They buy a procurement/vendor management “platform” because it promises to cover the process end-to-end.
What they actually use
After the first quarter, usage collapses to three workflows:
- vendor intake (a form plus document collection)
- approval routing (threshold-based signoff)
- a weekly export to reconcile against the accounting system
Everything else is shelfware — and that pattern is common. Zylo reports that 53% of SaaS applications go unused in any given 30-day period.[2]
What they pay
Assume a defensible mid-market pricing model:
- $1,200 / month platform fee
- $25 / user / month for 40 users (requesters, approvers, finance)
Annualized:
- 1,200 × 12 = 14,400 → $14,400 / year platform fee
- 25 × 40 × 12 = 12,000 → $12,000 / year in seats
- Total license: $26,400 / year
Then add the piece most ROI spreadsheets omit but nobody disputes:
- Implementation / onboarding: a light vendor package or internal ops/IT time, conservatively $5,000
All-in year one: $31,400.
Effective cost per used feature: 31,400 / 3 = $10,467 per used feature per year.
The point isn’t that $10,000 is always “too much.” It’s that the math makes the tradeoff explicit:
- Are these three workflows important enough to own?
- If they’re not, why are they priced like a platform?
What costs don’t show up on the invoice?
License cost is rarely the whole number. The hidden costs show up in three places.
Tool sprawl. A single request touches multiple tools. A “simple” vendor request becomes: check a spreadsheet → paste into a form → ping someone in Slack → reconcile later. Each handoff adds time and failure points.
Admin overhead. Every tool adds onboarding, access setup, audit and compliance reviews, renewal cycles, and vendor-risk paperwork. None of that goes away just because the tool is underused.
Workarounds. If the workflow is even slightly wrong, people route around it. The “real” version lives somewhere else — usually a spreadsheet — and the purchased tool becomes a second system to maintain.
Put together, you’re not just paying for shelfware. You’re paying for the administrative weight of a tool you didn’t need to buy in the first place.
When is building an internal tool cheaper than buying a SaaS bundle?
Building internal tools used to mean a dedicated engineering team, weeks of backlog contention, and owning hosting, logins, and maintenance. That’s still true for large systems. It’s not true for narrow workflows.
Most internal workflows are mostly:
- a UI
- a small amount of business logic
- a few integrations
The build-vs-buy decision comes down to fit and ownership:
If the workflow matters and the bundle doesn’t fit, owning the workflow is often cheaper than renting around the gaps.
AI-assisted development has lowered the build side of that equation further. A focused v1 that covers three workflows is a realistic afternoon for a finance or ops lead with modern tooling — it wasn’t two years ago.
How should you publish an internal tool so it can replace a bundle?
The goal isn’t “custom code everywhere.” It’s a small set of workflows your team can actually run without a platform team behind it.
A publishable internal tool has:
- a stable URL
- role-based access
- change history
- a predictable UI
- a clear owner
- a straightforward way to iterate
In other words: publish it, don’t leave it as a script on someone’s laptop. The difference between “we built a thing” and “we have an internal tool” is delivery.
A build-vs-buy decision checklist
Run this before your next renewal.
1. What job are we actually buying?
Write it in one sentence.
- Bad: “We need a CRM.”
- Good: “We need a single source of truth for pipeline that sales leadership trusts.”
2. What do we use weekly?
List the 2–5 workflows that actually happen. If you can’t list them, you’re not buying a product. You’re buying an assumption.
3. What breaks when we try to tailor it?
If the tool fights your process, it becomes shelfware. Look for:
- rigid data model
- permissions that don’t match your org
- limited automation
- “enterprise add-on” gating for basics
4. What is the real cost to keep it?
Include annual license, admin time, and time spent working around the tool. Then compute effective cost per used workflow.
5. What would v1 of a build look like?
A realistic v1 is usually one page, one workflow, one integration, with clear inputs and outputs. Not “replace the entire suite.”
What to do if your answer is “we should build”
Building is only a win if you avoid the two classic failure modes:
- building an app that only one person can run
- building an app that can’t be governed
The operational requirement is simple:
If it matters, it must be publishable.
That means you need a consistent way to authenticate users, control access, version changes, connect to systems of record, and ship updates without fragile deployment rituals. Without that layer, every build becomes a miniature platform project — and you end up right back where you started.
Measure what you actually use
If you’re paying for a bundle but only using a small slice, you’re paying a bundle tax.
A practical way to decide:
- Measure what you actually use.
- Quantify the cost per used workflow.
- Either renegotiate pricing to match reality, or build the workflows you actually need and publish them with governance.
Either outcome beats another year of renewing a platform to run three workflows.