Make a small compromise here, and a tiny compromise there, and pretty soon you’ve backed yourself into a huge compromised corner.
I should say from the start that I did this to myself. Nobody misled us, nobody sold us anything under false pretenses, and the agency we hired did roughly what we asked. The lock-in was something we walked into with our eyes open, mostly because we were not looking at the right thing.
We run a web hosting company. Our own site needed rebuilding, and rather than do it ourselves we hired an agency who worked on a well-known commercial website platform. That seemed sensible. They knew the tool, the tool was mature, and we had a business to run.
The project ran over by a couple of months. What came back was slower than the site it replaced, which for a hosting company is not a small thing. If you sell speed, having a slow website is not an inconvenience; it is a credibility problem.
But the performance was not what actually bothered me. What bothered me, once I looked properly, was how we had gotten there.
The Compromises You Agree to One at a Time
Somewhere during that build, the conversation changed shape. We stopped asking whether we could do something and started asking whether we could do it on the platform.
A design element got simplified because implementing it as drawn was awkward. An interaction got dropped. Something we wanted moved down the page because that was easier than fighting the layout system. Each of those was a small, reasonable decision, and I agreed to every one of them.
The result was a site that matched what the platform found comfortable rather than what we had set out to build. The workarounds we used left the site genuinely unpleasant to maintain. Changing existing content took real effort. Adding a page was worse. We had built ourselves a website we did not enjoy touching.
That is what lock-in actually feels like from the inside. It is not a locked door. It is a series of individually sensible concessions that you notice only in aggregate, usually too late.
Leaving Was the Easy Part
We rebuilt on Astro, a static site framework under the MIT license, and the performance problem simply went away. Static HTML is fast. There is no revelation in that.
The genuinely hard question was what we lost on the way out. The commercial platform’s real value was never the templates, and it certainly was not the design tooling. It was that people on our team who do not write code could edit pages and publish them without involving me. That is not a trivial thing to give up, and giving it up would have been a worse outcome than the one we were trying to fix.
This is the part of proprietary platforms that is easy to underestimate when you are arguing in the abstract. The lock-in is rarely the file format. It is the workflow that grew around the tool and the people who depend on it. You can export your content in an afternoon. You cannot export the fact that your colleague knows how to publish.
So I Built the Thing We Were Missing
A few years ago I would not have attempted this. Writing a content management system is not novel work but it is real work, and the maintenance afterwards is the honest reason most people rent one instead. The calculation was never close.
It is closer now. I am a CTO rather than a career developer, and I built our replacement myself with AI assistance. We describe what we want and it produces the page in our design and our voice. It took a fraction of the time it would have taken to brief someone else to do it, and I understand every part of it because I directed the whole thing.
I want to be careful about how I put that, because there is a lot of nonsense being written about AI and software. It did not build a CMS while I watched. I knew what I wanted, I made the decisions, and it did the parts that would otherwise have meant either learning a framework properly or hiring someone. The judgment was still mine, and it had to be, because the model was perfectly willing to produce things that looked right and were wrong.
But the outcome is real: a class of internal tooling that was firmly in the buy column has moved, and most organizations have not revisited the decision because nothing forced them to.
The Part Where I Disappoint You
I know where I am writing, so let me be honest rather than flattering.
We went to an open framework, and we deploy it on a commercial platform. Astro is MIT licensed and I could take that site anywhere tomorrow. Our deployment host is a proprietary service, and I chose it because it was fast to set up and it works.
That is not a purity position and I am not going to dress it up as one. What I would say is that the two decisions are different in kind, and the difference is the one that matters. If the deployment host turns unreasonable, I move the site somewhere else and the content, the structure, and the tooling all come with me, because none of them belong to the host. When the website platform turned out not to suit us, leaving meant rebuilding.
That is the distinction I would offer to anyone weighing this practically rather than ideologically. Ask what you would actually lose if a given vendor stopped being a good option tomorrow. Sometimes the answer is a config file and a weekend. Sometimes it is everything you have built, because the thing you built cannot exist outside the thing you built it on. Those are not the same risk and they do not warrant the same caution.
What I Would Tell My Past Self
Not much about the platform, honestly. It is a capable tool and plenty of people are well served by it.
What I would say is: listen for the moment the requirements start being written backwards. When someone says “we can’t do that in the system” and the group’s instinct is to change what we want rather than to ask whether the system is still the right one, a decision has just been made that nobody framed as a decision.
That is the point where it is still cheap to reconsider. We went past it repeatedly without noticing, and by the time I was paying attention we had a slow site, a painful workflow, and a couple of months of agency invoices behind us.
The rebuild took less time than the original project overran by. That is the detail I keep coming back to.
Nickola Naous is co-founder and CTO of Flashcloud, a web hosting company. He has spent nearly two decades building and running hosting infrastructure, and previously co-founded and sold a hosting company.
Be First to Comment