When should you build, and when should you buy? We sat down with CTO Thomas Bacon, to talk about why the answer is so complex, and how to think about the biggest risk you haven’t considered:
Key Takeaways
- Vendor lock-in is when a technology decision becomes too expensive to undo. For website builds, that usually means a technology choice that looked right at launch becomes a constraint on everything that follows, and changing course means a six-figure migration project.
- Open source doesn’t exempt you from lock-in. In choosing open source, companies trade vendor dependency for maintenance burden, security patching, and the commercial ecosystem that grows around many open source platforms. There are pros and cons to both.
- The pain scales with integration depth. A small tool is easy to swap. A platform your marketing, sales, and engineering teams have built workflows around is not.
- The lock-in landscape has shifted, but the risk hasn’t. Modern platforms are more interoperable, so you’re less likely to be trapped by a technical inability to export your data and more likely to be trapped by the organizational cost of switching.
The Vendor Lock-In Problem
In a website build, the platform decision feels like a technical call. Your dev team throws out acronyms, your agency presents a comparison deck, and everyone nods. Decision made.
Too often, that’s a mistake.
Vendor is not just a technical call. It’s a business risk decision, and most teams make it without the right information.
By the time that becomes obvious, you’re three years in, your systems are deeply integrated, and your vendor’s new account manager is on the phone with a very different number than the one you signed up for.
This piece is about why that happens, and how you can avoid it.
What Vendor Lock-In Means (and Why It Sneaks Up on You)
Vendor lock-in is simple in theory: you choose a technology, and now you’re stuck with it. The repercussions are a lot more insidious.
Most companies don’t feel locked in at launch.
If the platform works and everything integrates cleanly, the team is happy. But lock-in reveals itself later, when changing course would require rearchitecting systems three teams depend on, or when a contract renewal arrives with a number that would have stopped the deal entirely if you’d seen it upfront.
So, most people are dealing with the problem years after they should be, which means CTOs are often left choosing between a painful, year-long platform switch and shelling out more budget than they’d ever expected.
It’s a common problem. It’s an expensive one.
And, contrary to popular belief, it can’t be solved by simply “going open source,” because open source comes with its own version of lock-in, too. You still have to maintain it, patch it, and work around its limitations. The lock is still there, and still expensive. It’s just different (we’ll get into the hidden costs shortly.)
So, if your org has a CMS decision coming up, the best way to think about it is this: every technology decision is a lock-in decision. The question is which constraints you’re choosing to accept, and whether you’ve actually thought them through.
The Build vs. Buy Question
Every website project eventually surfaces some version of this: do we build it ourselves, or do we buy a platform that handles it for us?
The way that question usually gets asked is: “Can we afford to build?”
But that’s the wrong question.
The right question is: “Can we afford to be stuck?”
Build vs. buy is a risk and control tradeoff. A proprietary platform might check 95% of your boxes on day one, and that’s genuinely compelling.
But the 5% it doesn’t cover tends to surface at the worst possible time, and your options for addressing it are constrained by what the platform allows.
Custom builds and open source solutions trade upfront cost for long-term flexibility. You own the codebase. You own the decisions. When something needs to change, you change it – you don’t file a support ticket and wait.
Neither path is objectively correct. But to make this decision well, you need to frame it as a long-term risk question, not a short-term budget question.
Where Proprietary Platforms Win Out
Let’s be fair. The appeal of proprietary platforms is real, and dismissing it doesn’t serve anyone.
First of all, there’s the speed to launch. A well-built SaaS platform can get you live in weeks. There’s no infrastructure to configure, no security patching to schedule, no uptime monitoring to set up. That’s all handled. A team of engineers at the vendor is keeping your application online while you focus on your actual business.
For organizations without large internal engineering teams, that’s a genuine strategic advantage. The all-in-one support model means you have one vendor to call when something breaks, and the onboarding actually works.
And yes, the upfront cost is lower. On paper, at contract signing, proprietary platforms often look like the obvious financial choice.
The catch is that “on paper” and “at contract renewal” are sometimes very different documents.
Why Open Source and Custom Builds Win Long-Term
But if your organization has the longevity, the personnel, and the budget to handle it, the open source/custom development route is the objective winner.
You own the codebase. That means portability: if you need to move, you can. There’s no migration penalty baked in by design, no data held hostage behind an export tool that exports 80% of what you actually need.
There’s also the asset of community. Mature open source platforms have ecosystems of developers, plugins, and integrations that no proprietary vendor can match in breadth. When you need something built, you have options.
And crucially, there’s no arbitrary cost ceiling. Your bill doesn’t change because a private equity firm acquired your vendor and decided to rationalize the pricing model. The cost of running your platform is largely within your control.
And because you own the infrastructure decisions, you can optimize aggressively. Performance and scalability aren’t features you unlock at the next pricing tier.
They’re engineering problems you solve on your own terms and your own timeline.
So, yes. It’s more expensive upfront, and it requires a team who knows what they’re doing. But if you have both, open source is going to be better for you.
Costs That Show Up 12-18 Months Later
At the beginning of your build vs. buy decision, the risk feels abstract. About 12-18 months later is where it becomes concrete. Four scenarios worth taking seriously:
1. The acquisition scenario.
A vendor that was affordable and well-run gets purchased – say, for example, by private equity. What follows is predictable: cost rationalization, contract restructuring, and a call from a new account manager with a new number.
As Workhorse CTO Thomas Bacon says, “We’ve seen a $50/month security tool land a $5,000/month renewal quote after acquisition.” That particular story had a happy ending because the tool was small and swappable. But when it’s a core platform with three years of integrations built around it, you end up with a negotiation where you have no leverage.
2. Integration depth multiplying lock-in severity.
A small, standalone tool is easy to replace. A platform your sales team, marketing team, and engineering team have all built workflows around is a different problem entirely.
The pain of migration scales with how embedded the system is. Before you sign, ask yourself: if this vendor doubles their price in two years, how long would it take us to move? If the answer is “six to twelve months and a significant engineering effort,” you need to price that risk into the decision.
3. Features you didn’t know you needed.
Nobody audits what they’re losing until it’s gone. Capabilities that seemed like edge cases during the sales process become critical dependencies once your team builds around them.
A workflow that works around a platform’s limitations is still a workflow, and when the platform changes or disappears, so does the workaround. Every business has features that only reveal their importance in absence.
4. “We’ll deal with it later.”
Small things compound when you’re choosing your CMS. Traffic thresholds that trigger automatic tier upgrades. Forced migrations to new infrastructure. Data export costs.
The things that seemed manageable at contract signing are exponentially bigger in a few years.
“Later” always arrives, and it usually arrives during a period when you have other priorities. What looked like a six-month problem on the roadmap is now a six-figure unplanned project. CFOs find this particularly unpleasant.
Each of these become significant expenses after a few years of use, which is why it’s worth a business risk discussion up front. This is a conversation for your finance team, not just your IT team, and it’s important your C-Suite understands why that’s important.
How to Make the Right Call for Your Organization
There’s no universal answer in the build vs. buy debate. Any article that ends with “always use open source” or “always go proprietary” is selling you something.
The honest rubric starts with one question: what kind of company are you?
A manufacturer shouldn’t be self-hosting an open source email platform to save money. The cost savings on paper will evaporate the moment the team needs to maintain it, and email is not your competitive advantage. Use Google Workspace. Use Microsoft 365. Pick one and move on.
Similarly, an AI company probably shouldn’t be on a drag-and-drop website builder. The mismatch between your technical capabilities and your platform constraints will frustrate you within a year.
The important part is to match the decision to your organization’s actual profile:
- Team size and engineering capacity. Do you have the internal resources to maintain an open source platform, or does that cost get externalized to an agency indefinitely?
- Content complexity. A marketing site with 20 pages has different requirements than an enterprise platform with thousands of pages, dynamic personalization, and multilingual content.
- Integration requirements. How many systems need to talk to your website? How deeply? What happens to those integrations if the platform changes?
- Growth trajectory. What does this platform look like at 3x your current scale? At 10x?
Some practical due diligence before you sign anything:
First, go to Reddit. Search for your shortlisted platforms alongside terms like “price increase,” “renewal,” or “limitations.” You will find real stories from real customers who have been through exactly what you’re trying to avoid. People are not shy about this.
Second, take the time to push past a platform’s sales team. Ask for an engineer on the call. Salespeople will spin your concerns into features. Engineers, in our experience, are often refreshingly honest about what the platform doesn’t do well. An honest engineer saying “here are our limitations” is more valuable than a polished demo.
Always remember to ask directly about pricing history as well. Have enterprise customers seen unexpected cost increases? What triggers an upgrade? What are the API rate limits at scale?
And finally, pressure-test the “95% fit” assumption. Every platform will get you most of the way there. The question is whether the remaining 5% represents a minor inconvenience or a fundamental gap in how you need to operate.
In a sense, every platform decision is a lock-in decision. Your job is to make sure you’re locked into the choice that is best for each department in your organization – and that includes more than just IT.
Not every platform is wrong for every company. But every company deserves to make this decision with eyes open.