You have something that works. A prototype you assembled yourself, or a demo a technical friend put together, or a weekend of AI tooling that turned into something you can show people. It does the thing. Now it needs to become a product: something strangers can use without you in the room, that does not fall over, that an investor's technical advisor can open without wincing.
So you have decided to hire someone. That decision is the easy part.
The hard part is that you are about to choose between people you cannot evaluate. The market is full of people who talk fluently about AI without having shipped anything that survived contact with real users, and from the outside they are indistinguishable from the ones who have. If you are technical you close that gap with two or three questions. If you are not, no amount of research closes it.
This guide is not about learning to judge code. You are not going to learn that in a week and you do not need to. It is about the part of the decision you control completely: how the engagement is structured. Get that right and a bad outcome is visible in week two while it is still cheap. Get it wrong and you find out in month six, when the money is spent and you own something you cannot use.
If you are still deciding whether to hire an agency, a marketplace freelancer, or a full-time employee, that is a different question and we wrote about it separately in our comparison of the hiring paths. This guide assumes you have chosen to bring in an outside partner and are working out how to do it well.
Who owns what when the work is done
Most guides put this at the end, under a heading about exit planning. It belongs first, because it is the only item on this list that is nearly impossible to fix after the fact and free to get right at the start.
There are two kinds of ownership and only one of them shows up in contracts. Legal ownership is the contract saying the work belongs to you. Practical control is whether you can actually reach it. They come apart more often than founders expect. If the contract assigns you the code but the repository lives in the agency's organization, the servers run in the agency's cloud account, and the API keys are registered to the agency's email address, then you own something you cannot touch. Getting it back is not a lawsuit. It is a negotiation, conducted at the exact moment your relationship with that partner has gone wrong.
The fix costs nothing. Every account that exists for your product gets created in your name, with your billing details, and you add the team to it. Not the reverse. It takes an afternoon at the start of an engagement and it is close to impossible to unwind once the work has begun.
Here is the list to work through before anyone writes code:
- The source code repository, in your organization, on your billing.
- The cloud account, in your company's name, on your card. Your partner gets user access inside it.
- The domain and the DNS, in a registrar account you control.
- Model provider accounts and API keys, in your name and billed to you. This is the one founders most often let slide, because a developer already has an account and it is faster.
- Every third party service the product depends on: the database, the monitoring, the email sender, the payment processor.
- The deployment pipeline and its configuration.
- The documentation, treated as a deliverable rather than a courtesy.
That list is fairly standard and you will find versions of it in guides written for ordinary software projects. For an AI product it is incomplete, and the missing part is the part that matters most.
In a conventional application, the code is the asset. In an AI product, a large share of what you actually paid for lives outside the code entirely. The prompts that took forty iterations to get right are not code. The evaluation set that encodes what "good" means for your particular product is not code. Neither is the fine-tuned model, or the data used to produce it, or the processed content sitting in your vector database, or the accumulated traces that show how real users behave. A contract that assigns "all source code and related deliverables" to you may not clearly reach any of it.
So extend the list:
- The prompts, in version control, with their history. The history is the record of what you learned.
- The evaluation set and the tooling that runs it. This is the written definition of what your product is supposed to do, and it is worth more than most of the code.
- Any fine-tuned model or adapter, plus the training data used to produce it, plus the right to use both.
- The vector database contents and the ingestion pipeline that produced them, so the embeddings can be rebuilt rather than only inherited.
- The observability and trace data, which is your only record of how the system behaves in the wild.
Name these explicitly in the agreement. Standard software contracts predate the problem and mostly do not mention them, which means the default answer is unclear rather than favorable. None of this is legal advice, and a contract of any size deserves a lawyer, but you should walk into that conversation knowing which assets to point at.
Red flags at the quoting stage
You learn more about a potential partner from how they price the work than from anything they say about their experience.
The strongest signal is whether they ask hard questions before quoting. Anyone who gives you a confident fixed price without interrogating your prototype, your users, your data, and your quality bar is either guessing or planning to recover the difference through change requests. Both end in the same argument, four months in.
A few others worth weighing. A discovery phase longer than about two weeks usually means you are paying someone to think in a document rather than build something you can look at. A timeline where nothing at all is visible for three months means you have no way to course correct until it is expensive. An unwillingness to say what they would refuse to build is a sign of an order taker rather than a partner, and an order taker is exactly the wrong thing to hire when you cannot specify the order precisely. A price dramatically below everyone else's is not a bargain, it is a different scope that has not been explained to you yet.
Then there is the question of who actually does the work. Ask directly whether the people in the meeting are the people who will write the code. Agencies that sell with senior staff and deliver with junior staff are common enough that the question is not rude, and the reaction to it tells you as much as the answer.
On shipped work, be reasonable but firm. Confidentiality is real and a good partner will genuinely be unable to show you some of what they have built. They should still be able to describe a system's shape, the decisions they made, what broke, and what they would do differently. Someone who can only show polished slides has either not shipped or was not close enough to the work to remember it.
Milestones or hourly, and what each one costs you
There is no correct answer, only a trade you should make deliberately.
Fixed price with milestones gives you predictability and a clean exit. You know what you will spend, and if things go badly you can stop at a milestone boundary rather than negotiating your way out. The cost is rigidity. Every change becomes a commercial conversation, the vendor prices in the risk of being wrong, and you will spend energy arguing about whether something falls inside the scope. Fixed pricing also quietly requires that the work is knowable in advance.
Hourly gives you flexibility and honest pricing for work whose shape is genuinely unclear, which describes most first AI builds. The cost is that there is no ceiling and no natural checkpoint. It asks you to pay attention every week, and if you are not going to, do not choose it.
For a founder taking a prototype to production, the shape that usually works is a hybrid. Start with a small fixed price block that ends in two things: a plan you can read and something running you can see. That block is cheap enough to walk away from and it tells you more about the partner than any interview. Then move to milestones once the scope is actually known, or to hourly if it is not.
One factor specific to AI work deserves weight here. Some of what you are asking for may not be achievable at the quality bar you have in mind, and nobody knows that at the start, including the honest experts. Putting a fixed price on a question nobody can answer yet does not transfer that risk to your partner. It converts it into a dispute. Where genuine uncertainty exists, pay for the experiment that resolves it, then fix the price on the part that is now known.
Whatever the format, stage the payments against things you can see, and keep a meaningful portion tied to the end.
Agreeing what done means
Most engagements that end badly did not end badly over quality. They ended badly because nobody wrote down what finished looked like, and two reasonable people turned out to have been imagining different products.
Every milestone should answer three questions before work starts. What will I see. When will I see it. How will we both know it is done. If a milestone is called "backend integration" and the acceptance criterion is that the backend is integrated, you have written down nothing.
AI adds a wrinkle that catches nearly every first time buyer. In ordinary software, a feature works or it does not, and you can usually tell by looking. An AI feature is right a certain percentage of the time, and that percentage is a product decision, not a technical detail. "The assistant answers customer questions correctly" is not a specification. "On this set of one hundred real customer questions, the assistant gives an answer a support lead would accept at least ninety percent of the time, and never invents a policy that does not exist" is a specification, because it can be checked and it can fail.
Which means the evaluation set is the real contract. Build it early, build it together, and use real examples from your own domain rather than invented ones. It takes a day and it converts every future disagreement from an argument about impressions into a measurement. If a potential partner has no view on how the system's quality will be measured, that is the most useful red flag in this entire guide, because it usually means they have optimized for demos rather than for products.
What a good week looks like
You cannot review the code, so the rhythm of the work is your instrument.
A healthy week ends with something running that you can look at, even when the visible progress is small. Not a status report, not a percentage, not a description of work in progress. Something you can click. Alongside it, a short written summary of what moved, what did not, and what is next, plus a task list you can see without asking for it. You should also have access to the repository from day one, even though you will not read it, because the pattern of activity is legible even when the content is not.
The failure mode to watch for is several consecutive weeks of infrastructure work with nothing to show. Sometimes that is real and unavoidable. More often it means the project has drifted into building a platform rather than a product, and it is much easier to raise in week three than in month four.
Set the cadence explicitly at the start: a weekly call at a fixed time, a written update whether or not the call happens, and an agreed channel for questions during the week with an expectation about response time. This sounds like process for its own sake. It is actually the cheapest early warning system you can buy, and it is the thing you can evaluate without any technical knowledge at all.
How to interview a technical partner when you are not technical
You cannot judge whether an answer is technically correct. You can judge something almost as useful, which is whether the person can make you understand it.
The most reliable test in an interview is to keep asking follow up questions on a single topic and watch which direction the explanation moves. Someone who understands a system deeply can go simpler on demand, reaching for a comparison you already have. Someone who does not will retreat into jargon, because the jargon is all there is. Do not worry about whether you understood the first answer. Notice whether the third one was clearer than the first.
Questions worth asking, in roughly this order. Tell me about something you built that real people used, and what broke first. How would you know whether what I am asking for is working. What is the riskiest part of what I have described. What would you refuse to build for me, and why. Who exactly will write this, and can I meet them. What happens if the approach does not reach the quality bar we set.
That last question separates two kinds of answer. One kind describes a plan: how they would find out early, what they would try next, when they would tell you. The other reassures you that it will be fine. Only one of those has been through it.
When you take references, ask what went wrong on the project and how it was handled, rather than whether they were happy. Every real project has a difficult moment, and a reference who cannot recall one either was not paying attention or was not on a real project.
The vocabulary you need, and where to get it
You do not need to learn to code and nobody expects you to. You do need perhaps fifteen words, for one specific reason: without them you will nod through decisions you did not understand, and those decisions are yours.
The words worth having fall into four groups. How software gets built and shipped, which covers repository, environment, staging and production, and deployment. How the pieces talk to each other, which covers frontend and backend, API, and database. The AI specific set, which is where most of your decisions will actually live: model, prompt, context, retrieval, embedding, evaluation, hallucination, fine-tuning, and agent. And a small amount of process language, mainly sprint, backlog, and acceptance criteria.
You can pick these up in a weekend. Free glossaries are everywhere and any of them will do. The better route is to spend that weekend actually using the tools, which changes vague terms into things you have touched. We wrote a short guide on getting started with agentic AI as a non-technical person that covers the cheapest path.
The most effective thing you can do, though, is free. Ask your partner to explain each term in the context of your own product rather than in general. Not "what is retrieval" but "what is retrieval doing in my product, and what happens if it goes wrong." Someone who has thought about your system can answer that immediately. Someone who has not will give you the general definition, and you will have learned something more valuable than the definition.
The handover test
Ask one question before you sign anything: if this team disappeared next month, could another team pick this up?
You are not being pessimistic and you are not planning to leave. You are testing something else, because a team that builds for handover builds better. Documentation gets written while the reasoning is fresh. Decisions get recorded instead of living in one person's memory. Nothing depends on a single individual quietly holding the whole picture in their head.
There is a concrete version of this test you can run without any technical knowledge. Ask for the document a brand new developer would use to get the system running on their own machine, and then ask whether someone outside the team could follow it without help. A good partner has that document already, because they onboard people. A partner who has to write it for you is telling you something, and it is better to learn it in week one than in month eight.
Cover the exit in the agreement as well: a defined transition period, an obligation to support a handover, documentation named as a deliverable, and a specific timeline for transferring accounts and credentials. Agreeing this while everyone is optimistic takes ten minutes. Agreeing it once the relationship has soured takes a bargaining position you will not have.
The through line
You cannot evaluate the code. You can evaluate everything around it, and everything around it is what determines whether a problem shows up while it is still small.
Own the accounts from day one, including the prompts and evaluation sets that standard contracts forget. Judge the quote by the questions that preceded it. Choose the payment format deliberately rather than by default. Write down what done means in numbers before anyone starts. Expect something you can click every week. Interview for explanations that get simpler. Learn fifteen words. Ask whether a stranger could take it over.
None of that requires you to become technical. All of it requires you to be specific, early, while everyone still likes each other.
If it would help to know where your prototype actually stands before you hire anyone, that is what our Production Readiness Review is for. One week, fixed price of $4,500, and you get a written report plus a call covering what you have, what is missing before real users touch it, what the build will cost and how long it will take, and what an investor's technical advisor would find if they looked. If you go ahead with the build, the fee comes off the price.
See what the Production Readiness Review covers or tell us about your prototype.
