# How to Choose an AI Implementation Partner

> How to choose an AI implementation partner that actually ships: the four signals that survive the hype, the questions to ask, and how to spot a sales deck.

Canonical: https://thegrowthproject.com/guides/ai-implementation-partner/

A founder asked me last month how big my team was.

I asked why it mattered.

He paused. He'd been told to count heads. A bigger team meant more capacity, more safety, a better bet. That rule had worked for twenty years.

In the AI era, it doesn't work anymore. And it's exactly the rule that leads mid-market companies to hire the wrong partner, spend six figures, and end up with a pilot that never ships.

This is how to choose an AI implementation partner that actually delivers: what the role really is, the four signals that survive the hype, and the questions a non-technical owner can ask to tell delivery from a deck.

**TL;DR:** The old signals for picking a technology partner, headcount, rate cards, "we have a big team," now mislead you. A small team using AI well out-delivers a large one billing by the hour. The new signals are simpler and harder to fake: do they ship and use their own software, do they hand you a system you can run yourself, can they show you something live in production, and will they tell you what failed. Ask those four things. Watch what they show, not what they say.

## What an AI implementation partner actually does

The label is overloaded, so start by separating three things people sell under the same word.

| | What they sell | Where it ends |
| --- | --- | --- |
| **Consultant** | A recommendation, a roadmap, a deck | They leave before the build |
| **Dev shop** | Code built to a spec | They ship and move on; you operate it |
| **Implementation / delivery partner** | A working system, run in production, then handed over | They stay until it runs without them |

A real AI implementation partner lives in the middle of the work: they build the thing, run it in production with you, and leave you owning it. That's the gap where most projects die, the space between the people who advise and the people who operate, what we call [the implementation chasm](/blog/implementation-chasm/). [70% of digital transformations fail](https://www.mckinsey.com/capabilities/transformation/our-insights/common-pitfalls-in-transformations-a-conversation-with-jon-garcia) (McKinsey), and [95% of AI pilots never reach production](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/) (MIT). The partner you pick is the single biggest lever on which side of those numbers you land.

## The old signals are now noise

For most of business history, size meant capability. A bigger team did more work. A longer rate card meant deeper expertise. "We have 200 engineers" was a credential. You picked the partner who looked the most resourced, because resources were the constraint.

That logic is now inverted. A capable engineer using AI tools well does the work of several, not by typing faster, but by compressing the loop between idea and working software. The constraint moved. It's no longer how many hands you can hire. It's how much judgement sits behind them. (We learned that watching [our own bottleneck](/blog/we-were-the-bottleneck/), it was never the number of people.)

| The old signal | What it actually tells you now |
| --- | --- |
| Big headcount | A large bill, and coordination overhead you'll fund |
| Detailed rate card | They sell time, not outcomes |
| "We have a huge team" | Most of that team is between you and the people who build |
| Impressive slide deck | They're good at slides |
| Long list of frameworks | They name-drop tools, not results |

None of these are lies. They just measure the wrong thing. A large agency can still ship. But size is no longer evidence that they will. It's just size. So what do you measure instead?

## Signal one: do they use their own software?

There's a word for it now. Dogfooding. Running your own product, every day, before you ask anyone else to. It sounds obvious. Almost nobody does it.

Most technology partners advise. They build something, hand it over, invoice you, and move on. They never live inside the thing they made. They never feel the friction. The consultants who draw the Friday plan leave before Monday, and they never see what breaks.

Operators are different. We build software for ourselves first. We run our own business on it. When a workflow is clumsy, we're the ones cursing at it on a Tuesday. That feedback loop is the difference between software that demos well and software that survives real work. (That's the gap we wrote about in [the 11pm fix](/blog/the-11pm-fix/).)

Ask a partner: what do you run your own company on? "The same off-the-shelf tools everyone uses" tells you they don't eat what they cook. "We built it, and here's how it breaks for us" means you're talking to someone who understands the gap between a plan and a Monday.

## Signal two: will they hand you something you can run?

This is where good partners and dependency merchants split.

A dependency merchant builds you a system only they understand. The documentation is thin. The architecture lives in one person's head. Every change requires a new engagement. Cancelling them means starting over. It's a great business model. For them.

A real partner hands you a system you can run without them. Standard tools where standard tools fit. Documentation a new hire can follow. A clean handover. The honest ones tell you plainly, "here's the part you could take in-house, and here's the part where you'll still want us." They're not afraid you'll leave.

The test is uncomfortable to ask but easy to score. **Ask them: if we parted ways in twelve months, what would we be left with?** A good partner has a real answer. A bad one gets vague, or explains why you'd never want to. Engineered dependency feels like service. It's actually a leash. The technical version of a clean answer is a [zero-trust handover](/guides/zero-trust-handover/): you own the accounts and secrets, and can verify the vendor kept no access.

## Signal three: can they show you something live?

Anyone can build a slide. Anyone can mock a screen. AI has made the demo cheaper than ever, which means the demo proves less than ever.

The only thing that counts is software running in production, with real users, doing real work, while you watch. Not staging. Staging is empty and polite. Production is full of people doing things you never planned for, on the worst possible day.

So make them show you. Don't accept "we've done lots of projects like this." Ask to see one. Working. Now. If everything they can show is a case-study PDF and a logo wall, you're buying a story. The distance between a pilot and production is where most projects quietly die, we map exactly how to cross it in our guide to [production-ready AI](/guides/production-ready-ai/), and why most don't in [why 95% of AI projects fail](/blog/why-ai-projects-fail/).

Slides are a promise. Production is proof. Buy proof.

## Signal four: will they tell you what broke?

This is the one most owners never think to test. It's the most revealing.

Ask a potential partner about a project that went wrong. What failed. What they reverted. What they'd do differently. Watch what happens.

A salesperson deflects. Everything went great, every client delighted, no war stories. That's not confidence. That's someone who either hasn't shipped enough to have scars, or won't be honest when things go sideways, and things always go sideways.

An operator has stories ready, because they've lived through the failures. "We rolled out a migration, it choked under load, we rolled it back the same night and re-did it in phases." That candour is the best predictor of how they'll behave when your project hits its own Monday. People who tell you the unglamorous truth before you've paid them will tell you it after. The reverts matter as much as the wins, [what operators know that consultants don't](/blog/what-operators-know/) is mostly what broke and why.

## The checklist: questions a non-technical owner can ask

You don't need to understand the code. You need to read the answers.

1. **"What do you run your own business on?"** Good: they built it, and can tell you where it frustrates them. Bad: the same tools you already use, no skin in the game.
2. **"If we stopped working together in a year, what would we be left with?"** Good: a system you own, documented, runnable by your own hires. Bad: vagueness, or "you wouldn't want to do that."
3. **"Show me something you built that's running in production right now."** Good: a live system, or a reference client describing what's actually working. Bad: only slides, mockups, logos.
4. **"Tell me about a project that went wrong and what you reverted."** Good: a specific story with a specific lesson. Bad: "everything's always gone great."
5. **"Who actually does the work, and how close are they to me?"** Good: the people who build are in the conversation. Bad: layers of account managers between you and anyone who writes code.
6. **"How will I know if this is working in 90 days?"** Good: a concrete, measurable outcome. Bad: activity reports and hours billed.

Six questions. No technical knowledge required. Each one separates the operators from the order-takers.

## What it should cost

Pricing is a signal too. A delivery partner quotes **fixed scope, up front, with a real production date**, and prices the outcome, not the hours. The number depends on what's being built; you should know it before any work starts.

Be wary of the opposite shape: time-and-materials billing with no production deadline, retainers that renew by default, and a scope that quietly expands every quarter. That's how a six-week pilot becomes a permanent line item. The best partners would rather make themselves unnecessary than keep you on a leash, no retainers by default, and a clean exit when the system runs without them.

## The bottom line

The market still rewards looking big. Polished decks, large teams, long rate cards. But a small team that ships, dogfoods, hands over cleanly, and tells you the truth will out-deliver a large one every time.

Stop counting heads. Start watching what they put in front of you.