"Custom software is a vendor lock!"

A fellow consultant said it to me recently, almost in passing: "Custom software is vendor lock."

I've been in this industry long enough that I don't usually stop mid-conversation to stare at someone. But I did that day.

Because for years - years - I've been making the exact opposite argument. That off-the-shelf software is where the real vendor lock risk lives. That handing your business processes over to a pre-packaged product built for everyone and owned by someone else is one of the riskiest decisions a growing company can make. And here was someone I respect, flipping the whole thing around.

So we talked. For a while. And eventually, we found the real problem - which, as usual, wasn't in the argument itself. It was in the definition.

Table of contents

A Few Terms Worth Knowing First

Off-the-shelf software - any pre-made solution you buy or license rather than build. This includes SaaS subscriptions, on-premise installations, and perpetual licenses. The common thread: someone else built it, for everyone, and you adapt to it.

Custom software - software built specifically for your business, to your requirements. You own it, you control it, and it reflects how your company actually works.

ERP vs BMS - most people say "ERP" when they mean "a system that runs the whole company." Technically, ERP (Enterprise Resource Planning) covers one layer: finance, HR, procurement, inventory, and production. The broader concept is a BMS - Business Management System - which encompasses the full operational software ecosystem of a business:

Vendors selling monolithic "ERPs" are usually selling their version of a BMS - a single platform that promises to cover all of the above. We'll use ERP as the example throughout, since that's what most people call it. But everything here applies equally to any off-the-shelf system positioning itself as the one solution for your entire organization.

We Were Talking About Different Things

He was talking about badly written custom software. Projects built without a proper pre-implementation analysis. No documentation, or documentation that was written once and never touched again. No automated tests. Code that only makes sense to the person who wrote it - and sometimes not even to them.

That kind of software does create lock-in. Genuine, painful lock-in. You become completely dependent on the team that built it, because they're the only ones who understand how it works. Bringing in anyone new - or even just keeping the lights on after the original team moves on - becomes a slow, expensive nightmare.

I agreed with him on that. Because that's not a controversial take. That's just what happens when software is built badly.

But here's the thing: that's a problem of craft, not of category. Badly written software is a risk regardless of whether it's custom or off-the-shelf - and by "off-the-shelf" I mean any pre-made solution you buy or license rather than build: SaaS subscriptions, on-premise installations, perpetual licenses, all of it. And if we're going to have a serious conversation about which approach is right for a business, we need to set some ground rules about what we're actually comparing.

Don't Compare a Crashed Mercedes to a Brand New Opel

So let's be fair in both directions.

Bad off-the-shelf software isn't a safer bet than bad custom software - it's arguably worse. A poorly run SaaS product is an easy target for security breaches. An underfunded vendor can go bankrupt and take your data with them. You don't get a warning. You don't get a migration path. You get a 30-day notice and a blank stare.

And even well-run, successful off-the-shelf software carries risks that are easy to underestimate when things are going well:

Aggressive repricing. A company called Baselinker - popular among e-commerce businesses in Poland - changed their pricing in a way that effectively pushed hundreds, possibly thousands, of smaller shops off the platform. These businesses had built their operations around that tool. They didn't choose to leave. They were priced out. That's vendor lock-in. It just doesn't feel like it until it's too late.

No seat at the table. The product roadmap is decided by the vendor, based on what works for the majority of their customers - or their investors. If your business has a specific need that doesn't fit their priorities, you wait. Or you work around it. Or you leave.

Workflow imposed by the tool. Off-the-shelf products are built on assumptions about how businesses work. Those assumptions came from other companies - often not yours. When you adopt a tool wholesale, you sometimes don't realize how much you're bending your own processes to fit the software, rather than the other way around. And the things you're bending might be exactly what makes your business competitive.

If It Does Everything, It Does Nothing

Every department in a company has its own way of working. Its own documents, its own flows, its own edge cases. A system designed to automate every process across every company in every industry has to make compromises everywhere. It can't be excellent at all of them - so it ends up being mediocre at most.

You start to notice it when you're implementing. The system wants you to do things a certain way. That way made sense for whoever designed it. It might not make sense for you. But the system won't bend, so you do.

The better approach is to stop looking for one tool to rule them all, and instead build a stack of best-of-breed tools - each one purpose-built for its domain. A proper CRM for sales. A dedicated accounting system for finance. A WMS for the warehouse. Marketing automation for the marketing team.

Here's the thing about ERPs that people miss: the real value isn't that they do everything. The real value is that they're a Single Source of Truth - one place where data from across the business lives and stays consistent. That's what you actually need. And you don't need a monolith to get it.

When Pre-Made Goes Wrong - Real Numbers, Real Losses

Lidl spent $580 million over seven years trying to implement SAP's inventory management system. In 2018, they abandoned the entire project and went back to their existing in-house system. Seven years. $580 million. Back to square one. What went wrong? The project scope kept expanding, and Lidl was unwilling to adapt their processes to fit the system - which, frankly, was the right instinct. They just paid an enormous price for it.

Nike rushed an ERP deployment for demand planning and ended up with $500 million in lost sales and project costs. The system had major bugs affecting product distribution. The fix took years.

Revlon tried to consolidate two ERPs after an acquisition. The result: $54 million in recovery costs, a manufacturing facility shutdown, a 7% stock drop, and multiple investor lawsuits. They eventually scrapped the new system entirely.

HP lost $160 million in sales - $120 million in order backlog alone - because their SAP implementation couldn't handle the load when it went live.

These aren't small companies that ran out of budget or didn't have the right people. These are global organizations with dedicated IT departments, consultants, and resources that most businesses will never have. And they still got burned.

The pattern is consistent: a single, all-encompassing ERP implementation is a high-risk, high-cost, long-timeline bet. When it goes wrong - and it goes wrong often - the consequences are severe and sometimes irreversible.

The alternative isn't to avoid digitalization. It's to do it differently. Implement one module at a time. Replace one system at a time. Each step is smaller, the risk is contained, the feedback loop is shorter, and the organization has time to actually adapt. Gradual digital transformation is harder to write a press release about, but it's how companies actually succeed at it.

Custom Software as the Glue

It's not.

Custom software doesn't have to be a massive system written from zero. It can be a lightweight integration layer - something that connects your best-of-breed off-the-shelf tools, keeps them in sync, and gives you that single source of truth without forcing you to use one vendor for everything.

And this flips the vendor lock argument entirely. With this approach, if one of your off-the-shelf tools starts failing you - prices spike, features disappear, the vendor gets acquired - you replace that one module. The rest of your stack keeps running. You're not starting over.

There's also a smarter sequencing here that most companies miss. Use off-the-shelf tools first. Work with them for months. Actually figure out what your processes need, what the tool does well, where it breaks down. Then, if you've identified something genuinely specific to your business that no off-the-shelf tool handles, you build custom - with the benefit of really understanding what you're building.

The classic mistake is the opposite: building custom software before you know what you need. You end up building the wrong thing, expensively, and then living with it.

One more thing worth mentioning: AI is changing the cost equation here faster than most people realize. We've had clients who used AI to build their own custom modules for processes that no off-the-shelf tool covered well. The cost was a fraction of what it would have been two or three years ago. They eventually needed help with making it maintainable, secure, and properly tested - but the initial build happened fast and cheap.

The old argument that off-the-shelf is always cheaper than custom is still true upfront - a single subscription or license vs a full build. But over time? That gap closes quickly, especially once you factor in forced upgrades, features you pay for but never use, and the occasional repricing that doubles your bill.

Client vs Partner

When you use an off-the-shelf product, you're a customer. One of thousands, maybe millions. The vendor's decisions - about pricing, features, support, the future of the product - are made without you. You can submit a feature request. You can vote on a roadmap item. But you have no real influence.

A good custom software partner - the kind worth working with - treats you differently. They understand your business because they have to. Their work only succeeds if yours does. They grow alongside you. When something changes in your industry or your processes, they're the first call you make, not the last.

This matters more than most companies realize, because digitalization is not a project - it's a process. A company that's growing, evolving, entering new markets, or changing how it operates will need its software to change with it. The tools that fit you perfectly today might need to be extended, replaced, or connected to something new in two years. That's not a failure of planning. That's just what a healthy, growing business looks like.

This is why the ability to customize, extend, and swap out individual parts of your software stack isn't a technical luxury - it's a strategic requirement. An off-the-shelf system that can't adapt to where your business is going will eventually hold you back. And a software partner who understands your business is worth far more than a vendor who simply sells you a license.

That's not just a nice-to-have. Over time, it's a meaningful competitive advantage.

The Right Question

So: custom software or off-the-shelf?

The honest answer is that it's the wrong question.

The right questions are: What are my actual processes? What do I need to automate - and why? Where do off-the-shelf tools fit well, and where do they force me to compromise on something I shouldn't?

Start by defining your processes. Off-the-shelf tools can be genuinely valuable in this phase - not just as a solution, but as a way to discover what you actually need. Working with a real tool, even an imperfect one, surfaces requirements that no amount of upfront planning will. Sometimes you'll find that the off-the-shelf tool is good enough and stays. Sometimes working with it for six months will show you exactly what to build custom. Both outcomes are fine.

What's not fine is skipping that thinking entirely - picking a tool because it's popular, or building something custom before you understand the problem, and then spending years living with the consequences.

The companies that get this right don't pick a side in the custom vs off-the-shelf debate. They understand their own processes first, choose tools that fit those processes, build the infrastructure thoughtfully, and keep the flexibility to change pieces as the business evolves.

That's not a controversial take. It's just what good software strategy looks like.

If you have a different perspective on this topic or any questions related to the above, I’d be happy to talk:

If you're working through this kind of decision - whether you're evaluating a new ERP, rethinking your current stack, or just trying to figure out where custom software makes sense in your business - I'm happy to talk it through. Reach out.