“We need to make a small change to the website. How much will that cost?”
“£400.”
“It’s just changing a phone number.”
“Yes, but I need to access the custom system, which takes time to spin up, and…”
This is vendor lock-in. And it’s costing UK businesses thousands of pounds every year in maintenance fees that shouldn’t exist.
I’ve taken over dozens of websites where the previous developer - intentionally or not - created a situation where the business owner had no choice but to keep paying. Sometimes it’s malicious. Often it’s just poor practice. Either way, it leaves you stuck.
Here’s how it happens and how to avoid it.
The Common Lock-In Tactics
1. Accounts in the developer’s name
This is the most common and most dangerous form of lock-in.
Your domain registration is in their name. Your hosting account is in their name. Your email is routed through their account. You’re paying them, and they’re paying the actual providers - with a markup.
Why developers do this:
- “Easier to manage everything in one place”
- “We can respond faster if there’s an issue”
- “You don’t want to deal with technical support”
What it actually means: If you leave, you have to ask permission to take your own domain name. They control whether your website stays online. You can’t even access your own email without going through them.
I worked with a restaurant that wanted to switch developers after two years of poor service. The domain was in the developer’s name. It took three months and a solicitor’s letter to get the domain transferred. During that time, they couldn’t make any changes to their website.
2. Custom platforms that only they understand
“We’ve built you a custom content management system tailored specifically to your business.”
Sounds good, right? Custom-built for your needs.
The reality: They’ve created something that only they can maintain. Other developers won’t touch it because understanding someone else’s custom code takes longer than rebuilding.
What to look for:
- Phrases like “proprietary system” or “custom framework”
- Refusal to use standard platforms like WordPress
- Claims that standard platforms “won’t work” for simple business sites
- No documentation for the custom system
I’ve seen this with everything from property websites to plumber booking systems. In every case, the “custom” features could have been achieved with WordPress plugins or standard platform extensions.
One client was paying £250/month for “custom platform maintenance.” I migrated them to WordPress with the same functionality. Maintenance cost: £0 for most months, £150 when they need actual changes.
3. Hosting markup schemes
Your developer charges you £50/month for hosting. The actual hosting costs £8/month.
Common excuses:
- “We provide premium hosting”
- “This includes security monitoring”
- “We bundle support with hosting”
Some markup is fair - if they’re providing real services like security monitoring, backups, and fast support. But 500% markup for basic shared hosting is lock-in, not service.
The trick is you don’t know what the actual hosting costs because the account is in their name. You only see the invoice from them.
4. Refusing to provide source code
“The code is proprietary. We can’t share it.”
Unless you specifically hired them to build a product you plan to sell, this is rubbish. You paid for the website. You own the website. That includes the code.
Legitimate exceptions:
- Licensed themes or templates (you get the files, not the rights to resell)
- Third-party plugins (same - you can use them, not sell them)
- Actual proprietary software they’ve built as a product
Not legitimate:
- The HTML, CSS, and JavaScript of your website
- Custom features built specifically for your site
- Configuration files and content
If they won’t provide the source code, they’re keeping you dependent.
5. Vague contracts and verbal agreements
“Don’t worry, we’ll sort out the details as we go.”
This is how lock-in happens accidentally. Without clear terms about ownership, access, and deliverables, you end up in disputes later.
What should be in writing:
- Who owns the domain and where it’s registered
- Who owns the hosting account
- What platforms and technologies will be used
- What access you’ll have
- What documentation will be provided
- Who owns the code and content
- What happens if the relationship ends
I’ve seen several cases where both parties genuinely thought they were being reasonable, but had different assumptions about what was agreed. Get it in writing.
6. Deliberate complexity
Making simple things complicated to justify ongoing fees.
Examples I’ve seen:
- Requiring developer intervention to update business hours
- Charging £150 to add a blog post
- Making the admin interface so confusing that you “need” them to make changes
- Using obscure technologies that few other developers know
One client had a WordPress site where the developer had hidden the standard admin panel and created a custom interface. The custom interface could update text, but not images. Images required calling the developer - £80 per image change.
I showed them the standard WordPress admin that had been there all along. They’d been paying for image updates they could have done themselves for free.
How to Avoid Lock-In
Before you sign
Ask these questions before you commit to a developer:
1. “Who will own the domain and hosting accounts?” The answer should be: “You will. We’ll help set them up in your name.”
2. “What platform will you use to build the site?” Look for: WordPress, Shopify, standard frameworks like Astro or Next.js. Be cautious of: “Our own platform,” “proprietary system,” vague non-answers.
3. “Will I have full admin access to the website?” The answer should be: “Yes, from day one.”
4. “What happens if we part ways?” They should have a clear answer: “You keep everything. We’ll provide documentation and you can hire anyone to maintain it.”
5. “Can I see the credentials for all accounts?” If they say you’ll get them “at the end” or “when it’s finished,” that’s a warning sign. Insist on receiving credentials as accounts are created.
6. “Will you provide the source code?” The answer should be: “Yes, it’s your website. You’ll have full access to all files.”
7. “What documentation will I receive?” Look for: Setup guide, admin instructions, list of plugins or services, contact information for all accounts. Be cautious of: “We provide ongoing support, so you won’t need documentation.”
Contractual protections
Include these clauses in your contract:
Ownership clause: “Client owns all deliverables including but not limited to: source code, graphics, content, domain name, and hosting accounts. All accounts will be registered in client’s name with credentials provided to client upon creation.”
Access clause: “Client will receive admin-level access to website and all related services no later than project handover. This includes full FTP/file access, database access, and administrator accounts.”
Separation clause: “Upon project completion or relationship termination, developer will provide: complete source code, database export, documentation of all systems and dependencies, and contact information for all service providers.”
Platform clause: “Website will be built using [specific platform or framework], with documentation sufficient for any developer with experience in that platform to maintain the site.”
These clauses don’t prevent hiring the developer. They just ensure you’re not trapped if things don’t work out.
During the project
Stay involved enough to ensure you’re getting what was promised:
Ask for credentials as things are set up:
- Domain registered? Get the account details.
- Hosting purchased? Get the login.
- Admin panel created? Get the access.
Don’t wait until the end to request these.
Verify you can log in: Actually log into the accounts. Make sure the credentials work and you have proper access levels.
Request documentation in progress: Ask for the documentation while they’re building, not after they’re finished. It’s easier for them to document as they go, and you can verify it’s actually useful.
Use a password manager: Store all the credentials in a secure password manager like 1Password or Bitwarden. Share access with anyone else in your business who needs it.
After project completion
Test your independence:
Can you log into everything?
- Domain registrar
- Hosting account
- Website admin panel
- Email admin
- Any other services
Can you make basic changes? Try updating a page, adding a blog post, changing an image. If you can’t do basic tasks, you’re locked in.
Could you switch developers? Review the documentation. Could you hand it to another developer and have them understand what’s there? If not, ask for better documentation.
Are you paying for services directly? Check your bank statements. You should see charges from the hosting company, domain registrar, etc. - not just charges from the developer.
If any of these fail, address it immediately while you still have a relationship with the developer.
Red Flags to Watch For
Some warning signs that you’re heading toward lock-in:
Resistance to transparency: If they get defensive when you ask about account ownership or access, that’s a problem. Legitimate developers expect and welcome these questions.
Vague technical explanations: “It’s complicated” or “You won’t understand the technical details” often means they don’t want you to know it’s actually simple.
Bundled services with unclear pricing: When hosting, domain, support, and everything else are bundled into one monthly fee, you can’t tell what you’re actually paying for.
No documentation: “Just call us if you need anything” sounds like good service but creates dependency.
Unusual technology choices: If they’re using frameworks or platforms you’ve never heard of for a simple business website, ask why. There should be a good reason.
Pressure to sign quickly: “This price is only available if you commit today” is a sales tactic that prevents you from thinking through the relationship.
What Good Looks Like
In contrast, here’s what you should expect from a professional developer:
Transparent account setup: They help you register your domain and set up hosting in your name. They might recommend providers, but you’re the account owner.
Standard platforms: They use established platforms and frameworks. They can explain why they chose a particular option for your needs.
Full access from day one: As soon as an account or admin panel exists, you get credentials. No waiting until the end.
Clear pricing: Separate line items for development, hosting, domain, email, support. You know what each thing costs.
Documentation as deliverable: Documentation isn’t an afterthought. It’s part of what you’re paying for.
Independence encouraged: They want you to be able to make basic updates yourself. They explain how things work rather than keeping it mysterious.
Clear support terms: You know exactly what support is included, what costs extra, and what you can do yourself.
When Lock-In Is Justified
There are a few situations where some dependency is reasonable:
Complex custom applications: If you’ve hired someone to build actual software - not just a website - some ongoing relationship makes sense. But you should still own the code and have documentation.
Specialized technology: If you specifically chose a niche platform for good reasons, you’ll have limited developer options. That’s fine if it was an informed choice.
Managed services: If you’ve explicitly hired someone to manage everything and you don’t want to deal with any of it, some lock-in is inherent. But you should still have access and the option to leave.
The key is informed consent. Lock-in is only a problem when it’s hidden or misrepresented.
Breaking Existing Lock-In
Already stuck? You have options:
Request access formally: Send a written request for all account credentials and documentation. Many developers will comply when asked formally.
Review your contract: Check what was actually agreed. You might have more rights than you realized.
Offer to pay for transition time: If the developer needs to document things or set up access, offer to pay their hourly rate for that time. It’s cheaper than staying trapped.
Account recovery: If they won’t provide access to accounts in your name, contact the service providers directly with proof of ownership.
Legal pressure: A letter from a solicitor often produces results without going to court. Most developers don’t want legal disputes over access.
Walk away: Sometimes it’s cheaper to rebuild than to fight. If the site is simple, starting fresh with a new developer might cost less than months of disputes.
What I Do Differently
When I take on a project:
You register the domain and hosting - I send you links to the providers and guide you through registration, but it’s in your name from the start.
Full access immediately - As soon as your hosting is set up, you get the credentials. Same with the admin panel when it exists.
Standard platforms only - Astro for static sites, WordPress for content-heavy sites. Any developer can take over.
Documentation included - Every project includes a handover document explaining what was built, how to use it, and how to maintain it.
Flat project fees - You pay for the website build. Hosting, domain, and services are separate, and you pay those providers directly.
No ongoing fees - Unless you want me to maintain or update the site, you owe me nothing after the project is complete. You’re free to leave any time.
This is the foundation of our own-outright website service, avoiding lock-in from the start.
The goal is building websites, not building dependency.
Questions to Ask Right Now
If you currently have a developer or are evaluating one:
- Can you log into your domain registrar account?
- Can you log into your hosting account?
- Do you have admin access to your website?
- Do you know what the actual hosting costs, separate from what you pay your developer?
- Could you download a complete backup of your site right now?
- Do you have documentation explaining how your site works?
- Could another developer take over with the information you have?
If you answered “no” to any of these, you’re experiencing lock-in. Address it now, before you need to make an urgent change or the relationship sours.
Lock-in isn’t always malicious, but it’s always expensive. The developer who makes themselves irreplaceable is maximizing their income at your expense.
The developer who makes you independent is building a relationship based on quality work, not dependency.
You should hire a developer because they’re good at what they do, not because you have no other choice. Make sure you’re set up that way from the start.
