The average AI consulting engagement lasts 18 months. Ours lasts 90 days. That's not a pricing strategy. It's a philosophy.
When I tell prospective clients that our goal is to make ourselves unnecessary within a quarter, the reaction is always the same. Confusion, then suspicion, then (once they've spoken to our past clients) relief. Most of them have been burned before. They've been through the 18-month engagement that produced systems they can't run, infrastructure they don't own, and a team that's no more capable than when the consultancy arrived.
That's not an accident. It's a business model.
Revenue equals daily rate times duration. A consultancy that charges £2,000 per day per consultant earns £40K per month per person deployed. A three-person team over 18 months generates £2.16M in revenue. The same team over 90 days generates £360K.
The financial incentive is overwhelmingly in favour of longer engagements. Every month the consultancy extends the engagement is another month of revenue. Every dependency it creates, intentionally or not, is another reason the client can't terminate.
The tell is in the statement of work. Look for "ongoing support and maintenance" as a line item. That's dependency written into the contract before a single line of code has been written. It assumes from day one that the client won't be able to operate independently.
The other tell is proprietary tooling. If the consultancy builds on its own platforms, its own repositories, its own infrastructure, then the client is locked in by architecture. You can't run the system without them because the system lives in their environment. Vendor lock-in disguised as consulting.
Most of them aren't trying to trap you. The incentives just make it inevitable. When the financial reward for extending an engagement is six times greater than the reward for ending it, the engagement will extend. Bad incentives produce bad outcomes. Every time.
If you're currently working with an AI consultancy, run through this checklist. If three or more apply, you have a dependency problem.
1. They build on their infrastructure, not yours. Your AI systems run on their cloud accounts, their Kubernetes clusters, their CI/CD pipelines. If they disappeared tomorrow, you'd lose access to production systems. This is the single biggest red flag. Competent consultancies build on your infrastructure from day one.
2. They don't pair with your engineers. Their team builds in isolation. Your engineers get handoff documents, not hands-on experience. Code reviews happen internally within the consultancy, not with your team. Your people watch demos of completed features instead of participating in the build.
3. There's no transfer plan in the contract. Search the statement of work for the words "transfer," "handover," or "self-sufficiency." If none of those words appear, the engagement has no planned end state. It'll continue until someone on your side forces it to stop.
4. They measure activity, not outcomes. The monthly report lists hours worked, tickets closed, meetings attended, and sprints completed. It doesn't list revenue generated, costs reduced, or margin improved. Activity metrics justify continued engagement. Outcome metrics justify completion.
5. After 6 months, you couldn't run the system without them. This is the ultimate test. If the consultancy left today, could your team keep the AI systems running? Could they deploy the next agent? Could they diagnose and fix failures? If the answer is no after six months, you're being made dependent.
Curious what your margin opportunity looks like?
Free Tool
How much margin are you leaving on the table?
Answer 6 questions. Get a personalised margin estimate in under 2 minutes.
Take the Free Margin AuditI built MarginOps around the opposite principle. Every decision we make is designed to make the client independent, not dependent.
We build on your infrastructure. Your cloud accounts. Your repositories. Your CI/CD pipelines. Your monitoring. When we leave, nothing moves. The systems stay exactly where they are, running exactly as they were, accessible to your team with no interruption.
We pair with your team from day one. Every sprint, every deploy, every code review involves your engineers alongside ours. This isn't optional. It's a contractual requirement. We won't build in isolation because isolated builds create dependency by default.
The Self-Sufficiency Test at day 75. Five questions that determine whether we leave. Can your team deploy a new agent independently? Can they diagnose failures? Can they present the business case to the board? Can they onboard new team members? Can they say no to a bad AI idea with technical and commercial reasoning? If yes to all five, we're done.
Our engagement is designed to end. The AI Mobilisation Pattern has four phases: Assess, Deploy, Enable, Transfer. The transfer phase isn't optional. It's the entire point. We measure one thing: can your team deploy the next agent without us?
Here's how to avoid building dependency with any AI consultancy.
Demand a transfer plan in the statement of work before signing. Not a vague commitment to "knowledge transfer." A specific plan with milestones, dates, and acceptance criteria. If the consultancy pushes back on this, they're telling you everything you need to know about their business model.
Insist on pairing, not handoffs. Your engineers should be in every code review, every architecture decision, every deployment. Doing, not watching. If the consultancy says their team "works faster alone," that's true, and it's also how dependency gets built.
Set a self-sufficiency milestone with a specific date. "By day 75, our team will be able to deploy an agent independently." Put it in the contract. Tie a portion of the consultancy's fees to it. When the consultancy only gets paid if you become independent, they work to make you independent.
Ask what happens when they leave. The right answer is: "You don't notice." The systems keep running. Your team keeps building. The only thing that changes is you stop paying invoices. If the answer involves transition periods, ongoing support packages, or maintained access to proprietary tools, you're looking at a dependency model.
Check their track record of leaving. A consultancy that builds for self-sufficiency should have a long list of clients who run AI systems independently. If they can't name a single client who operates without them, they've never successfully transferred. Walk away.
The best AI consultancy is the one that puts itself out of a job, because it succeeded. Read more about our approach on the about page, or see how we use Claude to accelerate delivery. And if you've been burned by a dependency-building consultancy before, read why most AI consultancies fail. You'll recognise the pattern.
Our AI Readiness Assessment gives you a deployment plan in 5 days. If we work together after that, the engagement is designed to end at day 90 — with your team fully self-sufficient.
We go into businesses and make them permanently more profitable. Every initiative is EBITDA-tracked.