What You Own After You Hire an AI Developer

Search this and the first page splits cleanly in two. Half the results are agency landing pages with a form, half are step-by-step guides published by those same agencies. Each one describes a hiring process, and each one happens to end at the route its publisher sells.

The decision underneath is not which developer to hire. It is whether to hire anybody, and the three available answers leave you holding very different things when the work stops.

The three routes, by what is left behind

A contractor, a platform placement and an agency engagement are usually compared on cost and speed. That comparison is the least useful one available, because all three can be made to look similar on a rate card and they differ enormously in what survives the engagement.

• A contractor you manage directly. You own the code because it was written in your repository against your review. You also own every decision about architecture, evaluation and deployment, because there is nobody else to make them. This is the cheapest route if you already have an engineering function that can absorb those decisions, and the most expensive if you do not, since the bill arrives later as a system only one departed person understood.
• A platform placement. The platform solves sourcing and vetting, which is genuinely the slowest part of hiring, and solves nothing after that. What you own at the end is whatever your own process extracted along the way. The structural issue is that the platform's incentive ends at the placement, so nobody in the arrangement is accountable for whether the thing shipped works.
• An agency or studio engagement. You are buying a delivered system rather than hours, which means the handover is the product. It is also the route where the gap between vendors is widest, because the handover is the part nobody puts on the pricing page and the part that is cheapest to skip.

Whichever route you pick, write down before you start what you expect to be holding at the end. That list is the only thing that makes the three comparable, and it is the question every page on this SERP avoids, because two of the three routes answer it badly.

What a handover actually has to contain

For ordinary software the answer is roughly the code and a deployment. For anything with a model in it the code is the smaller half, because the behaviour is not in the code. It is in the prompts, the retrieval, the model version and the thresholds, and none of that is legible from the repository alone.

• The evaluation set, and the harness that runs it. This is the single item that determines whether you can change anything later. Without it you cannot tell an improvement from a regression, so every future edit is a guess, and a guess on a system you did not build is a guess you will not make. What an evaluation suite needs to contain is the longer version of this argument.
• The failure cases, written down and still failing. A handover with a green test suite and no known weaknesses is not a handover, it is a sales document. Ask which inputs break it. An engineer who has shipped this kind of system answers immediately, because the list is what they spent their time on.
• The cost model, with real numbers in it. Per call token cost, expected volume, and what happens to the bill if usage triples. You can build this side yourself with the LLM cost calculator and check the hosting half in the AWS cost calculator, which is worth doing before a vendor hands you their figure rather than after.
• The model and context decisions, with the reasoning. Which model, which context size, and why that one. The LLM context window comparison is the reference for the tradeoff, and the reason the decision needs documenting is that it expires: model lineups change, and a choice recorded without reasoning cannot be revisited.
• A runbook for the failure that wakes someone up. Provider outage, latency spike, a change in model behaviour after a version update. All three happen, none are hypothetical, and the response has to exist on paper before it is needed.

If a candidate or a vendor cannot describe this list, they have prototyped rather than shipped. That is not a disqualification on its own, since a prototype is sometimes exactly what you want, but it should change the price and it must change your expectations.

The questions that separate shipped from prototyped

The hard part of this hire is that the buyer usually cannot assess the skill. Both kinds of candidate demo well, because a demo is the artefact a prototype produces. These questions are hard to answer from prototype experience alone and easy to answer from production experience.

• What broke in production that your tests did not catch, and what did you change about the tests afterwards.
• How did you decide the system was good enough to ship. Specifically, what was the number and who agreed to it.
• Walk me through the last time a model update changed your behaviour. How did you find out.
• What did you stop using a model for after trying it.
• How do you handle a request that should not be answered at all.
• What does this cost per call today, and what did it cost when you started.

The fourth one is the most informative question in the list. Every production system has an abandoned use case, because the honest process of building one is finding the boundary. A candidate with nothing to put there has not found a boundary, which usually means they have not pushed anything far enough to hit one.

When the answer is not a hire

Two situations come up often enough to name, and in both the hiring question is premature.

The first is not having decided what the system is for. A brief that says we want to use AI in support is not a brief, and no developer can convert it into one for you, though several will try and bill for the attempt. The readiness assessment walks the same ground: what is written down, what sits in systems, and which of it is ready to be automated at all.

The second is a problem that is mostly data plumbing. A large share of what gets scoped as AI work is retrieval, permissions and integration, with a model doing a thin layer at the end. That work needs a competent backend engineer rather than a specialist, and paying a premium for the specialist buys you nothing because the specialism is not where the hours go. The question of who builds AI software covers how to tell the two apart before writing a job description, and how AI development cost is actually structured covers why the plumbing dominates the estimate.

How we scope this

We deliver engagements rather than place people, so treat this as disclosure rather than neutrality. What is worth borrowing is the shape of the handover, independent of who does the work.

Every engagement here ends with the evaluation suite in the client's repository, the cost model in a spreadsheet they can edit, the known failure list, and a runbook. Those four exist from the first week rather than being assembled at the end, because a handover written at the end is written by somebody who is leaving.

The thing to copy is the ordering. Decide what you want to be holding when it ends, then pick the route that produces it. Doing it the other way round, picking a route and discovering the handover afterwards, is how a working demo becomes a system nobody can change.