What should I look for in an AI development partner?

Four things above all: a system of theirs you can watch running in production, handover terms that name code, prompts, infrastructure, and evals individually, senior engineers who will sit inside your workflow, and at least one story of telling a prospect that AI was the wrong answer.

Should I hire an agency, a freelancer, or build in-house for AI?

It depends on volume and stakes. In-house pays when AI work is continuous and you can win the talent market. Freelancers fit small, well-understood scopes. For taking a real workflow to production without permanent headcount, embedded fixed-scope engagements carry the best incentive structure: the vendor is paid to finish, not to stay.

What questions should I ask an AI vendor before signing?

Ask to see production systems they operate today, who exactly will do the work, what their evals look like, what the handover contains item by item, what happens when the model provider deprecates a version, and when they last told a client not to use AI. The answers separate operators from resellers of demos.

How do I avoid vendor lock-in with AI development?

Contract the handover before the build: code in your repositories, infrastructure in your cloud, prompts documented, evals transferred, credentials under your control, runbooks written. Then verify with a cold-start test where your side redeploys the system without the vendor touching anything.

How to choose an AI development partner

The short answer

Choose an AI development partner by verifiable evidence, not references: a system of theirs running in production that you can use, handover terms that individually name code, prompts, infrastructure, and evals, the actual senior engineers who will sit in your workflow, and proof they have told someone no. Vendors who pass those four tests are rare and worth the search.

The AI services market is young, loud, and asymmetrical: every vendor has seen a hundred buyers, most buyers are choosing a vendor for the first time. This guide is the equalizer. It is also, deliberately, a standard we can be held to.

What you are actually buying

Strip the proposals down and an AI development engagement sells three things: judgment about where AI pays inside your operation, engineering that survives contact with production, and the terms under which you keep what gets built. Most selection mistakes come from evaluating only the first, because judgment is what demos and decks display. The failure data says the second is where initiatives die: the overwhelming majority of AI pilots return nothing, mostly for engineering and workflow reasons, not strategy ones. And the third decides whether year two of your system costs you a maintenance decision or a ransom.

The engagement models, honestly compared

Model	Incentive structure	Strongest when	Weakest when
Big consultancy	Paid for time and scale; growth means more of both	Political cover and enterprise coordination matter	You need one production system, not a program
Traditional dev agency	Paid to deliver the brief as written	The problem is stable and fully understood	The brief is a guess about an AI workflow
Freelancer	Paid per project; reputation-driven	Small scope, clear spec, low integration surface	Production hardening and handover discipline are needed
In-house hire	Salaried; aligned but expensive to reach seniority	AI work is continuous and hiring is winnable	The work is real but part-time, seniority scarce
Embedded fixed-scope studio	Paid to finish and hand over; ends on purpose	A real workflow needs production in weeks, owned	You want a strategy phase before any building

The models are not moral categories; they are incentive structures. The embedded fixed-scope model, described in forward-deployed engineers as a service, is the one whose incentives point at finishing: the vendor is paid to ship and leave, so lingering is a cost, not a revenue line. The lighter-touch variant is the fractional AI engineer. Whatever the model, the tests below are identical.

Every engagement model is an incentive structure. Buy the one whose incentives point at finishing.

The nine questions that expose vendors

01Show me a system of yours running in production right now. Running, not screenshotted. A vendor with nothing operable is selling their next experiment. Ours is the agent on this site; every claim we make about production AI is testable in one click.
02Who exactly does the work, and where do they sit? Names and seniority, not a bench description. Then: how much time inside our actual workflow? A partner who designs from briefs has already made the classic mistake.
03What do your evals look like? The single fastest quality test in the industry. Operators answer with specifics and a war story. Everyone else changes the subject. What good looks like is in our evals guide for buyers.
04Walk me through the handover, item by item. Code, prompts, infrastructure, evals, credentials, runbooks. Hesitation on any item is disclosure.
05What happens when the model provider retires the model? Every LLM system inherits this event. A real answer names the mechanism: pinned versions, deprecation tracking, golden conversations re-run on migration. We published our own incident; ask your vendor for theirs.
06What did you ship for the last client, and how fast? Weeks-not-quarters claims need receipts: scope, timeline, what changed for the users. Anonymized is fine. Vague is not.
07When did you last tell a prospect not to use AI? The most honest signal in the set. Embedded discovery regularly finds that boring automation wins. A vendor with no such story sells AI to every problem.
08What do you need from us to start, and what stalls you? Good partners name the real dependencies immediately: a workflow owner who decides, reachable data, access. Vendors who need nothing from you plan to build far from the work.
09How does the engagement end? The right answer has a shape: a defined scope, a handover, an option (not an obligation) to continue. Open-ended engagements are employment with worse terms.

The ownership terms that matter

"You will own the IP" is the least meaningful sentence in AI contracting, because an AI system is more than its intellectual property. The six transfers that constitute real ownership, and the cold-start test that verifies them, are specified in the ownership handover. Put them in the contract before the build, and treat resistance as the vendor explaining their retention model. The industry's largest players now market self-sufficiency as the goal; hold everyone, including us, to it.

Red flags, compressed

–A price before anyone has seen the workflow. A number produced without looking is a guess dressed as a quote.
–Demo-first sales with no production tour. Demos are the easiest artifact in AI to manufacture.
–Evals described as an add-on. That sentence relocates quality assurance from their build to your production.
–Hosting that must stay in their accounts. Rent, renamed.
–AI recommended for everything you describe. Some of what you described is a cron job.
–Strategy phases sold before any contact with the work. Analysis conducted away from the workflow produces the brief that produces the failure statistics.

Applying this to us

We wrote the standard we want to be judged by, so the application is straightforward. Our production system is the Discovery Agent that runs our own funnel, usable by anyone before a single call. Our engagements are fixed-scope sprints described on the approach page, they end in the six-part handover, and the fastest way to test all of it is the entry point everything on this site leads to: a 30-minute Workflow Audit, quoted only after we have seen the workflow. If we ever fail the nine questions, this page is the receipt.