• Hendrik Bulens

    5 minutes read


  • Back to news

The customization trap

ℹ️ This article appeared originally in the 2022 Autumn/Winter edition of the SPOTSi-Schlau Magazin.

While any mistake can cost a business dearly, custom software projects are especially risky. We need look no further than Lidl to see how a common scenario plays out. This major discount retailer operates over 11,000 stores across Europe and the United States, yet, despite its size, stability, and staffing, it experienced a spectacular failure. On top of its enterprise resource planning software (SAP), the company spent €500 million on a new inventory management system that never saw the light of day.

To be clear, IT projects don’t have to be expensive or complicated to make things go belly-up. In fact, a professional basketball team was once relegated to a lower league because a Windows update took too long to complete.

Bearing that in mind, a responsible CIO should operate as though failure is always just around the corner, and have a contingency plan and meticulously-thought-out execution strategy for any scenario. After all, digitalizing a company is a complex undertaking, one that involves far more than just software and databases. Many job titles have been invented to map out business processes, improve efficiencies, and create virtual counterparts. More likely than not, Lidl did all of this, concluded that there were too many gaps in SAP's software, and decided that the best approach was to step away from the standard solution and build a bespoke one to suit their needs. This behavior is not unique to Lidl. I see it daily from my clients at Dime Software.


During the early phase of my career, I jumped on that bandwagon as well, creating tailored solutions to close the gaps in my customer’s technological landscape. Fast-forward a few years, and many thousands of hours and euros later, and those same customers ended up scrapping everything and starting from scratch again.

It doesn’t help matters that IT companies use their impressive array of tools and procedures to uncover their client’s gaps and requirements, and then draft an extensive and enticing proposal for them to sign off on. Rarely do they ask questions about the way the customer conducts business, though. The mere mention of reengineering their business processes would run the risk of antagonizing their prospects, and that is a risk that they are unwilling to take. An unfortunate side-effect is that companies resort to customization way too quickly and far too frequently, only to be disappointed in the long term.


Customizing enterprise resource planning systems is a dicey game. Because everything is connected, even a minor modification can wreak havoc on the entire system. (Remember the Log4j vulnerability a little while back? One tiny hitch in an open-source library caused the world to panic for a few days.) Even if, by some miracle, the customization is justified and implemented correctly, the code still needs to be maintained and the features will eventually need to be expanded upon. The bottom line: customizations are never cheap, almost always take longer to build than anticipated, and they often have a shorter lifespan than their off-the-shelf counterparts.

Customizations are never cheap, almost always take longer to build than anticipated, and they often have a shorter lifespan than their off-the-shelf counterparts.

Don’t get me wrong, custom software certainly has its place in a business. Having full control over your software allows you to create exactly what you need. You don't have to worry about the vendor dropping their support. And you don't have to wait days for assistance or pay for changes to their standard product.

The issue is that all of this comes at a hefty price, so it’s best to proceed with caution – ideally surrounded by a team of highly qualified people.

Overall, software development is an unregulated mess. Neither qualifications nor credentials are required to get started, and there are no institutions with the authority to prevent anyone from deploying their solution. It is difficult to keep up in such a volatile and fast-paced industry. Yet, rather than proceed with caution, the marketing teams of consulting and software companies continue to tout customization as the holy grail.

What can be done?

As I see it, low-code platforms are a great supplement to custom software development. The available tools and platforms are improving daily, and they offer a cheap and low-risk solution that connects the entire ecosystem in a user-friendly way. Within a matter of clicks, users can create and connect their apps without having to write a single line of code.

Instead of customizing ERP systems, the industry should seek to enrich them with off-the-shelf solutions that can talk to one another. In this scenario, it is up to the partners to solve the puzzle and make the pieces fit together for their customers. Since this type of architecture is flexible and allows for expanded functionality, customizations can be used to close any gaps that arise.

All things considered, a good IT partner will only turn to customization as a last resort. First, they will look for standard solutions that can provide at least 75% of the required functionality, and then use their resources and ingenuity to come up with the remaining 25%. When it comes to the latter, the partner should follow the rule of configuration, composition, and customization, preferably in that order.


At the end of the day, customers need a reliable partner who can guide them along their journey, educate them, and challenge them to evaluate their business processes before resorting to quick fixes and dysfunctional software solutions. Even though I’m convinced that this is a matter of common sense, it has yet to factor into mainstream discussions and is costing companies millions. The entire industry has to step up their game to reduce the enormous amount of money that is lost on failed projects.

Back to news

About the author

Hendrik Bulens is Managing Partner at Dime Software and leads the Dime.Scheduler product team. His many years of experience as a consultant and passion for business and technology have helped shape Dime.Scheduler into what it is today and define where it is headed.

Hendrik Bulens
Last modified on