How to Pick an AI Developer (And Spot the Ones to Avoid)

Two AI developers walk into the same auto shop on the same afternoon. Same problem to solve: every morning, the service writer burns an hour re-typing parts orders from supplier emails into the shop’s scheduling software.

The first one shows slides — “AI-powered operational transformation.” The second opens a laptop, drops in three of last week’s real supplier emails, and runs them through a working prototype right there at the counter. One of them understands the job. The other is selling a category. Here is how to tell them apart before you sign anything.

Can they show you your own data running through their app?

This is the fastest filter there is, and most people skip it because asking feels rude. It isn’t. A developer who has actually built things like this will want your real data — a sample invoice, a messy spreadsheet, last month’s support tickets — because that mess is what tells them whether the idea holds up.

The one who deflects, who wants to talk architecture instead, who keeps steering back to “the platform” — that is someone who hasn’t built the specific thing you need yet. Maybe they can. But you are paying to find out, and you should know that going in.

Who owns the code when the invoice is paid?

Ask this directly, in writing, before you start. Some shops build your app and hand you everything — the code, the credentials, the freedom to walk away and hire someone else to maintain it. Others build a black box only they can touch, then quietly become a subscription you can’t cancel without losing the tool your team now runs on.

Neither is automatically wrong. A subscription can be perfectly fair when the price reflects real ongoing work — hosting, model updates, support. What’s wrong is not knowing which one you signed up for. Get the ownership answer on paper before the build starts, not after you depend on it.

What happens when the model gets something wrong?

Every AI system gets something wrong sometimes. That is not a defect to hide — it is a design question to answer out loud. Ask the developer to walk you through a specific failure: the model misreads an invoice, misroutes a customer message, flags the wrong record. What does your team see? Who catches it? What’s the undo?

Someone who has shipped these systems will have an answer ready, because they have hit that wall before. Someone who says “it’s very accurate” and moves on hasn’t thought about it — which means your team will do the thinking instead, at the worst possible moment, mid-shift, with a customer waiting.

Do they talk about your bottleneck, or about the technology?

Listen to the first few minutes of the pitch. A developer solving your problem talks about your bottleneck — the task your team hates, where it breaks, what a good day looks like once it’s gone. A developer selling a technology talks about the technology: the model, the framework, how cutting-edge it all is.

You don’t need cutting-edge. You need the manual task gone. The best builders are almost boring about the tech, because they have learned that clients don’t care what’s under the hood — they care whether the hour they used to lose every morning is theirs again. Watch for the ones who:

• ask about your workflow before they name a single tool;
• can point to the exact step where your current process breaks;
• describe the smallest version that would already help, instead of the whole vision on day one.

Does the timeline shrink as they learn more, or only grow?

Real projects get sharper as the developer sees your actual data and workflow — the estimate should tighten, not balloon. If every conversation adds scope instead of removing uncertainty, that is not thoroughness. That is someone discovering, in real time, that they didn’t have a plan when they quoted you.

The opposite is a red flag too: a developer who promises a fully custom system, in your industry, built to your exact workflow, in a suspiciously short window with no discovery at all. Either they have built this precise thing before — worth asking straight out — or they are about to hand you a generic wrapper and call it custom.

This is the bar we hold ourselves to

We built Command Module around this test, because we got tired of watching small businesses get sold platforms instead of solutions. The deal is plain: you bring the task your team hates, we build the app around how you actually work, and you own it — free for the first business in your industry to bring it. Then we sell it to the rest of that industry, once it has proven itself on someone’s real Tuesday.

FAQ

How do I know if an AI developer actually understands my industry, or is just pattern-matching a pitch?

Hand them a real piece of your work — an invoice, a ticket, a spreadsheet — before you talk price. Someone who understands your industry asks sharp follow-up questions about it. Someone who doesn’t nods and steers back to their platform.

Is it a bad sign if a developer wants to start with a small version instead of the full system I asked for?

No — that is usually the good sign. A small, working first version means they are testing the idea against reality early, before either of you has spent much. Be more worried about someone who commits to the whole vision upfront with no checkpoint in between.

What is the one question I should never skip before hiring an AI developer?

Who owns the code and the data when this is over. Get it in writing before the build starts. It is the question that decides whether you end up with a tool or a landlord.