Build-and-transfer: shipping AI your client can actually run.
How we design systems for handover, not dependence.
There are two ways to leave an AI system behind in a business. One keeps working after you go. The other quietly dies the day your access is revoked. Most fail the second way, and it is rarely the model's fault.
MIT's 2025 research put a number on it. Enterprises that bought or partnered for AI saw success around two-thirds of the time. Those that built in-house succeeded roughly a third as often. Dig into why, and the pattern is not about engineering talent. It is about what happens at handover. Systems stall because they cannot retain feedback, adapt to context, or improve once the people who built them step away. A polished pilot looks impressive in a demo and then collapses in the field, because it was built to be shown, not to be run.
We design for the opposite outcome. We call it build-and-transfer, and it changes the engineering decisions from the first day.
Build where the client already lives
The most common reason a system dies is that it was built somewhere the client cannot reach. A clever tool on a consultant's stack, behind a consultant's keys, is a dependency, not an asset. So we build inside the tools the business already pays for and already runs: their Microsoft tenant, their existing data, their identity and access. When we leave, nothing needs to be migrated, because it was never anywhere else.
Simple enough to be owned
Complexity is where ownership goes to die. A system only the builder understands is a system only the builder can run. We choose the simplest design that solves the problem, and we resist cleverness that impresses in a review and strands the client afterwards. The test of good engineering here is not how sophisticated the system is. It is whether the person who inherits it can change it.
Documented for the next person, not the last
Most handover documentation is written to close a project, not to run a system. We write it the other way around. Every tool ships with a plain-language record of what it does, what feeds it, where its data flows, and how to change it. That last point matters most. A system you can only operate is a dependency. A system you can extend is an asset.
Transfer the skill, not just the software
The deepest form of dependence is not technical, it is human. If only we know how to use what we built, we have not transferred it, we have rented it to you. So the build comes with the capability to run it. We train the people who will own it, we identify the champions who will extend it, and we hand over the know-how alongside the keys. The goal is that the team needs us less over time, not more.
Why this matters more in South Africa
In a market where skills are the binding constraint, dependence is expensive in a way that goes beyond fees. South Africa's financial regulators found, in their late-2025 survey, that the scarcest resource in the sector is AI talent. If your system can only be run by people the market is fighting over, you have built a liability. A system your own team can operate and extend is worth more than a more sophisticated one they cannot. Build-and-transfer is not a courtesy. In a skills-short economy, it is the difference between an asset that compounds and a cost that recurs.
The shadow economy is a clue
MIT also found that in more than nine out of ten firms, staff were quietly using their own AI tools, even where the official system had failed. That is not a discipline problem. It is a signal. People reach for tools they can actually use. A handed-over system that is simple, documented, and owned competes with that instinct. A complex, consultant-bound one loses to it.
Shipping AI a client can run is not the easy path. It means building in their environment, keeping it simple, documenting for the future, and giving away the very skill a more cynical model would hoard. But it is the only path that leaves something behind that is still alive a year later. We would rather build that.
Sources: MIT NANDA, The GenAI Divide: State of AI in Business (2025); FSCA & Prudential Authority, Artificial Intelligence in the South African Financial Sector (Nov 2025).
