Let me describe a Tuesday morning I've now seen play out at four different firms in the last eighteen months. The details change, the shape doesn't.
A developer - let's call him Matt - hands in his notice. He's been with the firm for five years. He built the website, set up the CRM integration, configured the hosting, manages the DNS, and maintains a handful of custom plugins that make the whole thing hang together. He's good at his job. He's also the only person who does it.
Matt's got a better offer. Or he's burned out. Or he's relocating. Doesn't really matter. What matters is that by the end of the month, he's gone.
Within the first week, someone in marketing tries to update the homepage banner and gets a deployment error they've never seen before. Someone in IT realises they don't know the login for the hosting account. A partner asks for a change to the client portal and discovers that the last three people who would have known how to do that are Matt, Matt, and Matt.
The website still loads. Clients can still find you on Google. But the thing is now frozen - a digital presence that can receive visitors but can't be changed, fixed, or protected without knowledge that just walked out the front door.
Our developer's been with us for six years. They're not going anywhere.
I hear this a lot. And I never quite know what to say, because it's usually delivered with the same confidence as "we've never had a flood" - which is true, until it isn't, and then you discover you didn't buy the insurance.
Developer turnover isn't a rare event - that's what makes this a planning-horizon risk rather than a remote contingency. The Stack Overflow 2023 Developer Survey found around 40% of developers are actively looking for or open to a new role at any given time. Median tenure for software developers sits at roughly two to three years across most industries, and in smaller firms - where the work can become repetitive and the growth path limited - it's often shorter.
Now layer on the specific conditions of a mid-market professional services firm. You've probably got one developer. Maybe two, but one of them carries 80% of the knowledge. They're not in a team of twenty where institutional knowledge is distributed across squads and codebases and wikis. They're a single person, often working semi-autonomously, sometimes reporting to someone who doesn't fully understand what they do. That's not a criticism - it's just how these things tend to evolve in firms where technology isn't the core business.
So the question isn't really whether your developer might leave. The question is whether you've ever seriously thought about what happens when they do.
None of this is about bad management or negligent developers. It tends to happen naturally, in three ways, at firms that aren't technology businesses.
Custom platforms and bespoke builds. Your website probably wasn't built from a template. At some point, someone - maybe Matt, maybe an agency before Matt - built something to a specific brief. That build involved hundreds of small decisions: how the content types are structured, how the CRM integration passes data, what happens when a form submission fails, why that one plugin was forked and modified instead of used out of the box. Every one of those decisions made sense at the time. Very few of them were written down. This isn't negligence - it's the natural consequence of pragmatic delivery under time pressure. When you're trying to get a site live by March and the budget is already stretched, documentation is the thing that gets cut first. Always.
I was in a meeting about eighteen months ago with a firm whose developer had left three months earlier. They'd hired an agency to pick up the work. The agency spent the first four weeks just trying to understand what the previous developer had built - reverse-engineering the integration logic, tracing API connections, figuring out why certain pages rendered differently on mobile. Four weeks of billable time before a single improvement was made. The COO looked at me across the table and said, "We're paying twice for work we've already paid for." He wasn't wrong.
Single-vendor and single-developer relationships. If your entire digital estate is maintained by one person internally and one agency externally, you haven't diversified your technical knowledge risk - you've concentrated it at two points. And if those two points are the same person - if your developer is your agency relationship - then you've got a single point of failure that would make any risk committee wince if they knew about it. The trouble is, they usually don't know about it, because it's never framed as a risk. It's framed as "Matt handles the website."
Documentation as the first casualty. I'll be honest - I've been guilty of this myself in earlier stages of running Distinction. When delivery demand is high and the team is stretched, documentation feels like a luxury. The platform that "everyone knows how to use" typically means one person knows how to use it, and everyone else can manage the surface layer - updating a blog post, swapping out an image. The moment you need to do anything structural, you're back to the one person who built it. And if that person isn't available, you're stuck.
"The website still works" can mask a lot of quietly accumulating damage. Let me be specific about what actually breaks.
Security patches can't be applied. This is the one that should worry you most. When a vulnerability is disclosed for your CMS version or a plugin you're running, someone needs to assess it, test the patch in a staging environment, and deploy it. If nobody knows how the deployment process works - or worse, nobody has access to the environments where deployment happens - that patch doesn't get applied. Your platform isn't insecure because it's old. It's insecure because the one person who could have kept it secure isn't there anymore.
Integrations break quietly. That CRM integration Matt built - the one that pipes form submissions into Salesforce and triggers the right workflow? When Salesforce updates their API, someone needs to update your end of the connection. If nobody knows how the integration was built, that update doesn't happen. And one day, the form submissions stop arriving in the CRM, and nobody notices for a fortnight because the failure is silent. I've seen this exact scenario at a 200-person consulting firm. They lost three weeks of web enquiries before anyone realised.
The website fossilises. Content updates - fine. A new blog post, a team member photo, maybe a new service page if the CMS is straightforward enough. But anything that touches the underlying code or configuration? Deploying changes to a production environment without understanding the deployment pipeline is like performing surgery with someone else's notes, except there are no notes. Most people sensibly decide not to touch it. No new features, no structural changes, no response to evolving business needs. The site just... sits there.
And sometimes - this is the one that really keeps me up at night when I hear about it - access itself is lost. The hosting account was registered under the developer's personal email. The domain registrar login is in their password manager. The API keys for three different third-party services are stored... somewhere. I spoke to a managing partner last year who spent eleven days trying to regain access to their own hosting environment after their developer left. Eleven days during which they couldn't deploy a single change to their website, including a time-sensitive compliance update. They eventually had to go through the hosting provider's legal escalation process with proof of company ownership.
Eleven days. For their own website.
(Onboarding a replacement developer is a whole separate problem - a competent person walking into an undocumented codebase needs weeks, not days, just to understand what they're looking at. We've inherited platforms at Distinction where it took our team two to three weeks of dedicated investigation before we could confidently make changes without risk of breaking something. That's not because our team is slow. It's because the previous developer's knowledge wasn't captured anywhere.)
Right, so here's the practical bit. I want you to do something after reading this - not next quarter, not when it's convenient, but this week.
Pick the most critical system in your digital estate. Probably your website, possibly your client portal or CRM integration. Then ask yourself four questions.
If the person who manages this system was genuinely unavailable tomorrow - not "on holiday but checking emails," actually gone - how long would it take to restore normal operation? Not keep it running. The ability to make changes, apply updates, fix things that break. If the answer is more than a week, you've got key-person dependency. That's not a maybe.
Is there written documentation - accessible to someone other than the primary manager - for the deployment process, the integration architecture, and the access credentials? Not "I think Matt wrote something in Notion once." Actual, current, findable documentation that a competent developer unfamiliar with your setup could follow. If you're not sure, the answer is no.
Is more than one person - inside the firm or in an external partner relationship - able to perform critical maintenance tasks on this system? Able, as in, has done it before. There's a massive difference between theoretical capability and tested capability.
When was the last time a second person actually used that documentation or performed those tasks? This is the one people skip. You might have documentation. You might even have a second person who theoretically knows the system. But if neither has been tested under real conditions, you don't actually know whether your safety net works. Documentation that's never been tested is decoration.
These four questions will tell you 80% of what you need to know in about five minutes. And I suspect most people reading this won't love the answers.
The temptation in an article like this is to say "and therefore you need to replatform immediately." You don't. Or at least, not necessarily. What you need is to reduce the dependency, and there are a few ways to do that at different levels of investment.
Make documentation a standing delivery requirement. This is the single cheapest intervention and the one with the highest return. From today, any development work - any integration, any configuration change, any deployment - should produce a written record that a competent developer unfamiliar with the system could use. Not a novel. A concise document covering what was built, how it connects, how to deploy it, and where the credentials live. Build this into your project governance. If your developer or agency pushes back on it, that tells you something important about how they work.
At Distinction, we build documentation into every engagement as a non-negotiable. Not because we enjoy writing it - frankly, nobody does - but because we've seen too many firms get burned when the person who "knew everything" moved on. A client shouldn't be dependent on us any more than they should be dependent on an internal developer.
Centralise access management. Hosting accounts, domain registrar credentials, third-party API keys, deployment tool logins - all of these should be accessible to at least two people and managed through a shared credential system. Not a sticky note on someone's monitor. A proper shared vault - 1Password for Teams, Bitwarden, whatever your preference - where the firm owns the credentials, not the individual. This costs almost nothing to implement and eliminates the "eleven days to regain access" scenario entirely.
Think about whether your platform choice is making the dependency worse. A heavily customised, bespoke build on an obscure framework is inherently harder to hand over than a well-implemented site on a widely adopted CMS with standard architecture. Bespoke builds aren't bad - sometimes they're exactly the right technical choice. But if yours is also undocumented and maintained by a single person, you've compounded the risk. Modern managed CMS platforms - Umbraco, Payload, Kentico, even well-structured WordPress - are significantly easier for a new developer or agency to pick up. The migration cost is real, but weigh it against the key-person dependency risk you're currently carrying unquantified.
But we'd have to migrate everything. That's a massive project.
Maybe. Or maybe it's a two-sprint engagement that costs a fraction of what an emergency recovery would. I've seen firms spend more recovering from a departed developer than they would have spent migrating to a sensible platform two years earlier. The maths tends to be fairly brutal once you add it up.
Build a partner relationship before you need one. A retained relationship with a digital consultancy or agency - even a lightweight one - means there's a capable team that already has some familiarity with your estate and can respond quickly if your internal resource disappears. The cost of a small monthly retainer is trivial compared to an emergency engagement where a new team has to start from zero, under pressure, with no documentation. It's the insurance policy. Buy it before the flood.
Every professional services firm I've ever worked with has a risk register. They have business continuity plans, insurance policies, disaster recovery procedures. They think carefully about what happens if a senior partner leaves, if a key client relationship is disrupted, if a regulatory change hits.
Almost none of them have ever formally assessed the risk of losing the person who keeps their digital infrastructure running. It doesn't appear on the risk register. It's not discussed at board level. And yet the probability of it happening - based on developer turnover data alone - is higher than most of the risks that are formally managed.
The average developer tenure is two to three years. Your risk register probably includes scenarios with lower probability and lower impact that get more attention and more mitigation budget. That's a bit nuts, right?
I'm not trying to make you paranoid about your developer. If you've got a good one, value them. Pay them well. Give them interesting work. But also - quietly, pragmatically - make sure that if they handed in their notice tomorrow, you'd know what to do by Friday. The firms that handle this well aren't the ones that never lose a developer. They're the ones that made sure the knowledge didn't leave with the person.
That's not distrust. That's governance.
If you want to understand where your firm's digital infrastructure carries key-person dependency risk - and what a realistic mitigation plan looks like - book a platform dependency review. It's the kind of conversation that takes an hour and saves you from a very expensive surprise.