Here’s a question that tells you more about your website than any design review:
If your developer disappeared tomorrow, could a competent stranger open your codebase and keep going?
If the answer is yes, you own your website. If the answer is “well, it’s built on [specific builder] and only they really know how it’s wired” — you don’t own it. You rent access to it. And rent always comes due at the worst possible moment.
The three ways you get locked in
Lock-in rarely looks like a trap when you sign up. It looks like convenience.
Platform lock-in. Your site lives inside a builder’s proprietary format. The layout, the logic, the content structure — none of it exists as portable code. Leave the platform and you’re not migrating, you’re rebuilding.
Knowledge lock-in. One person — an agency, a freelancer — is the only one who understands how it all fits. Custom work should avoid this, but messy, undocumented custom code creates the same trap as a builder. The lock-in is in someone’s head.
Data lock-in. Your customers, orders, and content can’t be cleanly exported. The most valuable thing you own is held hostage by the platform that stores it.
Any one of these turns a routine decision — switch developers, change platforms, add a feature — into an expensive ordeal.
Why this is a business issue, not a tech one
Founders file “how the website is built” under IT and move on. That’s the mistake. Portability shows up on the balance sheet:
- Pricing power over you. A platform you can’t leave can raise prices, deprecate features, or change terms — and your only options are pay or rebuild.
- Frozen roadmap. Want a feature the platform doesn’t support? You wait for them, or you don’t get it. Your roadmap is capped by someone else’s.
- Continuity risk. If your site is one person’s secret, you have a single point of failure on critical infrastructure.
- Exit value. If you ever sell the business, a clean, owned, documented codebase is an asset. A tangle of platform dependencies is a liability a buyer will discount.
Portability is just leverage by another name. It’s the freedom to walk away — which is exactly what stops anyone from squeezing you.
What owning your stack actually looks like
You don’t need to be technical to insist on it. Ask for these, in plain terms:
- The code, in your repository. Hosted on your GitHub, under your account. Not “on our servers.”
- Standard, boring technology. React, Next.js, Astro, plain HTML/CSS — things any competent developer already knows, not a niche proprietary system.
- A documented handover. A README, a walkthrough, environment notes. Enough that the next person starts in an hour, not a month.
- Your data, exportable. Customers, orders, content — yours to take, any time, in a standard format.
- Your own hosting and domain. On infrastructure you control, so moving is a config change, not a hostage negotiation.
When I hand off a project — Modern K.B.S., North Peak Power Systems, any of them — it comes with the code, a walkthrough, and the keys. Including the part where the client could, in theory, never speak to me again. That’s the point. You should be able to.
The clause to put in your next contract
One line settles it: “All source code, assets, and data are the property of the client and will be delivered in a standard, portable format on completion.”
A developer confident in their work signs that without blinking. One who hesitates is telling you exactly how the relationship ends if you ever try to leave.
You wouldn’t run your business from a building you can be evicted from on a whim. Don’t run it from a website you can be evicted from either.
I’m Divyansh Sood. Every project I ship comes with the code in your repo, a written handover, and the keys — including the option to never speak to me again. 9 live builds since 2022. If portability is something your team has been burned on before, email me — I read every brief personally.