How to hire an AI developer: 12 questions to ask before you sign

If you want to hire an AI developer and you're not technical yourself, the hardest part isn't finding one. There are plenty. The hard part is telling the difference between someone who builds real systems and someone who wraps a template in a nice demo and moves on.

You don't need to read code to tell them apart. You need to ask the right questions and listen to how people answer. Good developers are specific. They talk about your business before they talk about tools, and they're happy to tell you what could go wrong.

Look at shipped work, not demos

A demo proves that something worked once, on the input the builder chose. That's the easy part now. What you want is evidence that someone has put a system in front of real users and kept it running.

goLance's hiring guide makes the same point. Its signals of a qualified AI developer start with verifiable past work (shipped projects, live URLs, code you can inspect) and specific answers about process and trade-offs, with vague generalities flagged as a warning sign. The same guide adds a line I'd underline: if they don't talk about how they validated that the model worked, the model probably doesn't work.

It's a fair test to apply to me too. The thing I'd point you to is SubTrada, a procurement platform for UK construction that I built end to end, with Claude doing drawing reviews, metadata extraction from bulk uploads and quantity takeoff.

Write down what you need first

Before you talk to anyone, write a page on the problem you want solved. Not the technology, the problem: what happens today, who does it, how often, and what "better" would look like.

A freelancer on Hacker News who takes over abandoned and failed projects puts clear requirements first on their list, and says the lack of them, combined with open-ended payment terms, leads to failure "almost every time". A good developer will help you sharpen that page. A poor one will skip straight to quoting.

12 questions to ask an AI developer before you sign

Ask these on a call, not by email. You're listening for specifics, and for whether they're comfortable saying "it depends, and here's on what".

1. Can you show me something you've shipped that I can use or inspect? A good answer is a live product, a real system walked through on screen, or code, not a slide deck or a screen recording of a demo.
2. Can I speak to someone you've built for? A good answer is a name and an introduction, and they don't mind you asking what went wrong as well as what went right.
3. What do you need to know about my business before you can quote? A good answer is a list of questions about your process, volumes and people, and a suggestion to spend time on discovery before any price is fixed.
4. Do we actually need AI for this? A good answer is honest, including "a simple automation or an off-the-shelf tool would do most of this" when that's true.
5. How will we know it works? A good answer describes a set of real test cases, including the messy ones, agreed with you before the build, with a pass mark that decides when it's ready.
6. What happens when it's wrong? A good answer names the checks, the human review step, how it escalates, and the actions it will never take on its own.
7. What will it cost to run each month? A good answer is an estimate per task based on expected volume, covering model fees, hosting and monitoring, plus spending limits and alerts.
8. Who owns the code, the prompts and the accounts? A good answer is "you do": the code in your repository, the prompts documented, and the AI and hosting accounts in your company's name.
9. How is our data handled? A good answer says which providers will see your data, what their retention and training terms are, and how access is limited to what the system needs.
10. How will you break the work into milestones? A good answer is a short list of deliverables, each with a clear definition of done, a date and a payment attached.
11. What happens after launch? A good answer covers who fixes things, how quickly, what that costs, and what documentation you'll have if they're unavailable.
12. How will we stay in touch while you build? A good answer is a regular update rhythm, a working test version you can try at any time, and replies within a working day.

You won't get perfect answers to all twelve from anyone. What you're watching for is whether the answers get more specific as you push, or vaguer.

Red flags when you hire an AI developer

• Vague answers to direct questions. Especially on questions 5, 6 and 7. If they can't explain how they'll test it, what happens when it fails, or roughly what it costs to run, they probably haven't had to.
• No discovery phase. A fixed price after one short call means they're quoting a template, not your problem.
• Hourly billing with no deliverables. Hourly work is fine for open-ended exploration. For a build, it moves all the risk onto you.
• Everything in their accounts. If the code, the API keys and the hosting all live with them, you're renting your own system.
• Only talking about tools. The HN freelancer's advice is to watch whether developers ask about your business or just talk about their stack. You want the first kind.

Pay against milestones, not hours

The same Hacker News advice is blunt about this: don't sign a contract with hourly charges, or a deposit up front with the rest at the end. Tie payment to specific deliverables, agree what "done" means for each one before you sign, and pay promptly when you approve them.

For a sense of market rates, goLance's rate guide shows freelance AI developers on its platform charging anywhere from $40 to $350 an hour, with mid-level developers averaging around $93 and senior ones around $160. Rates vary widely by source, region and specialism, so treat that as a rough guide. A higher rate on fixed milestones is often cheaper than a lower rate on an open-ended clock.

If you want to sanity-check the running costs separately, I've written about what it costs to build and run an AI agent.

Get IP and confidentiality in writing

Before any work starts, you want a short written agreement that covers:

• Ownership. You own the code, prompts, configuration and documentation once each milestone is paid for.
• Confidentiality. An NDA, or a confidentiality clause, covering your data and your business information.
• Access. Accounts created in your name, with the developer invited in, so you can remove access at any time.
• Handover. What you receive at the end: repository access, documentation, and a walkthrough.

Have a lawyer look over anything significant. But don't expect the contract to do the work. As that HN freelancer points out, no contract can make someone deliver code they can't write. Clear requirements and milestone payments protect you far more than clever clauses.

The question behind all twelve

Most of these questions are really asking the same thing: will this still work, and will someone understand it, three months after launch? That's where most AI projects go wrong, which I've written about in Most AI projects don't fail during the build.

Print the twelve questions, take notes on each answer, and compare candidates side by side. The one with the most specific answers is usually the right choice, even if they're not the cheapest.