I recently had the pleasure of presenting at WERC 2026. My talk explored the maturation of software decision-making, and I challenged the audience to examine their existing business systems. “Go through your configuration screens, one at a time and look at each parameter that is a numeric limit, an enable / disable switch, or an operating mode selection. For each one, ask yourself whether this parameter reflects an actual, real-world, physical constraint, or if it’s something that is only necessary because the system can’t make a better decision.” In other words, which of your system rules and settings are there to model your actual business requirements, and which are there because the system needs guardrails?
This led to some interesting comments in the Q&A portion, which I heard echoed in other Q&A portions. When you buy an established business system, you are paying for a large number of features you will never use. The vendor has been building this complex offering up for years – decades even – to serve as much of the market as they can. No one customer will use every feature, but every customer will fund the ongoing development and maintenance of the behemoth.
It’s not unreasonable for the vendors to build robust applications to serve many customers. That’s how they stay in business. Large enterprise customers may have multiple different variations of the configuration, even from site to site or across business units. Nobody wants a completely different application from scratch.
However, the pain for the customers is real. Not only do they pay for the care and feeding of these immense applications, but they must also develop a special kind of internal resource on their team. This invaluable team member must be capable of understanding the myriad of configuration details, their potential side effects, and their applicability to the business operations. Finding the unicorn that is adept at both technology and operations to this level is a challenge for most organizations.
This is not a one-time cost. This is ongoing education and training as new features are adopted, new versions are rolled out, and new users come on board to demand new benefits.
At LogistiVIEW, we have maintained a core principle in our design. If you’re not going to use it, you don’t need to configure it. Our customers range in their use of our platform, from a single workflow / use case, to full-blown optimization, and all points in between. No one customer uses everything we have. Often, our customers start with a limited scope and expand, solving one problem at a time.
We hold it quite dear that none of them are burdened to manage the features we add, unless they find value in those enhancements.
This takes some deliberate attention in our designs, and adds some test scenarios to cover the different permutations. That’s ok. We would rather take that effort on than burden our entire customer base every new release, or intimidate new customers with, as they say, eating the whole elephant.
My response in that Q&A session advised the audience to interrogate potential vendors not just on ROI, but on “time to value.” What is their typical time to value on an implementation, vs. the complexity of your intended use case. The answer may reveal some information about how much they consider your burden for the benefits they are providing to everyone else.
