Website Documentation: How to Protect Your Business When Your Developer Leaves

Most businesses find out they have a documentation problem at the worst possible time, when their developer is already gone. Here's what to document, where to store it, and how to build the habit before it becomes a crisis.

Here's a pattern I keep seeing. A business loses their developer, either they quit, go silent, or the contract ends without a proper handover. The website is still running, so nothing feels urgent at first. Then something breaks. Or they need to add a feature. Or their hosting comes up for renewal and nobody knows which email the account is registered under.

Suddenly, a missing developer turns into a missing website.

The fix isn't just finding a new developer. The fix is website documentation, and the best time to start it is long before you ever need it. This post covers what documentation actually means for a non-technical business owner, what you need to document, where to keep it, and how to make it a habit before it becomes a crisis.

⚠️ Warning: If your entire website knowledge lives inside one developer's head, or in their personal accounts, you're one phone call away from a real problem. That's not an exaggeration.

What "Website Documentation" Actually Means

Documentation has a reputation for being dry and technical. Most people picture developers writing comments in code. That's part of it, but it's not the part that protects your business.

For a business owner, website documentation is really an answer to one question: if your developer disappeared tomorrow, could you still manage your website?

Could you renew your hosting? Log into your domain registrar? Contact support for your email service? Know what custom code exists and what it does? Find out if your site is running any security software?

If you hesitated on any of those, you're underdocumented.

Think of it as a manual for your own property. Your website is a business asset. You'd never buy a building and then let only one person hold all the keys, know where the fuse box is, and have the landlord's number. But that's exactly what most businesses do with their websites.

Why Documentation Gets Skipped Every Time

The honest answer is that nobody asks for it and nobody makes time for it.

Developers are focused on building. Clients are focused on getting the site live. Once a project ends, both parties move on. Documentation feels like extra work after already-done work, so it doesn't happen.

Then the relationship continues informally. The developer answers questions when asked. The client doesn't need to know the details because they can just "ask." That works fine until it doesn't.

I've worked with clients before that came to me after their previous developer stopped responding. Not because of bad intentions (people get sick, change careers, move countries), but because there was no documentation. What should have been a manageable transition became a several-week audit just to understand what was on their own server.

💡 Pro Tip: The best time to document a website is during and right after the build, when everything is fresh. The second-best time is right now. The worst time is when you actually need it.

The Documentation That Every Business Site Actually Needs

Let's get specific. Here's what to document, broken into three areas.

1. Access and Credentials

This is the most immediately practical category. If everything else is lost, this one list tells you what you own and how to access it.

Domain registrar account (where your domain is registered and who controls it)
Hosting provider account (where the files and database live)
Server access credentials (FTP, SSH, or control panel login)
Database credentials (even if you never touch it yourself, store it somewhere safe)
Email service or email hosting account
SSL certificate provider (if managed separately from hosting)
Content Delivery Network (CDN) if one is in use
Any third-party services connected to the site (payment processors, booking systems, form tools, analytics)
Admin login for the CMS or application itself (WordPress, a custom admin panel, etc.)

This list should live in a password manager (more on that below), not in a spreadsheet or an old email thread.

2. Site Structure and Custom Work

This section helps anyone coming in after your developer understand what was built and why.

What the site runs on (WordPress, Laravel, a custom framework, etc.) and which version
A list of installed plugins or packages, why each one was added, and whether it's still actively needed
A plain-language description of any custom features (a booking system, a subscription paywall, a price calculator, etc.)
Who built each major custom feature and roughly when
Any known quirks or things that require care ("don't update the search plugin without testing first")
Where the code lives (GitHub, GitLab, a private repo, or just on the server)

📝 Note: You don't need technical detail here. Something like "we have a custom member-only area that controls access to the video library. It was built by [developer name] in 2022 and connects to Stripe. The code is in /wp-content/plugins/member-portal." is enough. That's it.

3. Maintenance and Operations

This section is a simple runbook for keeping the site healthy day to day.

How often backups run and where they're stored
How to restore from a backup (or who to call)
Who to contact at the hosting provider if there's an outage
What a normal maintenance week looks like (scheduled updates, monitoring checks, etc.)
What the emergency process is if the site goes down
Scheduled renewals for hosting, domain, SSL, and any annual subscriptions (and what email they're tied to)

That last point is more important than it sounds. I've seen businesses lose domain control because renewal notices were going to a former employee's email and nobody caught it until the domain expired.

Where to Store Documentation (Your Developer's Hard Drive Doesn't Count)

This is where a lot of businesses get it wrong even when they do document things. The documentation exists, but it's in the developer's Notion workspace, saved as a text file on their computer, or buried in an old email thread.

That's not documentation for you. That's documentation for them.

Your documentation has to be:

Under your control. Not in your developer's accounts. In accounts you own and can access independently.
Accessible without your developer. If they disappeared today, could you find it and use it?
Updated when things change. Stale documentation is almost as bad as no documentation.

Here's a comparison of practical storage options:

Option	Best For	Notes
Password manager (1Password, Bitwarden)	Credentials and account access	Excellent for logins, not great for narrative descriptions
Notion or Google Docs	Site documentation and runbooks	Easy to update, shareable with future developers
Private GitHub/GitLab repo	Technical teams, code-level docs	Good if someone on your team is technical
A single shared Google Doc	Small sites, simple setups	Works fine if it's actually maintained

My recommendation for most small businesses is a combination: a password manager for all credentials (shared with whoever needs operational access to the business), and a Google Doc or Notion page for the narrative documentation.

Whatever you choose, it lives in your accounts. Not your developer's.

How to Build Documentation Into Your Developer Relationship

The mistake most businesses make is treating documentation as a one-time deliverable. "Get the docs at the end of the project, done."

That doesn't work. Websites change. Plugins get added. Custom features get built. Without regular updates, your documentation becomes outdated within a year.

Here's a better approach.

Make it a requirement from the start. When you're hiring a developer, include documentation expectations in your contract or scope of work. "You'll provide a handover document at project completion" is a reasonable ask. Most professionals will agree to it.

Update it with every significant change. Any time a new plugin is added, a custom feature is built, or a third-party service is connected, that's a documentation update. It takes ten minutes. Put it in the contract as a standard task.

Run a quarterly access check. Once every three months, verify you can log into your hosting, your domain registrar, and your CMS. This takes about five minutes and catches problems before they become crises.

Store it yourself, share access with your developer. Your developer doesn't need to own the docs. They contribute to them, but you own them. This is a meaningful distinction.

✅ Key Takeaway: Documentation isn't a deliverable your developer owns. It's a business asset you own that your developer helps maintain. That's a different relationship, and it's worth establishing early.

What to Do If You Have No Documentation Right Now

Most businesses that come to me for help have either no documentation or documentation they can't actually access. It's fixable, and you start with access recovery.

Step 1: Confirm you can access your own infrastructure.
Before anything else, verify you can log into your domain registrar, your hosting account, and your CMS admin panel. Write down every credential that works. Put it in a password manager today.

Step 2: Identify what you're missing.
If there are accounts you can't access (hosting controlled by your developer, a domain in their name, a server you've never logged into), make a list. These are your highest-priority recovery items.

Step 3: Contact your current developer.
Ask them to transfer relevant accounts to you and share any documentation they have. Most developers will cooperate with a reasonable, professional request. If they're no longer available, this becomes a technical audit.

Step 4: Document as you recover.
As you regain access to things, document them immediately. Don't wait until you have everything to start writing it down.

The goal isn't a perfect document. A rough Notion page with the right information is worth more than a polished document that doesn't exist.

Documentation Is an Exit Strategy

Here's the thing about documentation: preparing it isn't pessimistic. You're not planning for your developer to leave. You're just acknowledging that at some point, every developer relationship ends.

A business with good documentation can bring on a new developer quickly, hand off to an internal team, or make small changes without technical help. A business without documentation spends weeks recovering things that should have been easy.

Think of it as business continuity insurance. You hope you never need it in a crisis, but when that crisis comes, you'll be glad it exists.

If you're not sure where to start or your documentation situation is messier than this post covers, feel free to reach out. I do website audits that include a full access and documentation review.

Action Items

Immediate (this week):

Check whether you can log into your domain registrar, hosting provider, and CMS
Set up a password manager if you don't have one (Bitwarden is free)
Add every credential you currently have access to

Short-term (this month):

Ask your developer for a current handover document
Document the three main areas covered in this post (access, site structure, maintenance)
Store documentation somewhere you own, not in your developer's accounts

Long-term (ongoing):

Add documentation update requirements to your developer contract or retainer
Run a quarterly access check
Review and update documentation whenever a significant change is made to the site

Frequently Asked Questions

How detailed does my documentation need to be?

Detailed enough that someone new could understand what they're inheriting and log into everything they need. It doesn't need to be a technical manual. Plain language works. If you can describe what each part of your website does and how to access it, that's the core of it.

My developer handles all of this. Do I still need to document it?

Yes. The scenario where your developer handles everything is precisely the situation documentation protects you from. When they're available, everything is fine. The documentation exists for when they're not.

What if my developer refuses to provide documentation?

That's a red flag. Professional developers should be willing to document their work and give you control over your own accounts. If a developer resists this, it's worth asking why, and worth considering whether that's the right long-term partner for your business.

Can I just ask my developer to manage all of this?

You can ask them to contribute to it, yes. But the ownership and maintenance of documentation should sit with you or someone on your team. The habit of reviewing and storing it needs to be yours, not theirs.

How often should I update my documentation?

Any time something meaningful changes: a new plugin, a new feature, a new third-party service, or a change in who has access to what. Quarterly reviews help catch anything that got missed in the day-to-day.

If you're stuck and need help, don't hesitate to reach out. I'll do my best to help.