Nobody Else Has the Password: The Quiet Risk of Running a One-Developer Website

Somewhere in America right now, a small business owner is refreshing their inbox, waiting on a reply from the one person on earth who knows how their website actually works.

Maybe it's a freelancer who's gone quiet. Maybe it's a technically gifted cofounder who just quit. Maybe it's an agency that's been slow to respond ever since the last invoice cleared. Whatever the scenario, the feeling is the same: you own the domain, you pay the hosting bill, and yet somehow you have almost no control over the thing your revenue depends on.

People in software call this the "bus factor" — the number of people who'd need to get hit by a bus before your project grinds to a halt. For most small online businesses, that number is one. And unlike big companies, you can't absorb that hit.

The Problem Isn't the Developer Leaving. It's What They Take With Them.

Let's be fair to the freelancer or the cofounder for a second. Most of them aren't hoarding access to be difficult. They're busy, documentation is boring, and "I'll write it down later" wins every single week. The knowledge just ends up living in their head, their personal password manager, and a Slack DM from eight months ago.

Then they leave — burnout, a better gig, a move to Austin, a family emergency — and you discover the hard way that:

• Your hosting account is under their email address
• The domain registrar login is a personal Gmail you've never seen
• Your code lives in a private repo you can't access
• Nobody knows which plugin update broke the checkout page last spring

You're not locked out maliciously. You're just locked out. And in the meantime, your store keeps selling products with a broken shipping calculator, or your lead form quietly dies, and every day of silence costs you real money.

Five Free Things You Can Do Today

None of this requires a lawyer, an enterprise tool, or a budget line. It requires an afternoon and a shared document.

1. Build a plain-language "how this site works" doc. One Google Doc, shared with at least two people at your company. What platform is the site on? Who hosts it? Where's the domain registered? What's the monthly stack of plugins or services? You don't need technical depth — you need a map. If your developer quit tomorrow, this doc is the difference between a bad week and a bad quarter.

2. Get credentials out of personal accounts. Every critical account — hosting, domain registrar, DNS, analytics, payment processor — should be owned by a company email, not a Gmail that follows your developer home. If that's not feasible, at minimum make sure you're listed as the account owner and billing contact, and that recovery emails point back to you. Domain registrars let you verify ownership in about five minutes. Do it.

3. Use a password manager with shared vaults. Tools like Bitwarden or 1Password have team plans that cost less than lunch. A shared vault means credentials can be transferred, rotated, or revoked when someone leaves. A text file called "logins_FINAL_v3" on someone's desktop does not count.

4. Insist on a staging environment. A staging site is a private copy of your website where changes get tested before they touch the live version. Any competent developer can set one up in under an hour, and it's usually included in decent hosting plans for free. Without one, every change is a live experiment — and when your only developer is gone, nobody's around to undo the experiment.

5. Schedule a quarterly walkthrough. Thirty minutes on a video call. Ask your developer to screen-share the admin dashboard, walk through where things live, and update the doc. Frame it as a routine check-in, not a trust exercise. Good developers actually like this — it means fewer 2 AM emergency calls when something breaks and nobody knows where to look.

A Simple Handoff Checklist

Print this. Seriously. It's the minimum viable insurance policy:

• Domain registrar: account owner, login, and auto-renew status documented
• Hosting: provider, plan, billing owner, and admin access
• DNS settings: where they're managed and what records exist
• Code: repository location and at least one backup admin with access
• Database and file backups: automated, tested, stored somewhere you control
• Plugin/service list: what's installed, what it costs, what it does
• Key contacts: developer, host support, registrar support

If you can't check most of these boxes, you're one resignation letter away from finding out how fragile your business really is.

The AI Wrinkle

Here's the part that changes the math in 2025: a lot of what used to require your developer is now handleable by AI tools and automation. An AI assistant can read your documentation and help a non-technical person diagnose a broken plugin, draft the DNS change, or explain what an error log means. Modern site platforms can even auto-generate much of that documentation from your setup.

That doesn't replace a good developer — it de-risks them. When the knowledge is written down and the tools can help you act on it, losing your one technical person stops being an extinction event and becomes a hiring problem. A solvable one.

Own the Boring Parts

The businesses that survive developer departures aren't the ones with the fanciest code. They're the ones where the owner treated documentation, access, and backups as part of the business — not as an IT detail to delegate and forget.

Your website is an asset. Start acting like it. Spend one afternoon this week getting your keys back, and future-you — awake at 2 AM with a broken checkout page and a missing developer — will be very, very glad you did.