This guide is written to be useful even if you end up hiring someone else. That is deliberate. The questions below work on any provider, in any category, and a company confident in its own work will not mind being asked them.
The five kinds of AI provider, and what each is good for
Every provider in this space fits roughly one of five shapes. None of them is universally right — the fit depends on the workflow, the budget, and how much you want to own afterward.
Freelancer or independent contractor
A single person, often technically strong, working directly with you rather than through account managers. Good for a narrowly scoped build, a fast prototype, or ongoing work on a system that already exists and just needs a capable pair of hands. The risk is concentration: if that one person is unavailable, sick, or moves on, the project stalls, and few freelancers can absorb a build that spans several systems and a real evaluation process on their own.
Boutique studio
A small team, usually five to twenty people, that takes on a handful of clients at a time and tends to work directly with the engineers rather than through layers of account management. Good for a business that wants a custom system, wants to talk to the people actually building it, and does not need the scale of a large consultancy. The risk is capacity — a studio with three projects in flight has less room to absorb your fourth than its sales conversation might suggest, so it is worth asking directly who on the team would be assigned to you.
Large consultancy
A firm with deep benches, formal methodology, and the ability to staff a large, multi-team build. Good for enterprise-scale projects that need to touch many systems at once, need procurement and compliance processes a smaller firm cannot support, or need a name that a large buying committee will recognize. The trade-off is usually distance: the person who sold you the project is rarely the person who builds it, pricing tends to scale with headcount rather than outcome, and smaller engagements can get less senior attention than the pitch implied.
Platform or reseller
A company built around a specific no-code or low-code AI platform, configuring it for you rather than writing custom software. Good — genuinely good — for a narrow, self-contained task with a forgiving failure mode, where speed and low cost matter more than depth of integration or control over edge cases. The limit shows up predictably: the platform supports the systems it supports, you cannot always define exactly what happens when the system is unsure, and the logic that encodes how your business makes decisions ends up living on somebody else's roadmap rather than yours.
In-house hire
Hiring an engineer or a small team directly, rather than working with any outside provider at all. Good when the need is ongoing and central enough to justify a full-time role, and when you have someone in-house who can manage and evaluate that person's work. The cost is usually higher than it looks on a salary line once you add management time, tooling, and the fact that one person cannot always cover for another when something breaks — and it is a slow way to get a first system built, since hiring and onboarding take longer than most agency engagements.
None of these is a trick answer disguised as a real one. Before you evaluate providers at all, it is worth checking whether the workflow you have in mind is even ready to be automated — the AI readiness checklist is a fast way to find that out, and the first AI project guide covers how to pick the right first project regardless of who ends up building it.
Questions to ask on the first call
A short conversation tells you more than a glossy deck. These six questions are hard to fake an answer to, and the way a provider answers them matters more than the answer itself.
Who will actually write this? Ask for the name or the role of the person doing the build, not just the person on the call. A provider that cannot tell you who will touch the code, or answers with "our team" and nothing more specific, may be planning to route the work to a subcontractor you will never meet.
What happens when it gets something wrong? Every system built on top of a model gets things wrong sometimes. A provider with real experience has a ready answer involving logging, approval rules for anything consequential, and a defined path to a human. A provider without one will talk about accuracy in the abstract and change the subject.
What do you do about evaluation? Before anything goes live, has this provider tested it against real historical cases and compared the results to what actually happened? This is the question that separates a provider who ships and hopes from one who ships and knows. If the answer is vague, that is worth noting.
What happens after launch? Ask directly whether the relationship ends at go-live or continues. Systems that touch live data and changing business rules degrade quietly without attention. A provider should be able to describe what monitoring looks like and what a typical month after launch involves, not just what the build phase involves.
Who owns the code? You want a straight answer, in writing, before you sign anything. Some providers retain ownership or license terms that make leaving expensive later. This single question can save you from the most common regret buyers report after the fact — discovering after launch that switching providers means starting over.
Can we see how you handle failure cases? Ask for an example — anonymized if it has to be — of something that went wrong on a past project and what the provider did about it. A company that has a real, specific story is more trustworthy than one that claims nothing has ever gone wrong. Nothing going wrong, ever, is not a credible claim from anyone who has shipped real systems.
A provider worth hiring can usually describe its own process in a sentence. Ours is Discover, Design, Build, Run — yours does not have to look like that, but it should exist, it should be nameable on the spot, and it should include a stage where you find out the price before any build work starts.
Red flags that show up before you have paid anything
Some warning signs are visible in the first conversation, well before a contract is on the table.
- Guaranteed outcomes. "This will cut your response time by half" or "you'll see ROI in 60 days" said before anyone has looked at your actual workflow is not confidence, it is a sales script. No one can honestly promise a specific result before doing discovery.
- No discovery before a quote. If a provider gives you a number before spending real time understanding what you do today, that number is not a scope, it is a guess — and guesses tend to grow once the real work starts.
- Vagueness about what is custom versus a wrapper around someone else's platform. There is nothing wrong with building on top of an existing platform when that is the right tool for the job. There is something wrong with a provider who will not say plainly whether that is what is happening, because the distance between "we build custom software" and "we configure a third-party tool" changes what you actually end up owning.
- No mention of maintenance. If the entire conversation is about the build and nothing is said about what happens in month two, ask. A system with no plan for monitoring or updates is a system that will quietly drift out of date.
- Pressure to sign before scope is written. A provider pushing for a signature before you have a written document describing what will be built, what it will not do, and what it costs is asking you to commit to an idea rather than a plan.
None of these, on their own, should disqualify a provider automatically — but more than one in the same conversation is worth taking seriously.
How to compare proposals that are structured differently
Proposals from different providers rarely use the same units, which makes side-by-side comparison harder than it should be. A few normalizations make it fair.
Convert everything to scope, not price. A lower number attached to a vaguer scope is not cheaper — it is a smaller amount of defined work, and the gap tends to reappear later as a change order. Read each proposal for exactly what is included and what explicitly is not, and compare those lists before you compare the totals. Our own pricing page explains how we structure this on our side, for reference.
Check what "done" means in each proposal. Look for a stated way of measuring success — an error rate, a volume handled, a specific outcome — rather than a description of features. A proposal that only lists what will be built, with nothing about how you will know it works, is missing the part that actually protects you.
Look at what happens after the invoice. Some proposals include a defined support period; others treat launch as the finish line. Compare like for like by asking each provider, directly, what the weeks after go-live look like and what they cost.
Ask about data handling in the same terms for each provider. However a system is built, it will touch information you consider sensitive. Ask each provider the same direct questions about where data lives, who can see it, and what happens to it if the engagement ends — our security page is an example of what a straight answer to that question looks like in writing.
Weigh the team, not just the pitch. The person presenting the proposal is not always the person who will build the system. Ask who specifically is assigned, and hold every provider to the same standard on that question.
How to structure a first engagement to limit risk
However you choose, the structure of the first engagement matters more than the size of the provider's logo.
Keep the first scope narrow. A small, well-defined first project — one workflow, done properly — teaches you more about a provider than a long list of ambitions on a slide. It also caps your downside if the fit turns out to be wrong.
Insist on written success criteria before work starts. What does "working" mean, concretely? Agree on it in writing before the build begins, not after, so you are not negotiating the definition of success at the same time you are trying to judge whether you got it.
Make sure there is a real exit. Ask what happens if you want to stop after the first phase, who owns what at that point, and whether stopping is actually straightforward or quietly expensive. A provider comfortable with you leaving if the fit is wrong is a provider confident in the fit being right.
Treat the first project as a trial, not a marriage. A good first engagement is scoped so that, whatever you decide afterward, you have a working piece of software and a clear picture of what it would take to go further — with this provider or with someone else.