How to Choose a Technology Partner in the AI Era

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.

It doesn’t work anymore.

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, not a cost. 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. 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 the hard way watching our own bottleneck — it was never the number of people.)

Which means the signals you were trained to trust now point the wrong way.

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.

Ask a partner: what do you run your own company on? “We use the same off-the-shelf tools everyone uses” is fine for them, but it 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. (We’ve written about that gap in the 11pm fix.)

You want a partner with scars from their own software. Not someone advising from the sideline.

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. You can’t hire your own team to run it because nobody outside their building knows how. 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 will 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.

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. A partner who can put you in front of something live, something they built and still run, is showing you the one thing that can’t be faked.

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, and we’ve mapped that distance in why 95% of 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 is 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.” “We picked the wrong tool, admitted it, replaced it.” 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. A partner who’s never undone a decision has never been close enough to the edge to learn anything.

The Checklist: Questions a Non-Technical Owner Can Ask

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

“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.
“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.”
“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.
“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.”
“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.
“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.

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.

Choosing a partner and not sure what you’re looking at? We build our own software, run our own business on it, and hand over systems you can actually own. Let’s talk.