When we take over a website for a new client, one of the first places we look is the list of administrator accounts.
It usually tells a story. On one recent site, we found five admins. One belonged to the owner. The other four belonged to freelancers, hired years apart, from different companies, most with email addresses that no longer worked. None of them had touched the site in years.
All of them could still log in.
The owner didn’t know those accounts existed. Nobody had removed them, because removing them was nobody’s job. Each developer was hired to fix one thing, fixed it (more or less), got paid, and moved on. What they left behind wasn’t just their work. It was their access, their shortcuts, and their choices about how the site should run.
That admin list is a fossil record. It shows how the site was really built: one decision at a time, by people who were never going to be around when the decision came due.
When a developer disappears, your website doesn’t stop. It keeps running on every decision they made: the plugins they chose, the access they still have, the shortcuts they took. Nothing gets maintained, nothing gets updated, and you’re left holding the bag for choices you never knew were made.
That’s the part that surprises most business owners. A website looks like a finished thing: something you bought, like a sign or a delivery van. It isn’t. It’s a pile of decisions that are still running.
Every plugin someone installed is a decision. Every setting someone changed, every account someone created, every piece of custom code someone wrote: each one is a decision with a bill attached. The bill is maintenance. Updates that need applying, conflicts that need catching, security holes that need closing. And it comes due whether or not anyone’s there to pay it.
Here’s the rule we’ve learned from years of inheriting other people’s piles: every line written is a line owned. The question is never whether the site works today. It’s who pays when the bill comes due. When a developer vanishes, the answer defaults to you, the site owner.
Tired of dealing with this yourself? That's exactly what we handle.
See our plans →Websites end up as unowned decision piles because of a simple mismatch: developers get paid to build, not to own. The build cost is visible and paid once. The ownership cost (updates, fixes, security) is invisible, ongoing, and lands on whoever is left when the builder moves on.
There’s no villain in this story, which is what makes it so common. A freelancer quotes the work, does the work, and gets paid for the work. Owning the consequences for the next five years was never in the quote. And the client generally can’t evaluate the technical advice they’re given, so the cheapest bid usually wins, and the maintenance contract gets signed invisibly, by the client, without anyone saying so out loud.
It shows up in the work, too. We call it cowboy code: custom-built solutions where a well-maintained, off-the-shelf option already existed. Custom code isn’t wrong. Sometimes it’s exactly right. But every custom line is a line someone has to own, and the developer who wrote it is rarely the one who ends up owning it.
The pattern isn’t about where a developer lives or what they charge per hour. It’s about accountability. A developer with no maintenance relationship and no reason to be reachable next year will build differently than one who knows they’ll be answering for the site in five. Same skills, different incentives, very different pile.
You can. AI tools will genuinely build you a website in minutes. What they won’t do is own it. AI generates the same pile of decisions a developer would, faster and larger, then walks away from every one of them the moment the chat ends. The building was never the hard part. The owning was.
This is the twist that makes the old problem bigger, not smaller. When your developer disappeared, at least the pile was built by someone who understood it once. An AI-built site is a pile of decisions made at high speed by a tool that keeps no memory of why, assembled by an owner who, through no fault of their own, can’t evaluate what they’re now holding.
Which plugins did it choose, and are they maintained? What access did it configure? What happens when the next WordPress update conflicts with something it generated? The AI doesn’t know. It’s not coming back to check. There’s no email address to go dark, because there was never anyone home.
None of this means AI-built sites are bad. It means they change nothing about the real question. Speed of building was never what protected a business. Accountability for what’s built is, and that part still requires someone who answers when the bill comes due.
If your developer has stopped responding, the priority is control, not blame. Confirm you can access your three critical accounts: domain registrar, hosting, and WordPress admin. Then document what exists before changing anything. You’re taking inventory of a pile someone else built, and the inventory comes first.
Here’s the order we follow when a site like this lands on our desk:
Secure the front doors. Domain registrar, hosting account, and WordPress admin: verify you have working logins to all three, registered to an email you control. If any of them are in the developer’s name, start recovery with that provider now; it’s the slowest step, so it goes first.
Remove the ghosts. Go to your WordPress admin user list. Every account belonging to someone who no longer works on your site is a live key in a stranger’s pocket. Remove or demote them, and remember that admin accounts spawn other credentials. Application passwords, FTP accounts, and API keys created by an old developer outlive their user account unless removed separately.
Change what’s left. New passwords on everything you’re keeping, starting with hosting and admin accounts. If the old developer ever had access to your email, change that too.
Document before you renovate. List your plugins, your theme, anything custom you can identify, and when things were last updated. Screenshots of key pages help whoever works on the site next. Resist the urge to start deleting things you don’t recognize. Some of those decisions are load-bearing.
Then get the pile assessed. Once you control the accounts, someone qualified should evaluate what you actually own: what’s outdated, what’s abandoned, what’s custom, and what’s quietly waiting to fail.
And if you’d rather not deal with any of this yourself, that’s fair. It’s exactly what our decision inventory is for: we handle the access review, the stale accounts, and the assessment, and hand you a plain-English accounting of what you own. You get control back without spending your week in admin screens.
Real ownership means every decision on your site has a name attached to it. Access is controlled and current. Updates are applied and verified. Custom work is documented. And when something breaks, there’s a specific person who already knows your site and is answerable for fixing it. Before you notice, ideally.
That’s the actual product of managed hosting, and it’s why we describe our work the way we do: we take custody of the pile. Not just the files: the decisions. The stale accounts get removed on day one. The plugins get evaluated against the ones we already trust. The updates get applied after we verify they won’t break anything. The decisions never turn into emergencies, because someone keeps them current.
A website that’s owned this way is boring in the best possible sense. Nothing dramatic happens, because the dramatic thing was prevented three steps earlier. That’s the whole point.
If you’re reading this because your developer went quiet, or because you’re staring at an admin list full of names you don’t recognize, we’d be happy to take a look. We do a decision inventory on inherited sites: who has access, what’s running, what’s abandoned, and what needs an owner. No pressure, no commitment. Just an honest accounting of the pile you’re holding, and a conversation about whether we’re the right ones to carry it.
Very often, yes. Admin accounts, hosting logins, FTP credentials, and API keys created during past projects usually remain active until someone deliberately removes them. If you’ve hired more than one developer over the years, assume old access exists until you’ve checked the admin list and hosting account yourself.
Generally, you own your content and your domain (if it’s registered in your name), while code ownership depends on your contract with whoever built it. The practical problem is usually control, not law: if the domain, hosting, or admin access is registered under a developer’s name or email, recovering control comes first.
Nothing, at first. The site keeps running on the decisions already made. But updates stop, security patches go unapplied, and small problems accumulate with no one watching. The risk isn’t a sudden crash; it’s a slow drift toward the day something fails and nobody’s there to catch it.
It can be, but the tool that built it takes no responsibility for maintaining it. An AI-built site still needs updates, security monitoring, and someone accountable for its decisions: the same ownership needs as any other site, held by an owner who usually has less visibility into what was built.