If you can’t log into your own hosting, move your domain, or hand your code to a new developer without asking someone’s permission first, you don’t really own your website. You’re renting it from whoever does. That’s the thing most business owners don’t discover until the day they want to make a change and realize they can’t. Owning your tech stack means the accounts, the access, and the code your business runs on are in your name, under your control, and available to you whether or not the developer who built it is still in the picture.
The good news is that fixing this has almost nothing to do with technical skill. It’s about who holds the keys. And you can get every one of those keys into your own hands without a single line of code.
What being held hostage actually looks like
It rarely feels dramatic in the moment. Usually it’s a small friction that adds up. You want to update a phone number on the site and you have to email your developer and wait two days. You decide to try a new email provider and find out your domain is registered under their account, not yours. You get a quote from someone else, they ask for access to your code, and you realize you have no idea where the code even lives.
Most of the time, none of this is planned. A single developer holding your domain, your hosting, and your only login usually isn’t setting out to use that as leverage. It’s just the natural shape of a solo engagement: one person sets everything up, and it’s simpler for them to keep it under their own accounts than to walk a new client through creating five separate logins in the first week of working together. You don’t push back, because you don’t know enough about the technical side to know what you should have been asking for in the first place. That gap is exactly what turns into a problem later.
It surfaces when something goes wrong: a disagreement over scope, a slow response, a falling-out over money or a missed timeline. That’s the moment the access imbalance actually matters. A developer who holds every key has very little practical reason to keep treating you like a client instead of someone with nowhere else to go, and the shift can happen without any single deliberate decision on their part. Most developers won’t act on it. But the setup gives them the option, and you usually don’t find out which kind you hired until you’re already stuck.
The problem, most of the time, isn’t malice. It’s that the setup quietly concentrates control in one place, and you only feel it once you try to move, or once the relationship sours.
The real test is simple. If your relationship with your current developer ended tomorrow, could you keep your website running and keep making changes to it? If the honest answer is no, or “I’m not sure,” you’re closer to held hostage than you think.
The accounts that should always be in your name
There’s a short list of accounts that form the foundation of your web presence. Every one of them should be registered under an email address your business owns and controls, not your developer’s. This is a genuine checklist, so treat it like one and verify each item:
- Your domain registrar. The account where yourdomain.com is registered.
- DNS management. The settings that point your domain at your website and mail. Sometimes this lives with the registrar, sometimes separately.
- Hosting. The server or platform your website actually runs on. The account and its billing should be yours.
- Your code repository. Where the actual website code is stored and version-tracked, usually a service like GitHub or GitLab. You should have owner-level access to the account, not just be a guest on your developer’s.
- CMS or admin access. An administrator login to WordPress, Shopify, or whatever runs your site, at the highest permission level.
- Analytics and search tools. Google Analytics, Search Console, and similar. Losing these means losing your entire history of traffic and performance data.
- Every credential in a place you control. Logins stored in a password manager your business owns, so no single person is the only keyholder.
Two of these matter more than the rest: the domain registrar and DNS. Whoever controls those two can point your domain anywhere they want, including nowhere. Lose control of your domain and you don’t just lose a website. You lose your email, and anything else in the business that verifies itself through that domain. It’s the closest thing your business has to an off switch for its entire online presence, and it shouldn’t sit in someone else’s account.
That doesn’t mean your developer shouldn’t have access to it. They usually need to, to point subdomains, set up email delivery, configure a CDN, whatever the actual work requires. What matters is that the account itself is yours, and access is something you grant, not something you’re given.
If your developer needs access to do the work, and they do, they can be added to accounts that belong to you. That order matters. You own the account, and you grant them access. Not the other way around.
Access isn’t the same as control
This is the distinction that trips people up. Being able to log in and change things feels like ownership, but it isn’t. Plenty of business owners have admin access to a site they don’t actually control, because the account underneath was created and is billed by someone else. Access can be revoked. Ownership can’t be, at least not without your say-so.
Think of it like the difference between having a key to an apartment and being on the lease. The key lets you in today. The lease is what protects you when the situation changes. You want to be on the lease for everything your business depends on, and then hand out keys to the people who help you run the place.
Getting there is usually a calm, boring administrative conversation, not a confrontation. You ask your developer to confirm which accounts are in whose name, transfer anything that’s in theirs to yours, and add them back as a collaborator. A good partner will do this without friction, because it doesn’t cost them anything real. What they’re selling you is their work and their judgment, not their grip on your login credentials.
Building your jump-ship kit
Owning the accounts keeps you in control day to day. A jump-ship kit is what lets you actually leave, or bring in a second developer, without the whole thing grinding to a halt. It’s the set of things a new developer would need to pick up where the last one left off. If you have these on hand, switching becomes a normal business decision instead of a crisis:
- A current export or backup of your website and its database.
- Access to the code repository, with the recent history intact.
- A short document listing where everything lives: registrar, host, DNS, key plugins or services, and how they connect.
- Any custom work explained in plain terms, so its logic isn’t locked in one person’s head.
- The full list of accounts and how to access them.
You don’t need to understand every technical detail in that kit. You just need it to exist and to be yours. The point isn’t to prepare to fire anyone. It’s that having the option changes the entire dynamic. When you can leave, you almost never have to, because the relationship stays honest on both sides.
The difference between stable and stuck
Being deeply integrated with your developer is usually a good thing. They know your history, your quirks, the reasons behind decisions made years ago that would take someone new weeks to piece together. That familiarity is worth something real, and none of this is an argument against it.
The problem is when that same familiarity gets confused with being unable to leave. If there’s real dissatisfaction, communication that’s stopped feeling responsive, work that used to move faster and now doesn’t, or just a general sense that something’s off, and none of it ever gets addressed because the relationship feels too woven into the business to touch, that’s not stability anymore. That’s an unaddressed problem with a long history attached to it.
There are a few reasons this tends to happen. Switching feels riskier than it actually is when ownership was never sorted out in the first place, so a manageable transition gets imagined as a crisis, which is exactly what the checklist above is meant to fix. Bringing up dissatisfaction directly is uncomfortable, especially with someone you’ve worked with for years, so it’s easier to let it go unsaid than to have the conversation. And without a technical background, it’s genuinely hard to know whether a frustration is a real, fixable problem with this specific developer, or just how working with any developer goes, so people often stay by default rather than by an actual decision.
If you’re not sure which one you’re looking at, that uncertainty is normal, and it’s exactly the kind of thing an outside, technical perspective can help sort out. Sometimes the honest answer is that everything’s fine and what you’re feeling is just ordinary friction. Sometimes it’s a specific, fixable problem nobody’s ever said out loud. Either way, you don’t have to work that out alone or guess.
None of that means you should go looking for reasons to leave a good partnership. It means the opposite: once you own your accounts and have a real jump-ship kit, staying becomes a choice you keep making, not a position you’re stuck in because leaving looks too hard. That’s what makes it a partnership that can actually grow with the business, instead of one nobody’s gotten around to questioning.
Why anyone worth hiring wants you to have all of this
Here’s the part that sounds strange coming from a web development agency: we think you should be able to walk away from us, or from any developer, at any time. Not because we want you to, but because a client who stays only because they’re stuck isn’t really a client. They’re a hostage who hasn’t found the exit yet. That’s not a relationship worth building anything on.
The developers who resist giving you ownership are usually the ones who know their work can’t hold you on its own merits. The ones who hand you every key on day one are betting that you’ll keep working with them because the work is good and the partnership is easy, not because you can’t get out. That’s the bet worth making, for you and for whoever you hire.
A strong partnership with whoever runs your site is genuinely the goal, whether that’s one developer or a full team. You want someone who knows your site, cares about it, and moves fast when something breaks. Ownership doesn’t undercut that. It’s what makes it a partnership instead of a dependency. You hold the keys, you make the decisions, and you choose to keep working with the person who’s earned it.
Frequently Asked Questions
How do I find out who currently owns my domain?
Search a public “WHOIS” lookup for your domain name, which shows the registrar and often the registrant. If the details are hidden or point to your developer, ask them directly which account it’s under and request a transfer into one you control.
Can my web developer refuse to give me my own code?
It depends on what your contract says. In many custom-development arrangements the client owns the final code, but this is exactly why ownership should be written into the agreement up front. If it isn’t addressed, you can be left negotiating for something you assumed was already yours.
Won’t transferring all these accounts break my website?
Done properly, no. Account and billing transfers don’t change how the site runs, and a careful developer moves things without downtime. The risk comes from doing it hastily or without a backup in place, which is why the jump-ship kit matters before you start.
I trust my developer completely. Do I still need to do this?
Yes, and it’s not about trust. Even the best relationship can end for reasons that have nothing to do with a falling-out: they get busy, they change direction, your needs change. Ownership protects you from the situation, not from the person.
If I can only fix one thing on this list right now, what should it be?
Your domain registrar and DNS, ahead of everything else. Losing access to your website or your analytics is a real problem. Losing control of your domain can take down your email and your entire online presence at the same time, and checking who actually controls it is usually the fastest thing on this list to verify, and the easiest to fix if it’s wrong.
Take an hour and check your keys
Before you do anything else, find out where you actually stand. Sit down and go through the account list above, one line at a time, and mark which ones are truly in your name. The gaps you find are your to-do list. If you’re not sure how to read what you’re looking at, or something’s felt off for a while and you can’t quite tell if it’s a real problem or just how things go, that’s exactly the kind of thing we’re happy to walk through with you, no strings attached and no pressure to hand us anything. Reach out and we’ll help you get a clear picture of what you actually own, and whether what you’re feeling is worth acting on. Either way, the goal is the same: you, holding your own keys, and making an actual choice about who holds them alongside you.
