Before Hiring a Software Vendor: Assessing the Risk They Disappear

When a selection committee sits down to compare proposals from several software vendors, the main questions on the table are who fits the scope of work and who can deliver on time. The question that belongs next to them is this: if this company, or the key people on this team, are no longer around in year three, what will your organization actually be holding?

The question does not come from distrust. Software companies close or get acquired for reasons that have nothing to do with the quality of their teams, and good engineers can always change jobs.

We are also a vendor that organizations have to evaluate. So this article is written as the questions we think an organization should put to every bidder, us included. It is not written to tell you whom to pick.

The conditions that belong in the TOR from the start, from architecture documentation to cloud accounts held in the organization's name, we have covered in a separate article. This one covers the next step: reading each bidder during selection, before the contract is signed.

Owning the code and being able to open it are two different things

The first question an organization thinks of is who owns the source code they are paying for. The legal answer depends on both copyright law and the wording both parties agree to in the contract. We are not legal advisors, so we recommend that your organization's legal team read this clause in each bidder's draft contract directly.

One point worth handing to your legal team as well is the components the vendor did not write new for your project, such as open source libraries or a framework the vendor has built for use across many projects. Those parts come with conditions of use set by their original owners, so ask clearly what rights your organization gets to them when the contract ends.

From the practical side, what we see as equally important is that ownership on paper only works if your organization can open the code. A contract that delivers the source code at project close protects you on the day the project ends as planned. It does nothing on the day the vendor disappears halfway through, because that handover day never arrives.

The real exposure sits in the middle of the project.

So the question to put to every bidder during selection is whether your team will be able to read the repository from the first sprint, and whether code will be pushed there every working day or bundled up for each milestone acceptance. A bidder that wants to keep the code in its own systems first should be able to explain how often your organization will receive an updated copy.

If the main repository has to live on the vendor's side, a checkable option is a mirror copy kept somewhere your organization controls. Git's documentation explains that --mirror does not map only branches: it maps every ref of the source, including remote-tracking branches and notes, and sets things up so those refs are overwritten each time the copy is updated. A copy like this keeps the full change history, which we think is worth more than a final zip file, because the history shows when each part of the code changed and alongside which piece of work.

Key-person risk: the company stays, but the people who know your system may not

A vendor that is stable as a company still carries another layer of risk that its financial statements will not show. Knowledge of your system may end up sitting with one or two people on the team.

Picture the tech lead who designed the entire data structure resigning in the seventh month of the project. The company is still intact and sends a replacement, but the new person has to work backwards to understand why the system turned out the way it did. Meanwhile your project slows down without anyone breaching the contract.

There are only a few signals you can ask about without offending anyone.

• Ask for the key roles that will actually work on the project, with a backup for each role, not just the names of the team that came to present.

• Ask whether every piece of code is reviewed by someone other than its author. If it is, at least two people have read every part of the system.

• Ask to speak once with the team that will do the work before you decide.

• Ask whether a team member has ever left mid-project and how the work was handed over, asking about the process rather than about names.

A good answer does not have to claim that nobody has ever left. The more useful answer explains how the handover worked and how long it took before the new person could carry on.

What source code escrow is, and when it is worth it

Code escrow means depositing source code with a neutral third party. The US Department of Defense acquisition guidance in DFARS PGI 227.7203-2 describes the government and the contractor agreeing on a third-party escrow agent that keeps designated software until a condition written into the contract occurs. When that condition occurs, the government can obtain delivery of what was deposited, and the contract must also state the government's license rights in the deposited material.

The same guidance also says that escrow is not preferable in all cases, but may be useful when delivery or access during the contract is not feasible or not cost-effective. We think that sentence is the heart of the decision. If your organization can already read the repository throughout the project, escrow adds little protection for code written new for you.

Where we think escrow is still worth considering is when your system depends on software the vendor owns and licenses to you without source code, such as a vendor platform the whole system is built on. Your organization never had that code in the first place. If the vendor disappears, the code deposited with a third party is what leaves you a way to keep making changes.

From our side, escrow has limits worth knowing before you sign. The deposit may not be the latest version, or may not build, if nobody is responsible for checking it periodically. And even when the deposit is complete, code that arrives without anyone to explain it still takes a long time before a new team can maintain it. Escrow helps with access. It does not solve the people problem.

This kind of risk is different from being tied to a single cloud provider, which we cover separately in our decision framework on single cloud versus multi-cloud.

Reading a vendor's continuity signals without asking for too much

Some information your organization can check on its own without asking the vendor at all. Thailand's Department of Business Development runs DBD DataWarehouse+, which lets users search juristic person and financial statement data, and says the data can be used as supporting information for investment decisions and to check whether a juristic person exists. Looking up the company's status and the financial statement data it has filed is a check that bothers no one.

What we consider asking too much is requesting internal documents the vendor has no reason to disclose, such as a list of the other organizations that hire it, with contract values. That kind of request does not lower your risk, and it puts a vendor that keeps those organizations' information confidential at a disadvantage.

A more informative question is whether any system the vendor built several years ago is still in operation, and whether its owner would be willing to take a call from you. If so, ask that owner how much the work stumbled when people on the vendor's team changed, and whether they think moving the system to another team would really be possible if they ever needed to.

Another reasonable request is to see a sample handover package from a past project. If confidentiality agreements prevent that, a table of contents or a template is enough to show how carefully the vendor has thought about handing work over.

What you should receive along the way, not only on handover day

The goal of everything above is that another team can take over if that is ever needed. A takeover only works when your organization has been accumulating certain things throughout the project, rather than receiving everything in the final week. These are the items we think you should ask every bidder how and how often they will deliver.

• Code with its change history, in a repository your organization can read, as described above.

• Build and deploy steps written as a pipeline or script in the repository, not steps that live on one person's machine or in one person's memory.

• An automated test suite that someone outside the team can run and read the pass or fail results of on their own.

• The backlog and the list of known but unfixed bugs, in a system your organization can open, because that list is the first thing a new team needs to know.

• Starting configuration for each environment, with secrets already separated out and stored elsewhere.

The way we recommend checking that these items actually work is to schedule one takeover rehearsal in the middle of the project. Someone from your organization's team, or from a third team, who has never touched this project builds and deploys the system to a test environment using only what is in the repository.

Wherever they get stuck is where knowledge still lives in someone's head.

The middle of the project is when those gaps can still be fixed in time. During selection, ask each bidder whether they are willing to do a rehearsal like this, and if so, whether it can be written in as part of a milestone.

The limits of these criteria

The downside we need to state clearly is that the key-person criterion costs small vendor teams points, even though a team of four or five with direct experience of the problem may do better work than a large team that rotates people in and out. If you rule out small teams on headcount alone, your organization may lose an option that fits the work. Our advice in that case is to give more weight to repository access and the takeover rehearsal than to headcount, because those two reduce risk regardless of team size.

An objection we often hear

An objection we often hear is that this vendor is a large company with hundreds of employees and is not going to disappear easily. That is a fair point, and the chance of a large company closing may genuinely be lower. But the continuity your organization needs is not the continuity of the company. It is the continuity of the system you are paying for.

A company of any size can move a team to another project or drop a product for its own business reasons. The questions in this article apply to vendors of every size, and a large company's answers should pass the same criteria.

Where to start

If you are about to open your next round of proposals, the immediate starting point is to add these questions to your bid evaluation criteria and have every bidder answer them in writing, in the same format.

• From when will your organization be able to read the repository, and how often will code go into it?

• Who fills the key roles on the project, and who backs up each role?

• Are they willing to do a takeover rehearsal mid-project?

• Does any part of the system use software the vendor owns and does not open to you? If so, what protection do they propose?

In the meantime, have your legal team read the source code rights clause in each bidder's draft contract. Maintenance terms after handover are a separate contract, which we also cover in a separate article.

Summary

If you take only one thing from this article, ask every bidder whether your organization will be able to open the repository from the first sprint. Ownership of code written into a contract is worth exactly as much as what your organization can actually open on the day it needs to.

If your organization is drafting selection criteria for a software vendor and would like someone to review them, you can reach Superdev at 088-983-9386 or [email protected]. Our office is in Bangkapi, Bangkok. There is no deadline, and if you would like to ask us the questions in this article as well, we are happy to answer every one of them.