Enterprise software: What if customization was never the problem?

For most of my career, I heard the same advice repeated in boardrooms and software demonstrations: “Configure, don’t customize.”

It sounded sensible. Customization was expensive, difficult to support and supposedly the reason so many enterprise software projects failed to deliver on their promises. If customers could stay within the boundaries of the software, everyone would benefit.

After decades in enterprise software, I’ve come to believe the opposite. “Configure, don’t customize” is one of the industry’s most misleading phrases, because every path eventually leads to customization.

What I’ve learned about enterprise software

In my leadership positions at Siebel, Oracle and Salesforce, I made a point of meeting with as many consumer goods customers as possible to understand how they were using our technology and where it created value.

Those conversations taught me a lot about designing, selling, implementing and supporting enterprise software. But even though my customers appreciated my contributions, something didn’t sit right with me. They were achieving an acceptable ROI on their software investments, but it wasn’t nearly as high as I thought it could be or what was promised in the project justification documents.

Despite advances in cloud computing, software-as-a-service (SaaS) and modern development platforms, my customers’ implementation costs remained high, they kept pushing back on upgrades, and they continued to add extensive customizations to the software they purchased.

For that reason, I can only rate my life’s work a 6 out of 10 — but that might be changing. With AI-assisted development and the rise of vibe coding, the industry may finally have a chance to break that cycle.

How enterprise software has and hasn’t gotten better over the years

Over time, I realized the issue wasn’t that customers, software vendors or system integrators (SIs) were failing.

The vendors may say the SIs lack proper training; the SIs might claim the software cannot support key business requirements; and the customers are accused of being underresourced or unclear on priorities. There’s usually some truth on all sides, but in fact, enterprise software has always tried to solve an almost impossible problem: Every industry is different, and the closer software gets to the realities of how organizations operate, the harder it becomes to avoid customization.

The software itself remains the main challenge. Over the years, software development has improved to the point where we have browser-based applications that are much easier to build and deploy than the old client-based models. The SaaS business model has reduced capital outlay, while the cloud has eliminated the need to buy, configure and maintain servers. However, the implementation, support and upgrade costs haven’t come down much.

The dreaded software upgrades

Many people say cloud software updates are now effortless because they’re automatically pushed to customers. This is only partially true. Vendors typically make new functionality available through mandatory releases, while fixes to existing functionality are often optional because they can break customer customizations. As a result, some organizations postpone the latter for years because the cost and risk are too high. Many even avoid upgrades entirely until support for their current version ends.

IT teams often configure sophisticated enhancements to solve complex business challenges. On many occasions, my customers’ innovations were so good that they even inspired my next product designs. However, when software vendors push out new functionality, customers discover they must back out of years’ worth of configurations before they can adopt the new capabilities. That’s why many choose to keep their customized solutions even when vendors deliver comparable functionality.

How software vendors create technical debt

When a product team discovers flaws in an existing design, they often cannot simply fix the problem. In cloud environments, changing core functionality can disrupt customers’ customizations. Instead, product managers often build entirely new versions of functionality alongside the old ones and allow customers to opt in through configuration settings.

Duplicating functionality protects customers from accidental disruption, but it also creates technical debt. Over time, the software becomes bloated with obsolete features, unused objects and obscure configuration options. Implementation consultants end up confused about which version of a feature is current. Performance can also suffer, and product teams spend their time maintaining old designs instead of innovating.

Even simple bug fixes can be complicated. A customer may have already built a workaround for a defect, and fixing the bug might unintentionally break the workaround. No matter the decision, someone is left frustrated.

Product managers dream of building functionality that transforms industries. Instead, much of their time is spent managing backlogs, resolving bugs and maintaining upgrade compatibility. Resources are limited and release timelines are aggressive. When approval and funding for meaningful innovation do come through, teams still end up underfunded with unreasonable timelines — because what everyone thought was one piece of functionality turns out to be one functional area with a hundred variations.

The challenge of building industry-specific functionality

The reason every path leads to customization becomes obvious the moment a product manager starts gathering requirements.

They might begin by interviewing multiple account managers from their biggest retail customer, only to discover they each do business very differently — and the complexity just grows from there. Convenience, wholesale and indirect channels each have their own requirements. Business practices vary widely across markets. Small consumer packaged goods (CPG) companies face unique challenges. Regulated industries such as alcohol and tobacco add another layer of complexity. Companies using direct store delivery or van sales models operate differently again, and B2B organizations selling to hotels, restaurants and cafés present yet another set of needs.

Before long, what looked like a single requirement has turned into dozens of legitimate business scenarios. Now, the product manager faces tough trade-offs. Should they build a highly flexible platform that lets customers build out the last mile themselves; focus deeply on a few use cases and let customers build out the remaining use cases on their own; or pursue a compromise that partially addresses a range of scenarios?

None of these approaches eliminates the need for customization. A flexible platform requires customers to configure their own processes. A highly specialized solution inevitably leaves gaps that customers must fill themselves.

That’s why I eventually concluded that “configure, don’t customize” was misleading. Modern enterprise platforms are so advanced that everything is technically configuration. Customers can create complex workflows, business rules, data relationships and automations without writing code. And from an upgrade perspective, those configurations are just as troublesome as customizations using code.

The underlying challenge remains the same: No software vendor can anticipate and preconfigure all the ways an organization needs to operate.

Enter the age of vibe coding

The rise of “vibe coding” tools — using AI to generate and refine software based primarily on natural-language instructions — is fundamentally changing enterprise software. Product teams can now build functionality much faster, and customers can develop last-mile capabilities more quickly and safely as well.

That raises a fundamental question for the industry: Now that software vendors can build out a hundred possible business scenarios using AI-assisted development, will what they build be as good as what customers can configure on their own?

Software companies will go one of two ways. Some will double down on building highly detailed solutions for as many use-case scenarios as they can. If successful, they will create foolproof software that requires little business process expertise to implement. If they fail, they’ll end up with software that cannot be  reconfigured and is difficult to enhance and expensive to upgrade.

Others will double down on platforms that make it easy for customers to build their own last-mile functionality exactly how they want it. Those customers will be able to quickly develop functionality that gives them a competitive advantage. However, if requirements are too complex, they may end up building a system that simply doesn’t work.

A new focus on accelerators

To reduce risk with the platform approach, I believe SIs will double down on building accelerators. These became less fashionable as software firms pushed toward configuration over customization, but AI may reverse that trend.

The big advantage accelerators have over preconfigured vendor functionality is that they can be reconfigured, whereas vendor functionality has to be locked down. That matters because just one incorrect formula buried in a software vendor’s thousand lines of code can make an entire functional area unusable, whereas with an SI’s accelerator, that formula can easily be edited.

This is a profound advantage of the platform or accelerator approach over software vendors’ preconfigured solutions.

Where does this leave us today?

Organizations buying enterprise software now face a difficult decision: wait for software vendors to deliver specialized, industry-specific functionality, or embrace AI-assisted coding and build their own highly tailored solutions — possibly with the help of an accelerator.

Either way, the enterprise software industry may finally be approaching a point where it can deliver the business value it has promised for decades — not by eliminating customization but by embracing it.

If that happens, maybe I can finally upgrade my career score from a 6 to a 10.

• ALSO READ → Retail media: The $100 billion growth engine retailers can’t afford to ignore