What key man risk looks like in AI builds
One person wrote the prompts. One person holds the API keys. One person knows why the workflow branches the way it does. Nothing is documented because it lived in their head and they were always available. Then a model gets deprecated, or the CRM changes its API, and the person who could fix it in ten minutes is on another project or gone.
We see this every month. An owner paid a freelancer to build an intake bot, it broke the first time the API changed, and nobody in the company could touch it. The system is not the problem. The single point of failure is.
How a build and run partner removes it
Three things. Documentation: every system ships with a written map of what it does, what it connects to, and where the keys live. Team maintenance: a monthly run plan means more than one person is paid to keep it alive. Ownership: you own the code, the accounts, and the data, so any competent developer can pick it up if you ever want to leave.
The cost difference
A freelancer quotes 5,000 to 10,000 for a build and nothing for maintenance because there is no maintenance. A build and run partner quotes from 15,000 for the build and from 2,500 a month to run it. The second number looks bigger until you price the first outage: a week of dead lead routing at a 5M business costs more than a year of maintenance.
Full numbers on what a done for you AI system costs.
What to ask before you hire anyone to build AI
Do I own the code and the accounts? Who maintains it after launch and what does that cost? What happens when a model or an API changes? Where is the documentation? What happens if you leave? If any answer is a shrug, you are buying key man risk. Get a free AI audit and we will show you what a documented, maintained system looks like on your own workflows.
Questions we get asked
What if my freelancer is great?
Keep them, and get the documentation, the account ownership, and a maintenance agreement in writing. Great people still leave.
Can I switch to a partner later?
Yes. We take over existing builds regularly. The audit maps what exists, what is undocumented, and what needs to be rebuilt versus kept.
What documentation should I expect?
A system map, every integration and where its credentials live, the prompts and why they are written that way, and a runbook for the common failures.
How do I know if I have key man risk?
Ask who could fix the system tomorrow if the builder was unreachable. If the answer is nobody, you have it.