You have decided you want something built: the phone intake, the invoice pipeline, the assistant that reads the inbox. Now you need someone to build it, and every firm you talk to says “AI” in the first sentence and something different in the second. One wants a monthly retainer. One has a platform. One will not give a price until you have had three calls. You cannot tell who is good, and the wrong choice costs more than money; it costs a year and the goodwill of your staff.
This article is how to hire an AI consultant, and it is written by one. That is a conflict of interest, so here is the deal: everything below is a test you can put to any firm, including this one, and if a firm fails it, walk. We would rather lose a project to a good competitor than have you hire badly. By the end you will have the questions, the red flags, what a good scope looks like, the ownership terms that matter, and how to run a first project small enough to survive being wrong.
What hiring an AI consultant actually involves
Hiring an AI consultant is hiring a contractor to build something in your building. You would not hire a builder who would not show you a plan, would not say what it costs, wanted to own the extension afterwards, and charged you rent on it. You would want to see their work, talk to the people who live in it, and start with the small job before the big one.
The AI part changes less than the sales pitches suggest. The work is still: understand the process, design the system, build it, test it, hand it over with documentation, and support it. What is new is that a lot of firms are selling the word rather than the work, and some of the lock-in traps are new.
1. Ask what they built last, go and look, and talk to who uses it
Ask for two or three things they have built that are running today, and ask to see them. Not a slide, not a demo environment; the real thing, a recording of it, or a call with someone who uses it. A firm that has built things can show you things. A firm with “deep expertise across the AI field” and nothing to click on is a marketing firm.
While you look, ask what went wrong. Every real project has a part that did not work the first time. A consultant who tells you the story of the integration that broke, and what they changed, is telling you something true. One who says every project went smoothly is either new or not telling you.
References are still the best signal. Ask for two clients from the last year and ask them: did it get finished, is it still running, what broke, would you hire them again, and what would you tell me to watch for. The last question gets the honest answer. A consultant with no references yet is not disqualified, but the other tests weigh more.
2. Ask them to explain it to you until you understand it
A good consultant can explain what they are going to build, why, and how it will fail, in plain words, to someone who does not know the field. You need that to judge it, and a person who cannot explain a thing plainly usually does not fully understand it.
If every answer contains three acronyms and “it’s complicated”, or questions are deflected to “trust the process”, stop. Read What Is an LLM? A Plain Explanation for Business Owners and AI Glossary for Business Owners, 45 Terms in Plain English before the meetings and you will be able to tell fluent from evasive. Ask specifically: what does this system do when it is not sure. The answer should include a person, a queue, and a log. “The AI handles it” means it will embarrass you.
3. Insist on a written scope before a price
A scope is a document that says what will be built, what it will not do, what it needs from you, how you will both know it is done, and what it costs. It should be specific enough that two different developers reading it would build roughly the same thing, and it should name the systems it connects to, the accounts it runs in, and the acceptance tests (the checks you will run together to agree the work is finished).
No scope, no project. A consultant who wants to start on a retainer “to figure out what you need” is asking you to pay for their sales process. A short paid discovery phase with a written scope as its deliverable is legitimate; an open-ended retainer is not.
Read the “will not do” section hardest. A good scope has one, and it is honest: “the system will not process handwritten forms”, “the phone agent will not quote prices”. A scope with no exclusions has not been thought through, and the arguments will happen later, on your money.
4. Understand the pricing model and what it does to their incentives
There are three common models. Fixed price from a scope: you know the cost, the overrun risk is theirs, and it depends entirely on the scope being good. Time and materials: you pay for hours, fair for genuinely uncertain work and dangerous for anything you cannot see, because the incentive is to take longer. Retainer: a monthly fee, sensible for support after something is running, questionable before.
Our view is that a fixed price from a written scope is the fairest model for a defined first project, with ongoing support as a separate, smaller, clearly described arrangement. Whatever the model, you should be able to see what was done for what was charged. Why fixed prices have become realistic for small custom builds is covered in The Cost of Custom Software in 2026 After Agentic Coding. Be suspicious of a fourth model: pay-per-seat or pay-per-use on your own automations. A firm that charges you monthly per user or per run of a thing in their account has not built you something. They have rented you something and called it consulting.
5. Own everything, in your own accounts
At the end of the project you should own the code, the prompts, the configuration, the documentation, and the data, and all of it should run in accounts you control: your cloud account, your model provider account, your automation platform, your domain. The consultant has access while they are working and loses it when you say so. If they disappear tomorrow, another developer can pick it up.
Ask directly: whose accounts does this run in, and can I take it somewhere else. If the answer involves “our platform”, ask what happens to your workflows if you stop paying. If they stop working, you are being sold a subscription with a setup fee. That can be a fine product; it is not consulting, and the price should reflect that you own nothing. Put ownership in the contract in plain words: all deliverables are your property on payment.
6. Check for the three things that separate real systems from demos
Every AI system that is fit to run a business process has three things. Logs: a record of every input, output and action, so that when something goes wrong you can see what happened. Tests: a fixed set of example inputs with known correct outputs, run before every change. A human path: a defined place where the cases the system cannot handle go, and a person who works it.
Ask for these by name. Ask to see the logs of a system they built, what their test set looked like, and where the exceptions go. A firm that builds all three will answer in detail, because it is most of the work. A firm that does not will talk about the model. What a bad AI project looks like is in AI Mistakes Businesses Make, the Ten Ways Money Gets Wasted.
7. Ask about the boring parts: data, security, and what happens after
Ask where your data goes, which third-party providers see it, under what terms, and what is done to reduce what is sent (the questions are in AI Data Privacy for Business, What Happens to Customer Data). Ask how the system is kept from doing something it should not: what it may do without a person, and how you switch it off.
Then ask what happens after launch. The provider will retire the model version you built on within a year or two, and the systems you connect to will change. Who watches for that, who fixes it, what does it cost. A good answer is a written support arrangement with a response time and a monthly cost, and documentation good enough that someone else could do it. A bad answer is “we’ll be here”.
8. Run the first project small enough to survive being wrong
Do not start with the whole vision. Pick one process, with one internal owner, one measure of success, and a scope that can be built in weeks not months: the inbox triage, invoice extraction for one document type, after-hours phone intake. Enough to be useful; small enough that if the consultant is wrong for you, you have lost a modest sum and learned something.
Judge the first project on process as much as result. Did they communicate. Did the scope hold. Did they show you the logs. Did they say no to something. A consultant who behaved well on the small project will behave well on the large one. The month-by-month plan is in AI Roadmap for Small Business: 90 Days Without a Developer.
Picture a business like this one
The business below is a composite of the kind of company that writes to us, not a client. The numbers describe the shape of the problem, not a case study.
Picture a business like this one: a property management company with fifteen staff and four hundred units, drowning in maintenance requests by email and phone. The owner talked to three firms. The first proposed a “custom AI platform” on a monthly retainer, no scope, ownership unclear. The second proposed building the workflows in their own automation account and charging per unit per month. The third produced, after a paid two-hour discovery session, a four-page scope for one thing: classify incoming maintenance requests, extract the unit, the issue and the urgency, create the ticket in the existing system, and route emergencies to the on-call phone, everything else to a review queue. Fixed price, six weeks, the company’s accounts, acceptance tests and exclusions listed (no phone calls in phase one, no automated replies to tenants), support quoted separately.
An owner in this position should hire the third firm, and not because the price was lowest (it was not). The scope told them what they were buying. The exclusions told them the firm had thought about it. The accounts told them they would own it. The size told them that if it went wrong, it would go wrong small.
What changes after six weeks, if it goes well: the office works a review queue instead of an inbox, emergencies reach the on-call phone in a minute, and the owner has logs showing every request and how it was classified. If it goes badly, the owner has a four-page scope to hold the firm to and a modest sum at risk.
What it costs to run
The running costs are the ones the consultant should be putting in front of you, itemised, before you sign. For most business AI systems they are: model usage (typically tens to low hundreds of dollars a month, billed by the provider to your account), an automation platform or a small server ($10 to $60 a month), storage and email sending (a few dollars), and any SaaS the system depends on.
Then the support arrangement, which is the one people forget: a modest fixed monthly fee or a bank of hours, with a stated response time. If a proposal has no running-cost section and no post-launch line, it is incomplete; ask for both before comparing it to any other.
The mistakes we see most
- Buying the demo. It ran on the consultant’s clean data. Ask to test on yours before signing.
- Retainer before scope. Paying monthly to discover what you want.
- Running in their accounts. The day you stop paying, the workflows stop.
- No exclusions in the scope. Everything was implied; nothing was agreed; the arguments came later.
- No logs, no tests, no human path. It worked in the demo. Nobody can say why it stopped.
- Starting with the whole vision. Six months, one big invoice, and a system nobody owns internally.
When to bring in help
Some of what you want does not need a consultant at all. If a single off-the-shelf tool does the job, a capable person on your staff with a weekend and a subscription can set it up; the decision rules are in Build vs Buy AI Tools for Your Business, the Decision Rules. A consultant is worth paying when the work crosses systems, touches money or customers, needs logs and tests and a human path, or has to be maintained by someone other than the person who built it.
When you do hire, use every test above on everyone, including Levelbrook. We build web apps, automations and AI systems for businesses, at a fixed price from a written scope with exclusions and acceptance tests, running in accounts you own, with logs, tests and a human path in every system, and a separate, written support option. If we cannot show you those things, do not hire us either. The form below is how a conversation starts.