Blog
Tags:
This is the end of your agility, IT professional
More and more often, I see companies making a remarkable choice: instead of adapting the software to the way they work, they adapt their way of working to the software.
The reasoning sounds logical. Almost funny. You buy standard SaaS, you choose “best practices,” you avoid customization, and you go live faster. And yes, after twenty years of ERP horror stories, that reflex is understandable. Projects that run years over schedule because the ERP has to do exactly what your process does. Customization that breaks again with every new release. Performance that slowly declines because your extra layers were not included in the original design. And dependence on that one developer who “knows how it really works.”
So organizations turn it around: “If we just adapt our process to the package, we'll be rid of the hassle.”
This raises a very uncomfortable question: what problem are you actually solving?
If customization was the risk, aren't you just shifting that risk? Instead of being dependent on a programmer, you become dependent on a supplier. On their roadmap. Their pricing model. Their integrations. Their definitions of “how it should be done.” And if your distinctive way of working lies precisely there—in your exceptions, your speed, your customer agreements—then you are sacrificing a piece of your competitive strength for peace of mind in IT. Phew!
Look, in the short term, that trade-off can be attractive. Less complexity. Faster implementation. Less maintenance. Fewer incidents due to DIY tinkering.
But in the longer term, the real test comes: how agile can you remain when legislation changes, your market shifts, or your business model flips? Can you still move, or is your company stuck in the logic of a package? Probably the latter.
In this blog, I look at the problems that push organizations in this direction, what they hope to gain from it, and what alternatives there are. Without falling back on “everything customized” or “just swallow the standard.”
Bloat sells. And you pay for the wait.
Today's software is surprisingly often... just not good.
Not “a little messy.” But really bad: slow, fragile, and full of glitches that only become apparent after hours of use. And if your people have to wait every day for screens, exports, synchronizations, and “just log in again,” there will come a time when someone says, “Enough is enough, we're going to fix this NOW.” And then the trouble begins.
Except then the search begins... for the wrong culprit.
Because why is software so often subpar?
Reason 1: The speed of change: “shipping” is more important than “getting it right.”
The world is moving faster than your release calendar. What is “state of the art” today feels like legacy tomorrow. Customer expectations change. Legislation changes. Security changes every quarter (sometimes every week). And so software has to keep up—faster than ever.
But speed comes at a price. Not because engineers are lazy, but because quality is linked to time. High quality = a lot of time. Little time = low quality. Think about it: testing, threat modeling, performance budgets, decent release cadence, rollback plans, documentation, refactoring... these aren't “extras.” They're the foundation. And it's precisely that foundation that gets skipped first when the pressure is on.
So teams start rushing. Features get added. Hotfixes follow. Another integration. Another exception. And before you know it, “it works” is the norm and “it works well” is a luxury.
Can you prevent this? Yes. But it doesn't come for free. You need to make structural investments in engineering discipline: automated testing, observability, clear architectural boundaries, a backlog that also pays off technical debt, and the courage to sometimes say no to “just a quick fix.”
If you don't do that, “faster adaptation” is not a strategy. It's an accelerator pedal towards fragile software. And customization that becomes obsolete faster and faster.
Reason 2: Lack of knowledge (and time to do it right)
For years, there has been a shortage of architects, good engineers, testers, and performance specialists. Average talent is already difficult to find; real star players are rare. As a result, teams continue to build, but they don't finish. Refactoring, testing, hardening, and measuring are the first things to go when “the business” wants something new.
And then comes the new hype: “vibe coding.” It gives me a serious headache and stomachache. Nice for prototypes. Totally risky if you feed production environments with code that mainly copies what it sees most often: mediocrity. Mediocrity scales excellently. Quality does not, absolutely not.
Reason 3: Customization without understanding the heart of the system
Many custom developers don't know the package they are expanding on deeply enough. They know the API, but not the internal dynamics. They optimize functionality (“it works”), but not quality (“it keeps working when it gets busy”). Performance and security become secondary issues, until they become the main issue with the problems they cause.
Result: extra layers that make the system heavier, upgrades that cause extra frustration, and incidents that make it all much more expensive. You get an application that does exactly what you asked for and... becomes slow in the areas you didn't include in your requirements. Oops...
Reason 4: Demand for bloat: appearance sells, friction doesn't
Users see icons, colors, new menus. They don't see more efficient queries, less I/O, better caching. So suppliers build what is visible. Windows 11 is a useful example: Microsoft is strongly committed to “modern UX,” while over the years there has been regular criticism of bloat and performance (especially on older hardware). And even performance claims sometimes turn out to be mainly hardware comparisons, not “Windows 11 is faster by definition.”
Reason 5: No strict 80/20 discipline
A beautiful UI is valuable. But if you get 80% “beauty” with a 20% loss in performance, you stop there. Otherwise, you end up with a shiny hood on an engine that overheats.
And that's exactly where customization becomes fatal: it piles up on an overly heavy foundation. Bad software is annoying. Bad customization makes it structural.
You trade customization for dependency
When you align your business processes with the way your software works, you immediately solve one problem: you have less (or no) hassle with poorly functioning customization. Upgrades go more smoothly. Your performance remains more predictable. And you don't have to hope with every new version that “that one extension” still works.
That's the benefit.
But you also take on new risks. And those are often less visible. Until things go wrong. And they do go wrong; I see it happen time and time again with many of our customers. Here are the main risks:
Agility: their pace becomes your pace
The world is changing rapidly. Legislation, invoicing requirements, security requirements, new markets, new customer conditions. If your processes fit into the package, you are dependent on the supplier to move with the times. I've seen it happen: a customer was unable to invoice certain countries as of January 1 because mandatory invoicing requirements were not yet included in the software. Ouch. That's not an “IT problem.” That's hard cash flow. And reputation.
Forced to adapt: change without a business case
If the supplier decides that “the new way” is smarter, you have to reorganize. Sometimes because a larger customer demands it. Sometimes because legislation in their country is changing. Sometimes because someone had a brilliant architectural idea. Whatever the reason, you have to adapt your operations, rewrite processes, retrain people, and reinvent exceptions. That costs money, time, and focus. And it rarely generates immediate revenue, just hassle.
Dependency: price, exchange rate, and ownership
Price changes, bundles that suddenly become “mandatory,” licensing models that shift from predictable to variable; ultimately, you no longer have control. And when ownership or strategy changes, your risk profile changes with it: sovereignty, data location, support, roadmap. Sometimes minor. More often business-critical.
Evaporation of distinction: your “special sauce” becomes standard
Many organizations are not unique in their organizational chart, but they are unique in how they deliver: turnaround time, exceptions, service promises, chain agreements. If you trade that unique way of delivering for “how the package wants it,” you often sacrifice competitiveness for apparent peace of mind. That can be a great choice, but then call it that.
The core is simple: you trade the risk of customization for the risk of dependency. Make that trade-off explicit. And test it at the moments that hurt: growth, new legislation, price increases, and changes in direction.
Before you make your decision: let me observe for 30 minutes
Often, the solution to complexity is simpler than it seems.
The problem itself feels complex. Many dependencies. Even more opinions. The already present “that's just not possible.”
The good news is this: in practice, the solution is usually surprisingly simple. If you remove the noise and look only at the facts.
For over 15 years, Sciante has been quickly and cost-effectively removing the sting from seemingly unsolvable IT problems. We tackle precisely those situations where teams get stuck, where everyone is perplexed, and where the business continues to pay.
In just 1 to 2 weeks, we uncover the blocking issues that others overlook. That is our strength. Not with thick reports, but with hard measurements and a short, clear list: this is slowing you down, this is costing you money, this needs to be done first.
So before you decide to bend your processes to a supplier (and trade your autonomy for “peace of mind”), I'd be happy to take a look with you.
It's quick. And... it's free of charge.
Then you'll quickly know whether giving up autonomy makes sense... or whether you're mainly solving the wrong problem.