If you run a company of 20 or 200 people and you want an AI agent or an automated workflow, the first question is rarely "which model?". It is "who builds this, and how do I know they are any good?" Here is how we would think about it if we were on your side of the table.
Start with the job, not the title
"AI developer" covers very different people. One builds a chatbot on top of your documents. Another wires your CRM, your inbox and your invoicing tool together so nobody retypes data. A third trains models from scratch, which almost no SME needs.
Before you post a job or send a brief, write one paragraph: what happens today, who does it, how long it takes, and what "done" looks like. If you cannot describe the task in a paragraph, no developer can scope it either. That paragraph is also the best filter. People who ask good questions about it are worth talking to. People who answer with a list of buzzwords are not.
Three ways to get it built
A full-time hire. The US Bureau of Labor Statistics reports a median annual wage of $140,910 for computer and information research scientists, the closest official category to an AI engineer, and the top tenth earn above $232,120. That is before recruiting, equipment and the months it takes to find someone. It makes sense when AI is part of your product or you have a steady stream of projects. It rarely makes sense for a first project.
A freelancer. Quick to start and flexible. The risk is that one person has to be the architect, the developer, the tester and the support desk, and when they are busy or leave, nobody else knows how the system works. It suits a small, well-defined task where you already have someone technical to review the work.
A team that delivers the whole system. You pay for design, build, testing and handover as one piece, and several people know your setup. You need to check that you get the code and the accounts at the end, which we cover below.
Many companies end up mixing these: a team builds the first version, then one internal person owns it day to day. That is a healthy pattern, because the handover is planned from the start.
What the data says about building vs working with specialists
MIT's NANDA initiative studied generative AI projects in companies. As reported by Fortune, tools bought from specialised vendors and partnerships succeeded about 67% of the time, while internal builds succeeded only one-third as often. The report does not mean in-house teams are bad. It suggests that experience with a specific kind of problem matters more than the job title of the person you hire, and that a first project built by people who have already shipped similar ones tends to go better.
Take the numbers as a direction, not a law. The sample was large companies, and "success" had a narrow definition. For a smaller business the lesson is simpler: ask for evidence that they have built this kind of thing before.
Questions to ask before you sign
- Can I see something you built that is running today? A demo video is fine. A client who will take a call is better. Ask what broke in the first month and how it was fixed.
- Who owns the code, the data and the accounts? The answer you want: the system runs in your cloud account, with your API keys, and you get the repository. If the developer hosts everything on their own accounts, you are renting, and leaving later means rebuilding. We wrote about this in why your automation should run on accounts you control.
- What happens when the AI is wrong? A good answer includes limits, human approval for risky actions, and logs you can read. "It rarely makes mistakes" is not an answer.
- How will we know it works? Agree on one number before work starts: minutes saved per ticket, share of questions answered without a human, errors per month. Without it, "it works" becomes an opinion.
- Who maintains it after launch? Models, APIs and your own processes all change. Ask what support looks like and whether a short handover session for your team is included.
Mistakes we see most often
Hiring for the tool, not the problem. A developer who is an expert in one framework will propose that framework. Sometimes a plain workflow does the job and an AI agent would only add cost and risk. We lay out the difference in AI agents vs. workflow automation.
Starting too big. The first project should take weeks, not a year, and touch one process. A narrow win teaches you how your data really looks and builds trust inside the company.
Skipping the data check. An agent that answers from your documents is only as good as those documents. If your price list lives in three conflicting spreadsheets, fix that first. Any developer worth hiring will look at your data before quoting.
Judging by the slide deck. Polished proposals are cheap to make. Ask the developer to walk you through how they would build your first workflow, step by step, including what could go wrong.
A simple way to start
Pick one repetitive process that costs your team real hours each week. Write the one-paragraph description. Then talk to two or three candidates, whichever model you prefer, and compare them on the five questions above rather than on price or tool names. Pay attention to who pushes back on your idea with a reason: that person has seen it fail before.
If you would like a second opinion on the paragraph, or on a proposal you already received, we are happy to read it on a free 30-minute call. You can also see how we staff projects on our AI engineers page, or browse real systems we built to judge the standard for yourself.
