How to Hire an AI Automation Developer: Questions, Red Flags and What It Should Cost

Most businesses that want "an AI developer" actually want one expensive, repetitive job to stop eating somebody's week. The Monday report. The intake form that gets retyped into the CRM. The quote that takes an hour to assemble from three spreadsheets. That job is the thing you are hiring for, and the best way to hire well is to keep it at the centre of every conversation.

This guide is written from the other side of the table. I build these systems, and these are the questions I would want a buyer to ask me, the answers that should worry you, and the prices I publish for this kind of work.

Describe the job, not the technology

Before you talk to anyone, write half a page about the work as it happens today:

• Who does it, and roughly how many hours a week it takes them.
• What starts it: an email arriving, a form submitted, a day of the week.
• What they look at to do it: which systems, documents and spreadsheets.
• What "done" looks like: the record updated, the email sent, the report delivered.
• The awkward cases: missing information, two sources that disagree, the customer who wants an exception.

Then collect five to ten real examples, redacted if necessary. Include at least one that should be escalated to a person and one that should result in no action at all. A developer who asks for these is investigating your business. A developer who does not ask for them is about to build a demo.

Notice that none of this mentions a model, an agent or a framework. "We need an agent" leaves every important decision unspoken. "We retype 40 intake forms a week into HubSpot and get about one in ten wrong" gives a developer something to measure.

Work out which kind of project it is

"AI automation" covers three quite different kinds of build, and the right developer differs between them:

| If the job is… | It is mostly… | Ask about… | |---|---|---| | Moving information between systems with some judgement in the middle (triage, extraction, follow-ups) | Workflow automation | Completion checks, permissions, retries, what happens when it fails | | Answering questions from your own documents | Document search / RAG | Source quality, access control, how answer quality is measured | | A tool your team logs into every day (a quoting system, a reporting dashboard, a CRM assistant) | An internal application | Accounts, roles, hosting, who maintains it |

Be open to the answer that part of the job does not need AI at all. If the steps follow fixed rules, an ordinary script or a Zapier flow may be cheaper and more reliable. A good developer will say so, even when it shrinks the project.

What it should cost

Freelance AI work is often quoted by the hour, which leaves the buyer carrying all the risk of a slow build. AI tooling has changed the economics: a competent developer who builds with AI can deliver the same result in far fewer hours than a few years ago. You should be paying for the outcome, not for the hours the old way would have taken.

These are the fixed prices I publish on my pricing page, as a reference point:

| Package | Price | What you get | |---|---|---| | AI Workflow Audit | $299 | 3–5 automation opportunities in your business, ranked by hours saved against cost to build, with a plan for each | | AI Automation Sprint | $1,500 – $3,000 | One repetitive workflow automated end to end in 7 days | | Internal AI Tool | $3,000 – $8,000 | A custom dashboard, chatbot, document processor, quoting or reporting tool | | AI Maintenance | $300 – $1,000 / month | Monitoring, fixes when an API or model changes, and small improvements |

Two things should always be separate in any quote you receive:

1. The build price. Fixed, or at least capped, and tied to a result you can check.
2. Running costs. Model usage, hosting and any paid software the tool depends on. These are ongoing, billed at cost, and should come with an estimate and a hard spending cap. Ask what happens when the cap is reached: the right answer is that the tool stops and tells someone, not that it quietly keeps spending.

A quick way to check whether a build is worth it: multiply the hours the job takes each week by what those hours cost. Five hours a week at $30 an hour is about $7,800 a year. A $2,000 automation that removes most of that pays for itself in a few months. If the arithmetic does not work, do not build it, whoever you hire.

Questions for the first call

A first call should leave both sides understanding the job better. Useful questions to ask:

1. "What would you need to see before quoting?" Good answer: examples, access to the systems involved, the volume. Bad answer: a price before they have seen anything.
2. "How will we know it did the job correctly?" Good answer: a concrete check, such as the record exists in the CRM with these fields, or the totals match the source. Bad answer: "the model is very accurate."
3. "What will it be allowed to do without a person approving it?" Good answer: a list of actions, with anything irreversible (sending, paying, deleting) behind an approval step at first.
4. "What happens when it fails at 3am?" Good answer: it stops, logs what happened and alerts someone, without retrying forever.
5. "What will I own at the end?" Good answer: the code, the accounts, documentation, and a way for another developer to take over.
6. "What is the smallest version worth building first?" Good answer: one workflow, one team, a result you can compare with how the work is done today.

Listen for how clearly they separate what they know from what they still need to find out. Estimates made before seeing the source systems are provisional, and an honest developer will say so.

Red flags

Walk away, or at least slow down, if you hear these:

• A price before any questions. Either the project is being padded to cover the unknowns, or the unknowns will become change requests later.
• Demos instead of evidence. A slick demo on made-up data proves the developer can make a demo. Ask to see something running on real work, and ask what it cannot do.
• No mention of failure. Every automation fails eventually: an API changes, a document arrives in a new format. If failure handling is not in the plan, it will be your problem.
• "Fully autonomous" from day one. Sensible projects start with the system preparing work and a person approving it, then remove the approval once the error rate is known.
• Accounts in their name. Production accounts, API keys and hosting should be under your control, with the developer given access.
• Open-ended hourly billing for a defined job. Hourly work makes sense for exploration. For "automate this workflow", a fixed price or a cap is reasonable to ask for.

Scope the first project so you can judge it

The best first project is small enough to finish and complete enough to use. For an inbox workflow, that might mean the system sorts and drafts replies for a week while nobody sends anything automatically. Your team compares the drafts with what they would have written, corrects them, and you measure whether it actually saved time.

Agree the acceptance criteria in writing before the build starts, in plain words. "Every intake form arrives in the CRM within five minutes with all required fields, and anything it cannot parse lands in a review queue" can be checked. "The system handles intake intelligently" cannot.

Also agree what would make you stop. If the source data turns out to be unreliable, that is a useful finding, and a good project plan allows for it.

What you should receive at handover

• The source code in a repository you own.
• Every account (hosting, model provider, integrations) in your name.
• A short runbook: what runs, when, what it touches, how to pause it, who gets alerted.
• The test examples used to check it, so a future change can be checked the same way.
• A clear statement of running costs so far, against the estimate.

A short checklist for your shortlist

• Did they ask about the job before the technology?
• Did they ask for real examples, including awkward ones?
• Did they suggest a simpler option where AI is not needed?
• Is the price fixed or capped, and separate from running costs?
• Is there a concrete check for "done", and a plan for failure?
• Are irreversible actions behind an approval step?
• Will you own the code and every account?

If you want a second opinion on a workflow you are thinking of automating, the $299 AI Workflow Audit is designed for exactly that: a plan you can hand to me, another developer or your own team. You can also build a project brief for free, or look at the work I have shipped first.