If you've ever been involved in a major enterprise software purchase, you've probably heard some version of this before: "You may not need this capability today, but it's included in the package."

On the surface, this sounds like a pretty good deal. Maybe you don't need advanced planning, field service, supplier collaboration, or some new AI feature right now, but you might someday. And if the incremental cost is low enough, why not lock it in while you're negotiating the larger deal?

The problem is that "someday" has a funny way of never arriving.

Enterprise software portfolios are full of capabilities that were purchased with good intentions but never meaningfully adopted. Some never get implemented at all. Others get turned on because someone figures, "We already paid for it, so we might as well use it." A few users kick the tires, enthusiasm fades, and before long the feature is quietly sitting there collecting dust.

That's shelfware. And while we tend to think of shelfware as unused software licenses, the problem goes much deeper. Unused or underused capabilities can increase your software spend, add complexity to your environment, create new dependencies, and sometimes make future upgrades or changes way harder than they need to be.

There was a time when buying ahead made more sense. Adding specialized capabilities later could mean another lengthy software selection, an expensive integration project, or a custom development effort that was difficult to justify. Those tradeoffs look different today. Best-of-breed SaaS applications are easier to integrate than they used to be, and low-code platforms have made targeted solutions more economical to build. AI-assisted development adds a third shift on top of both of those, changing how quickly an organization can stand up a custom solution to fill a functional gap.

In this article, we'll look at how much enterprise software functionality actually gets used and why seemingly harmless "value-add" features can carry hidden costs. Then we'll make the case for buying what you need today, while preserving the flexibility to buy or build what you need tomorrow.

The Shelfware Problem

Shelfware isn't a new problem. For as long as organizations have been buying enterprise software, they've been buying more functionality than they ultimately use.

Recent research shows just how widespread the problem is. Zylo's 2025 SaaS Management Index found average license utilization of just 47.3%. Vertice's 2026 data found that 65% of SaaS licenses were either unused or underutilized. Looking specifically at ERP packages, Panorama Consulting noted in 2025 that its consultants routinely encounter organizations where nearly a third of the system is sitting dormant. And that’s probably a very conservative number.

Of course, the exact utilization percentage isn't really the point. Depending on whether you're measuring licenses, modules, features, or actual usage, the numbers will vary. Still, no matter how you slice it, the pattern is very consistent: organizations are buying considerably more software than they actually use.

In this regard, AI has become the new frontier. Deloitte's 2026 State of AI in the Enterprise report found that workforce access to sanctioned AI tools jumped sharply over the past year, yet fewer than 60% of workers who actually have access use it in their day-to-day work, a gap that's barely moved since the year before. These aren't forgotten licenses from ten years ago. They're capabilities organizations recently decided they needed, paid a premium for, and are still struggling to put to work.

Sometimes it's an entire module bundled into a larger agreement, or a premium feature that seemed too good to pass up. And sometimes the capability gets implemented simply because someone figures, "We already own it, so we should probably use it."

But owning software, turning it on, and getting value from it are very different things. That's where shelfware becomes more than just a licensing problem.

The “Someday” Trap

Most shelfware doesn't start with someone intentionally buying software they don't need. It usually starts with a pretty reasonable conversation about the future.

For example, you might be negotiating a new ERP agreement and the vendor offers an additional module at a steep discount. Or, maybe a vendor entices you to move up a licensing tier because it unlocks several capabilities that are on your long-term roadmap. In these situations, it's easy for teams to rationalize expanded purchases by reasoning that: We'll probably need this eventually, so we might as well get a good deal now.

The problem is that you're making a purchasing decision today based on requirements that may look very different two or three years from now. Priorities shift and people move into new roles. On top of that, the technology itself keeps evolving out from under whatever assumptions you made when you signed the deal. And sometimes the requirement everyone was convinced was coming never materializes, at least not in the way people expected.

Bundling makes this especially difficult because vendors are very good at making incremental functionality look inexpensive. It's the same instinct that sells an extended warranty at the checkout counter: a small add-on against a much bigger purchase feels almost free, even when the odds you'll ever use it are pretty low. Another module might add relatively little to a much larger agreement, particularly when discounts and incentives are involved. But you're still paying for it, and that cost tends to follow you into renewals whether the expected value ever shows up or not.

There's nothing wrong with planning ahead. But there's a big difference between maintaining a technology roadmap and pre-purchasing everything on it. In many cases, the better option may be to keep your options open and spend the money when "someday" actually becomes today.

Why “Included” Isn’t Always Free

As we discussed in the previous section, it's easy to justify adding another capability when the vendor tells you it's already included. At that point, it can feel like there's little downside. After all, if you've already paid for it, why wouldn't you use it?

Sometimes there’s a happy ending to that story. The capability gets adopted, solves a real problem, and delivers real value. Still, it's important to remember that licensing is only one part of the total cost of ownership.

Turning on a new capability usually means time-consuming configuration workshops, testing, security, training, integrations, and ongoing support. It becomes another piece of your environment that someone has to understand and maintain. And depending on how deeply it gets embedded into your business processes, it also becomes something you have to account for every time you upgrade, integrate another system, or make an architectural change.

That's where "free" functionality starts to become deceptively expensive. A feature that started as a convenient add-on can create dependencies that make it much more difficult to change direction later. You may discover a better solution, but replacing the one you already implemented now means unwinding integrations, migrating data, retraining users, and changing established processes.

None of this means you shouldn't use capabilities that are already included in your software. If they solve a real problem and they're a good fit, by all means use them. But "we already own it" isn't much of a business case.

Before turning something on, it's worth asking the same questions you would if you were buying it separately: What problem are we solving? Who is actually going to use it? What will it cost us to implement and support? And, perhaps most importantly, what are we tying ourselves to by adopting it?

Just Turning It On Doesn’t Create Value

Once you've paid for a capability, there's a natural temptation to try to get something out of it. We've seen this play out plenty of times: even though it's not perfect, we already own it, so let's turn it on and see if people will use it.

Sometimes it works out. More often, simply making a new tool available isn't enough to change the way people work, especially when using it introduces more friction than the process it's supposed to improve. Users need a compelling reason to change an established process, learn a new tool, or add another step to their day. If the benefit isn't clear to them, adoption is going to be an uphill battle.

This is especially easy to miss with enterprise platforms because deployment can look like progress. The module is configured. Users have access. Training has been delivered. The project gets marked complete. Six months later, everyone is still doing things pretty much the way they did before.

That's how shelfware can hide in plain sight. The software isn't technically sitting on the shelf anymore, but it isn't producing much value either.

A better measure of success isn't how much of your software you've managed to turn on. It's whether the capabilities you've implemented are actually helping people work better, solve a problem, or produce measurable business outcomes.

You Have Options

One of the assumptions behind buying software for someday is that you're protecting yourself from a harder decision later. If you already own the capability, you won't have to go through another software selection, negotiate another contract, or figure out how to integrate another product into your environment.

That argument made a lot more sense when your options were limited.

Today, waiting doesn't mean you're committing yourself to a more difficult or expensive path. If the need eventually materializes, you can still buy the module from your existing vendor. But you can also evaluate a best-of-breed solution based on the requirements you actually have at that point, rather than the ones you were trying to predict several years earlier.

Waiting also gives you something that's easy to undervalue: optionality. The software market will change. Your business will change. New products will emerge, existing products will improve, and the economics of solving the problem may look very different by the time you actually need to solve it.

There's also nothing preventing you from revisiting the original vendor. If their solution is still the best fit when the requirement becomes real, buy it then. The difference is that you're making the decision with a real use case, real users, and a much clearer understanding of what you actually need.

Closing Thoughts

Enterprise software has always encouraged us to think ahead. Buy the bigger package and lock in the discount. Add the module now because you might need it later. On paper, that can look like good planning. In practice, it can leave you paying for capabilities that never become priorities.

That doesn't mean you should ignore your roadmap or avoid investing ahead of an obvious need. It means there should be a higher bar for buying software for someday. A discounted feature that nobody needs isn't necessarily a bargain, and an included capability isn't automatically free once you account for the cost of implementing, supporting, and maintaining it.

More importantly, waiting isn't nearly as risky as it used to be. You can add capabilities from your existing vendor later, or choose a best-of-breed product once you actually understand the requirement. Increasingly, you can also build a targeted solution yourself, using low-code tools and AI-assisted development. You don't have to predict every future requirement during today's software negotiation.

Buy what you need. Get value from it. Keep your options open.

Someday can wait.