Key Person Risk When You Hire a Small Software Agency: What to Check Before You Sign

Key person risk when hiring a small software agency is the fear that your product will quietly come to depend on one developer, and that the day that person leaves, gets sick or stops answering, nobody can change your software. It is a fair fear. It is also one you can check before you sign, and mostly fix in the contract. This guide explains how big the risk really is, why firm size is the wrong thing to measure, what the contract has to say, and seven checks to run on any agency. It is written by Paul Byrne, President of Razoyo, a small software engineering firm, so “what if the people who built it leave?” is one of the questions we get before the call, and one we have to answer for ourselves.

What is key person risk in a software project?

Key person risk is the chance that one person’s absence stops your software from being changed, deployed or understood. In software teams it has a well-known nickname, the “truck factor”: the smallest number of people who would have to be hit by a truck, or quit, before a project is in trouble.

Three things usually sit in one head when the truck factor is one:

• The knowledge. Why the code is shaped the way it is, which parts are fragile, what the workarounds are for.
• The access. The hosting account, the domain, the app store listing, the payment provider, the passwords.
• The process. How a change gets from a laptop to production, and what has to be done by hand along the way.

Lose the knowledge and changes get slow and risky. Lose the access and changes can become impossible. Lose the process and every release turns into an experiment.

How common is it?

More common than buyers assume, even in well-run software. Researchers who estimated the truck factor of 133 popular open-source projects on GitHub found that “the majority of our target systems (65%) have TF <= 2” (Avelino et al., ICPC 2016). In other words, two people leaving would put most of those projects in trouble, and these were popular projects with many contributors.

Private client projects are usually smaller than that, so the honest starting assumption is that your product will be understood in depth by one or two people, whoever you hire. The question is not whether knowledge concentrates. It always does. The question is whether the things around the knowledge, the access, the code, the documentation and the process, are set up so another competent team could take over.

Is a small agency riskier than a large one?

Not automatically. A large firm has a bench of people, but the number who actually know your system is still small, and in a large firm they are often not the people you met. Our large consultancy or small senior firm comparison puts the pattern plainly: “In a large firm, the seniors sell and the juniors build.” Rotation through a big staffing pool can lose knowledge faster than one person leaving a small team.

A small firm has the opposite shape. The people who scoped your product usually build it, which is good for continuity, but there are fewer people to cover for each other. Neither size protects you on its own. What protects you is a short list of facts you can check, whatever the size.

The last row is the point of this guide. It is the same in every column. Our freelancer or engineering firm comparison covers the other differences.

What should the contract say about ownership?

That the code, the documents and the accounts are yours, in writing, and when that happens. Under US copyright law, copyright “vests initially in the author or authors of the work” (17 U.S.C. 201). Code written for you by an outside firm is not automatically yours just because you paid for it, and a transfer of copyright ownership “is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed” (17 U.S.C. 204). Have your own lawyer read the clause. What you are looking for is simple to state:

• What you own. The code written for you, the documents, the repository and the infrastructure accounts.
• When you own it. On payment of fees, not “on final delivery” of a project that might never finish.
• What the firm keeps. A short, named list of its own pre-existing tools and libraries, licensed to you for use inside your product.
• What happens if you leave. A notice period and a handover list.

Ours is published on our you own the code page: once fees are paid, you own the code we write for you, plus the documents, the repository with its full history, and the infrastructure the product runs on. What we keep is our own pre-existing libraries, tooling and know-how, licensed to you as part of your product. Retainers end on 30 days’ notice. If a firm will not put its version in writing, that tells you something.

Who should hold the keys?

You should, and never through one person. GitHub’s own documentation warns that “if an organization only has one owner, the organization’s projects can become inaccessible if the owner is unreachable,” and recommends “that at least two people within each organization have the owner role” (GitHub Docs). The same logic applies to every account your product depends on.

• The repository lives in an account your company owns, with at least two of your people able to administer it. The agency gets access; it does not own the house.
• Hosting, domain and third-party accounts are registered to your company, not to a developer’s personal email.
• Credentials are stored somewhere you control, and rotated when anyone with access leaves, on either side.

When a client leaves us, the handover on our ownership page includes hosting, cloud and third-party accounts “with credentials rotated so we no longer hold the keys.” Ask any firm whether it will do the same, and when.

How do you tell if knowledge is stuck in one head?

Ask to see the evidence, not the promise. Every firm says it documents its work. These four things show whether it does:

1. Code review by a second person. If every change is reviewed by someone other than the author before it merges, at least two people have read every line. At Razoyo, as our process page says, every pull request is reviewed by a lead developer before it merges.
2. A board you can see. Planned work, finished work and priorities in a project system you have access to, not in someone’s inbox. Our clients get access to the same board our team works from: epics, issues and priorities.
3. A deploy anyone can run. A written, repeatable path from a change to production. If only one person can release, the truck factor is one regardless of how many people can read the code.
4. A readme a stranger could follow. How the system is built, how to run it locally, how to run the tests.

Our ownership page states the test we hold ourselves to: could another competent team pick this up on Monday? It is a useful question to put to any firm, word for word.

Razoyo’s Monday Handover Test

Run these seven checks on any agency before you sign, us included. They are built from the handover we publish on our ownership page: code and repository, access, documentation, the board and a working deploy path. Each has a pass and a fail.

1. Whose account is the repository in? Pass: yours, with at least two of your people as owners. Fail: the agency’s account, with a promise to transfer it later.
2. When does ownership pass? Pass: in writing, on payment of fees. Fail: on final delivery, or not stated.
3. Does anyone review each change besides its author? Pass: every change, before it merges. Fail: “our developers are senior, they don’t need review.”
4. Can you see the work? Pass: you have access to the project board. Fail: you get a status email.
5. Can someone else deploy? Pass: the deploy path is written down and routine. Fail: one person does it by hand.
6. Who holds the credentials? Pass: your company, with rotation when people leave. Fail: a developer’s personal accounts.
7. How fast can you leave, and with what? Pass: a notice period of weeks and a named handover list. Fail: no exit terms, or a long minimum term.

How does Razoyo handle this, as a small firm?

Honestly, the same way we tell you to check any firm: by making sure context does not live in one head, and that you could leave without starting over. We are a small senior team, and we will not pretend that removes the risk. Here is what we publish:

• Every change is reviewed by a lead developer before it merges, so no piece of your code has been read by only one person.
• You get access to our project board, the same epics, issues and priorities our team works from.
• Once fees are paid you own the code we write for you, plus the documents, the repository and the infrastructure.
• On rescue work, named engineers, not a rotating pool. Our codebase rescue page says documented ownership is one of the seven checks every rescue has to pass before it is called done.
• Retainers run month to month, with thirty days’ notice to stop, according to our pricing page.

And the team stays. Our about page puts it this way: “In an industry known for high turnover, Razoyo’s team is remarkably consistent,” and many of our clients have been with us for more than a decade. We are still the engineering team behind Spider, the hotel business intelligence platform now part of Lighthouse.

One more protection sits before any build. Our System Spec is $2,500 fixed, and the product brief and PRD it produces are yours whether or not you build with us. The Women’s POWER Pickleball League paid $5,000 for a larger fixed-price Spec, took it to a partner who could fund the build, and the document worked without us. A specification someone else can build from is the cheapest key person insurance there is.

What if your developer has already left?

Then the risk has already happened, and the job is recovery, not prevention. Get control of the accounts first: the repository, hosting, domain and anything that takes payments. Then have someone read the code before anyone rewrites it. Most inherited systems are worth keeping in part, and rewrite or refactor an inherited codebase explains how to decide. If you need a team to take over, the firms that take over existing codebases are compared in one place, us included.

And when you hire the next team, run the Monday Handover Test first. Most of the pain of a departed developer is a failed check from the list above that nobody ran at the start.

Key takeaways

• Knowledge always concentrates. Most projects depend deeply on one or two people, whoever you hire. Plan for it rather than hoping against it.
• Firm size is the wrong thing to measure. Ownership, access and documentation protect you at any size.
• Get ownership in writing, on payment of fees. Under US law, a transfer of copyright ownership needs a signed writing.
• Hold the keys yourself. Repository and accounts in your company’s name, with at least two owners, and credentials rotated when people leave.
• Ask for evidence. Second-person code review, a board you can see and a deploy anyone can run.

Key terms glossary

• Key person risk. The chance that one person’s absence stops a business, or a product, from operating normally.
• Truck factor. The smallest number of people whose loss would leave a software project unable to continue.
• Work made for hire. A work whose copyright belongs from the start to the employer or commissioning party, rather than to the person who created it.
• Repository. The store of a product’s code and its full change history.
• Code review. A second developer reading and approving a change before it becomes part of the product.
• Handover. The transfer of code, access, documentation and work history from one team to another.

FAQ

What is key person risk when hiring a software agency? It is the chance that your product comes to depend on one developer, so that if that person leaves, gets sick or stops responding, nobody can safely change, deploy or understand your software. It applies to freelancers, small agencies and large firms alike.

Is it riskier to hire a small software agency than a large one? Not automatically. A large firm has more people, but only a few will know your system, and they may rotate off. A small firm has fewer people to cover, but the people who scope the work often build it. Ownership, access and documentation protect you at any size.

How do I reduce key person risk with a software vendor? Keep the repository and every account in your company’s name with at least two owners, get ownership of the code in writing on payment of fees, require a second person to review every change, ask for access to the project board, and make sure the deploy path is written down.

Do I automatically own the code an agency writes for me? Not necessarily. Under US copyright law, copyright starts with the author, and a transfer of ownership is valid only in a signed writing. Make sure the contract says what you own and when, and have your own lawyer read the clause.

What should a software development contract say about leaving? It should name a notice period and a handover list: the code and repository with full history, access to every account with credentials rotated, documentation on how the system is built and deployed, and the project board. Razoyo’s retainers end on 30 days’ notice.

What should I do if our only developer has left? Take control of the repository, hosting, domain and payment accounts first. Then have an experienced team read the code before anyone rewrites it, because most inherited systems are worth keeping in part. Run a handover checklist with the next team before they start.

How does Razoyo handle key person risk as a small firm? Every change is reviewed by a lead developer before it merges, clients get access to the project board, and once fees are paid you own the code we write for you, plus the documents, repository and infrastructure. Retainers end on 30 days’ notice, and the System Spec is yours to take to any team.

Talk it through

If you are about to hire a small firm, or you already depend on one and it is starting to worry you, that is a free 30 minute conversation. Bring the contract or the proposal. We will run the Monday Handover Test on it with you and tell you which checks fail, what to ask for, and if the firm you are talking to passes, that you should hire them. Schedule Free Consultation.

Paul Byrne is President of Razoyo, a software engineering firm in The Colony, Texas taking prototypes and constrained systems into production since 2011.