Software Succession Planning for Small AI Vendors

A procurement team will spend three meetings asking an AI vendor about data residency and training policy. Almost none of them ask the question that actually determines whether the vendor still exists next year: what happens to this software if the person who built it is gone.

That gap is getting wider, not smaller. AI tooling now lets one or two people ship software that used to need a ten-person team. That is good for buyers: faster delivery, lower cost, a system built for their exact problem instead of a configured slice of something generic. It also means a growing share of B2B software now runs on a bus factor of one. Nobody underwrites that risk, because nobody asks about it.

The Concentration Risk Nobody Underwrites

Ten years ago, a piece of software good enough to run a company's core operation needed a company behind it. That correlation has broken. A single developer with the current generation of AI coding tools can now build and ship a system that a five-person team would have taken two quarters to produce a decade ago.

This is the argument for working with small, specialised vendors in the first place. They move faster, charge less, and build exactly what the business needs instead of the nearest configurable module in a platform that was designed for ten thousand other customers. For a niche B2B operation, that fit is often worth more than the safety of a household name.

What it introduces, quietly, is concentration risk. If the software runs a client's daily operation and one person holds the entire mental model of how it works, that operation now has a dependency with no institutional backstop. Not a hypothetical one. If the vendor becomes unavailable, unwilling, or insolvent, the client has working software and no path to keep it working.

Buyers do not ask about this because the category barely has a name yet. Vendor security questionnaires are a mature genre. Vendor continuity questionnaires, for AI-era software built by very small teams, mostly do not exist.

Big Platforms Are Selling Continuity, Not Just Software

Salesforce, HubSpot, and Microsoft rarely win a feature-for-feature comparison against a system built specifically for one company's workflow. What they win is the confidence that the vendor will still be answering support tickets in five years, because the company behind the software has thousands of employees and a balance sheet.

That confidence is not free. The buyer pays for it in three ways: a product tuned to the median customer rather than their specific problem, integration work to bend a generic tool around their process, and a price that reflects enterprise sales and support overhead rather than the marginal cost of the feature they actually use.

A boutique or bespoke AI vendor inverts that trade. Better fit, faster delivery, lower price. What is missing by default is the institutional backstop, because there is no institution behind it, just a person or a small team.

Framed that way, the decision is not "safe platform versus risky vendor." It is a trade-off between two different kinds of cost: pay upfront for continuity you may never need, bundled into every feature you buy, or pay for exact fit and speed, and buy continuity separately, deliberately, sized to what the engagement actually needs.

What Continuity Actually Means, in Five Artefacts

"We will make sure you are covered" is not a commitment. It is a feeling, and feelings do not survive a client's own risk review. Continuity, done properly, is five specific artefacts.

Technical documentation. Architecture, deployment steps, environment variables, database schema, recovery procedures, kept current rather than written once at kickoff and abandoned. Every other artefact on this list depends on this one. Escrow without current documentation is a code dump nobody can operate.

A backup developer retainer. A vetted external developer, under NDA, who reviews the codebase periodically, ideally does a trial deploy against staging so their knowledge stays live, and is contractually available to step in within an agreed window if a trigger event occurs. This is the artefact that turns "we have the code" into "someone can actually run it."

Software escrow. Source code, documentation, and deployment scripts deposited with a neutral third party, released to the client under defined trigger conditions such as extended unavailability or insolvency. This is the most formal and most expensive piece, and the one most B2B buyers assume exists by default. It usually does not, unless someone asks for it.

Key person insurance. A policy naming the client, or the engagement, as beneficiary, paying out if the founder or lead developer dies or becomes permanently unable to work. It does not restore continuity by itself. It funds the transition, covering the cost of a replacement developer or a rushed handover while the backup developer retainer and documentation do the operational work.

A continuity clause in the contract. The piece that makes the other four enforceable rather than promised. It specifies what triggers a handover, what the client is entitled to receive, and within what timeframe. Without it, everything above is goodwill.

None of these five require a large vendor to implement. They require a vendor who has decided, before being asked, that this is part of what they are selling alongside the software.

Not Every Engagement Needs the Full Stack

The mistake in the other direction is treating all five as mandatory for every project. A small internal dashboard that saves someone two hours a week does not need software escrow. The cost would outweigh the risk it covers.

Right-size to two questions: how much does the client's operation actually depend on this running, and how bad is a gap if it stops. A marketing microsite or an internal reporting tool needs documentation and a clause, nothing more. A system that runs a client's daily operations, the kind that would stop a warehouse, a claims process, or a customer-facing service if it went dark, justifies the backup developer retainer and, past a certain deal size or criticality, escrow and insurance too.

This is also where cost stops being the objection people expect. Documentation is mostly discipline, not budget. A backup developer retainer runs to a few thousand euros a year for quarterly reviews, roughly the same order of magnitude as an annual penetration test most B2B software buyers already budget for elsewhere. Escrow and key person insurance cost more, which is exactly why they belong on the systems where the downside actually justifies it, not on everything by default.

Why We Build This In, Not Bolt It On

We wrote recently about treating AI trust and EU sovereignty as product decisions rather than comms, because the buyer changed and started asking specific, checkable questions instead of accepting a paragraph on the about page. Continuity is the operational half of the same shift. Sovereignty is about not being structurally at the mercy of where a vendor's model runs or what happens to your data. Continuity is about not being structurally at the mercy of whether the vendor is still around.

We run several client systems that fall squarely into the "would stop an operation" category, including live 24/7 automation a client depends on daily. For engagements at that level, documentation and a continuity clause are not something a client has to negotiate for after the contract is signed. They are part of what gets scoped before the first sprint.

The honest version of this article is not "hire a big platform to avoid this risk." Big platforms solve continuity by pricing it into everything, whether the specific project needs it or not, and by giving up the fit that makes a bespoke system worth building in the first place. The better answer, for a genuinely niche or complex B2B problem, is to ask the small vendor in front of you what their continuity plan is before you sign, not after something goes wrong.

What to Do Next

If you are evaluating a boutique or bespoke AI vendor, ask for their continuity plan before you sign, not after something goes wrong. Ask specifically: is there current documentation, is there a backup developer who could step in, and what does the contract actually guarantee if the vendor is unavailable.

If you are a solo or small team building B2B software, the cheapest version of this to start is documentation kept current and a clause in your standard contract. Add a backup developer retainer once a client's operation genuinely depends on the system running. The rest scales with the size of what you are protecting.