Dependent on One Developer? What Happens If They Disappear Tomorrow?

Dependent on One Developer? Your Business May Have a Bigger Risk Than You Think

Dependent on one developer is not just a staffing problem. It can become a serious business risk if that person is the only one who understands your software, knows how to deploy it, holds important passwords or has access to systems nobody else can reach.

I have seen businesses become increasingly reliant on one capable technical person without ever consciously deciding to do so. Everything works while that person is available. The problem only becomes obvious when they resign, become ill, take extended leave, stop responding or simply decide they no longer want to work on the system.

The good news is that you do not need to replace a trusted developer or build a large technology team to reduce the risk. You need to understand where the dependency sits, make sure the business controls its critical technology assets and create a practical path for somebody else to step in.

That is what key person technology risk is really about.

Takeaways

What Does Being Dependent on One Developer Actually Mean?

A business has single developer dependency when one person holds knowledge, access or technical capability that the organisation cannot easily replace.

It does not necessarily mean you literally employ only one developer.

You might have a development team of five people but still have one person who is the only developer who can safely deploy the application. One contractor might be the only person who understands an important integration. Your technical founder might be the only person who knows how the cloud infrastructure has been configured.

The dependency can exist in different places:

• Source code: Only one person knows where all the code lives or has full access.
• Infrastructure: One person controls AWS, Azure, Google Cloud or another hosting environment.
• Deployments: Only one person knows how to release a new version safely.
• Architecture: One person understands how the major parts of the software fit together.
• Credentials: Critical passwords, API keys or recovery accounts are controlled by one person.
• Integrations: Nobody else understands connections to payment platforms, CRMs, accounting systems or other services.
• Troubleshooting: Every serious incident eventually gets handed to the same person.
• Supplier relationships: One person is the only contact with hosting companies, development agencies or specialist vendors.
• Business knowledge: The developer understands important rules and workflows that have never been properly documented.

Technology teams sometimes call this the bus factor. It measures how few people could disappear before a project or system could no longer continue effectively.

The term is a little dramatic. I prefer to think of it as the lottery factor. What happens if your developer wins enough money tomorrow to decide that debugging your application is no longer their life ambition?

The question is the same.

Can the business continue without them?

What Happens If Your Software Developer Leaves Tomorrow?

The answer depends on how much knowledge and control sits with that person.

In a well-managed environment, losing a developer is inconvenient. Work slows down while somebody new learns the system, but the software keeps operating and the business knows what to do next.

In a high-risk environment, the situation looks very different.

A production problem occurs and nobody knows how to fix it.

A security vulnerability needs patching, but nobody can safely deploy the update.

The hosting provider sends an important warning, but the account belongs to the former developer.

A certificate expires.

An integration stops working.

A customer reports a serious defect.

Someone asks for the latest source code, and management discovers it has no administrative access to the repository.

Suddenly, the issue is no longer about replacing an employee or contractor. It is about maintaining the operation of the business.

That is why I treat developer dependency as a governance and continuity issue rather than simply a development team issue.

Key Person Technology Risk Is Not About Distrusting Your Developer

This distinction matters.

A developer can be loyal, capable and completely trustworthy while still representing a major key person dependency.

In fact, dependency often develops because somebody is very good at their job.

Problems get sent to the person most likely to solve them quickly. They become the person who understands the difficult parts of the system. Management trusts them, so they are given more responsibility and access.

Over time, the organisation starts relying on that individual without deliberately planning it.

The wrong response is to treat the developer as the problem.

The better question is:

Why has the business allowed so much knowledge, control or access to depend on one person?

People before technology matters here.

A good developer should not have to carry the stress of knowing that everything depends on them. Holidays should actually be holidays. Sick leave should not result in emergency phone calls. One person should not need to rescue every production problem.

Reducing key person risk protects the developer as well as the business.

The Seven Areas I Would Check First

If you suspect your business is dependent on one developer, I would start with seven areas.

1. Source Code Ownership and Access

Ask a simple question:

Can the business access the complete source code without asking the developer?

Your code should normally sit in a source control platform such as GitHub, GitLab or Bitbucket, using an organisation or business-controlled account.

Management does not need to understand the code.

It does need to know:

• where it is stored
• who owns the account
• who has administrative access
• whether all current code is actually there
• whether access can be transferred
• whether another developer could retrieve it

Source control is more than a backup folder. Systems such as Git record changes, versions and development history.

The NIST Secure Software Development Framework treats protection and controlled access to source code as an important part of software development practice. Source code should be managed as a business asset, not left sitting solely on someone’s laptop or inside an account the business does not control.

2. Hosting and Cloud Infrastructure

Next, find out who owns the environment running your application.

It might be hosted in AWS, Microsoft Azure or Google Cloud.

The business should know:

• which provider is being used
• whose name the account is in
• who controls billing
• who holds administrator access
• what services are running
• how the environment is configured
• what would happen if the current administrator disappeared

I regularly find that management knows roughly where its application is hosted but could not independently get into the account.

That should be fixed while everybody is still available and cooperative.

3. Domains, DNS and Email

Your domain name can be just as important as the software.

If somebody loses control of your domain or DNS configuration, your website, application and email can stop working even though the software itself is perfectly healthy.

Make sure the organisation controls the registrar account, recovery email address, multi-factor authentication and payment details.

The same principle applies to app stores, email platforms, SSL certificates and other services that customers rely on.

4. Passwords, Secrets and Administrator Accounts

Critical credentials should not exist only inside somebody’s memory, personal password manager or private email account.

This does not mean emailing the CEO a spreadsheet called passwords.xlsx. That merely swaps one problem for a more exciting one.

Use a secure password-management or secrets-management process. Critical accounts should have clearly controlled recovery mechanisms, appropriate multi-factor authentication and more than one authorised recovery path.

Current Australian Government cyber guidance recommends individual accounts where possible, controlled shared access, least privilege and prompt access changes when staff leave or change roles.

You need enough access redundancy to survive somebody leaving without creating unnecessary security exposure.

5. Deployment and Recovery

Ask:

Could another developer take the latest source code and deploy the application?

That question reveals a lot.

A development team may have excellent source code documentation but still rely on one person who knows the undocumented sequence required to get a release into production.

You should understand:

• how software moves from development to production
• what automated processes are involved
• what manual steps remain
• which credentials are needed
• how a failed deployment is reversed
• who else has performed the process

Where practical, deployment processes should be automated and repeatable.

If someone needs to remember seventeen undocumented steps and perform three mysterious rituals at midnight every time you release software, you do not have a deployment process. You have folklore.

6. Backups and Restoration

Having backups is good.

Knowing that they work is much better.

Australia’s cyber security guidance recommends backing up data, applications and settings according to business continuity requirements. It also recommends protecting those backups and testing restoration so the organisation knows recovery is actually possible.

For custom software, consider:

• application databases
• uploaded customer files
• configuration
• infrastructure settings
• source code
• important documentation
• encryption or recovery information

Then test restoration.

A green “backup successful” message is not proof that you could recover the business.

7. Documentation and Knowledge

Documentation matters, but I would not ask, “Do we have documentation?“

I would ask:

Could another competent developer use it?

Those are very different questions.

A folder containing 200 documents does not necessarily make the system maintainable.

Useful documentation might include:

• a simple architecture overview
• development setup instructions
• deployment instructions
• infrastructure information
• major integrations
• supplier details
• database information
• important technical decisions
• common support procedures
• backup and recovery processes
• known issues and technical debt

Keep it practical.

The goal is not to document every line of code. It is to give another competent person enough context to understand the system without needing its original developer sitting beside them.

How Do You Know Whether Another Developer Could Take Over?

There is only one reliable way to find out.

Test it.

This is where businesses sometimes mistake documentation for proof.

Imagine asking an independent developer to look at your system tomorrow. Could you provide them with:

1. access to the source code
2. instructions to run it
3. a description of the architecture
4. access to an appropriate development or test environment
5. deployment documentation
6. infrastructure information
7. a list of external services and integrations
8. relevant credentials through a controlled process
9. recent technical decisions
10. a person they can ask about business requirements

Could that developer make a small change, test it and safely deploy it?

If the answer is yes, your dependency is probably manageable.

If the answer is, “Only Dave knows how to do that“, Dave has accidentally become part of your disaster recovery plan.

That deserves attention.

A Simple Developer Dependency Test

You can perform an initial assessment without being technical.

Score each question Yes, Partly or No.

Question	Yes	Partly	No
Does the business control the source-code repository?
Does the business control hosting and cloud accounts?
Does more than one authorised person have appropriate access?
Are deployment instructions documented and tested?
Are important integrations documented?
Are backups running automatically?
Has restoration actually been tested?
Could another developer set up the application?
Are technical decisions recorded somewhere accessible?
Are domains, certificates and supplier accounts business-controlled?
Could someone other than the key developer respond to an incident?
Could the business replace the developer without losing control of the software?

One or two “No” answers do not automatically mean you have a crisis.

A pattern of them deserves investigation.

This is essentially what I look at in a Key Person Technology Risk Review. The purpose is to identify where the business depends heavily on individuals, understand the consequences and create practical recommendations to reduce that dependency.

Common Mistakes Businesses Make

Waiting Until the Developer Resigns

This is the worst time to discover the problem.

A four-week notice period disappears quickly when somebody is finishing work, handing over projects and preparing for their next role.

Do the continuity work while relationships are good and nobody is under pressure.

Assuming “It’s in the Cloud” Means It Is Safe

Cloud services are useful, but the cloud provider does not automatically manage your accounts, business permissions, application configuration or recovery process for you.

The Australian Signals Directorate describes cloud security as a shared responsibility. Customers still have responsibilities around access, authentication, credentials, backups and incident response.

The real question is not where your technology lives.

It is whether your organisation controls it.

Asking the Developer to Write Everything Down

Documentation is necessary, but handing somebody a blank page and saying “document the whole system” rarely works well.

Prioritise what another person would need to operate, support and change the application.

Start with the critical paths.

Creating Shared Administrator Passwords Everywhere

Reducing dependency does not mean everybody gets administrator access.

That creates another risk.

Use individual accounts, least privilege, multi-factor authentication and controlled emergency access. The aim is business continuity without sacrificing security.

Hiring a Second Developer and Assuming the Problem Is Solved

Two developers can still produce a bus factor of one.

If Developer A controls infrastructure and Developer B only works on the front end, losing Developer A may still stop production releases.

Measure capability and access, not headcount.

How to Reduce Dependency on One Developer

You do not need to fix everything at once.

I normally prioritise the work based on business impact.

Step 1: Identify What Could Stop the Business

Start with critical systems and processes.

What technology generates revenue?

What do customers use?

What would cause the biggest problem if it stopped tomorrow?

Focus there first.

Step 2: Map People to Critical Knowledge and Access

For each important system, identify:

• who understands it
• who can modify it
• who can deploy it
• who administers it
• who controls recovery
• who deals with suppliers

Anywhere you find only one name, investigate further.

Step 3: Put Business Ownership Around Critical Assets

Move important technology assets under appropriate company-controlled accounts.

That may include source code, cloud environments, domains, app stores, analytics systems, payment services and software licences.

Do this carefully. Do not casually share credentials or weaken existing security controls.

Step 4: Document the Critical Paths

Prioritise the knowledge somebody would need during an emergency.

You can improve less critical documentation later.

Step 5: Create a Genuine Second Pair of Hands

Somebody else needs enough knowledge to perform critical tasks.

Depending on the business, that might be:

• another internal developer
• an external development company
• a fractional technology leader
• an independent technical consultant
• a managed service provider for infrastructure
• a specialist support arrangement

The right option depends on your software and the level of risk.

For businesses without senior internal technology leadership, ongoing Fractional CTO services can also help put governance, ownership and continuity around the development function.

Step 6: Test the Handover

Do not wait for an actual departure.

Have somebody else:

• access the repository
• set up the project
• make a small change
• run the tests
• deploy into a safe environment
• restore something from backup
• follow an operational procedure

You will find gaps very quickly.

And that is precisely what you want.

Find them on a quiet Tuesday rather than during a customer outage on Friday night.

What If You Use an External Developer or Software Agency?

The same principles apply.

Outsourcing development does not outsource your responsibility for technology governance.

If your software matters to the operation or value of the business, you should understand:

• who owns the intellectual property
• where the source code resides
• whether you have independent access to it
• who owns the cloud accounts
• what happens when the contract ends
• what documentation must be provided
• how credentials are transferred
• what support arrangements exist
• whether another supplier could realistically take over

Current Australian Government guidance on technology service providers specifically recommends documenting access arrangements and applying appropriate controls to third-party access.

Your contract matters here too. Intellectual property ownership, licensing and termination provisions can have legal consequences, so obtain appropriate legal advice where necessary.

The technical question I care about is simpler:

Could you change suppliers without losing control of your technology?

If not, you have supplier dependency as well as developer dependency.

When Does Developer Dependency Become a Serious Business Risk?

Not every small business needs a large development team.

A startup with one developer may quite reasonably accept more key person risk than a mature company running a system used by thousands of customers.

Look at the consequences.

The risk deserves more attention when:

• software directly generates revenue
• customers depend on the application every day
• sensitive information is stored in the system
• the business would struggle to operate without it
• replacing the developer would take months
• nobody else can deploy or support production
• important knowledge is undocumented
• the developer controls accounts the business does not
• the company is preparing for investment or sale
• customers expect formal continuity arrangements
• regulatory obligations increase the consequences of failure

This is where Technology Leadership becomes more than managing developers. Leadership means understanding technical risk in business terms and making deliberate decisions about what should be fixed, accepted or monitored.

What Investors and Buyers May See

Developer dependency can also become visible during investment, acquisition or technology due diligence.

Imagine buying a company whose main asset is its software.

Then imagine discovering that:

• one contractor built nearly all of it
• there is poor documentation
• infrastructure sits in their personal account
• deployment is manual
• nobody has tested recovery
• replacing that person could take six months

That changes the risk profile of the deal.

A buyer is not only buying source code. They are buying the organisation’s ability to operate, maintain and improve that software after the transaction.

That is why Technology Due Diligence should look beyond code quality alone.

People, knowledge, ownership, operational processes and continuity matter too.

Frequently Asked Questions

What happens if my software developer suddenly leaves?

Your immediate risk depends on what only that developer can do. Check source-code access, production systems, hosting, credentials, deployments, backups, integrations and documentation first. If nobody else can perform critical tasks, treat the situation as a business continuity issue.

Is being dependent on one developer always bad?

No. Small businesses and startups often begin with one developer because building a larger team would make no commercial sense. The issue is not having one developer. The issue is having no realistic continuity plan if that person becomes unavailable.

What is key person risk in software development?

Key person risk exists when important technical knowledge, access, authority or capability depends heavily on one person. If their departure would seriously disrupt development, support or business operations, the dependency deserves attention.

What is the bus factor?

The bus factor is an informal measure of how many people could become unavailable before a project could no longer continue effectively. A bus factor of one means the project relies critically on one person.

How can I tell whether another developer could take over my software?

Give another competent developer controlled access to the code and documentation and see whether they can understand the architecture, set up the application, make a small change and follow the deployment process. A practical handover test tells you far more than asking whether documentation exists.

Reduce the Risk Before It Becomes an Emergency

You do not need to assume your developer is about to disappear. You simply need to make sure the business would still be able to function if they did.

A Key Person Technology Risk Review can identify where critical knowledge, access and responsibility currently sit, then prioritise practical steps to reduce the exposure without creating unnecessary process or bureaucracy.

Strong technology businesses value capable people without making the organisation completely dependent on them. If your business is dependent on one developer, now is a much better time to understand the risk than the morning they are no longer available.