How to Hire an AI Developer: A Practical Buyer’s Checklist

Hiring an AI developer is easier when you can describe the work you want done without naming a model. “We spend every Monday assembling the same client report” is a more useful starting point than “we need an agent.” The first description gives a developer something to investigate. The second leaves the important decisions unspoken.

I build AI integrations, independent applications, and automation systems. The questions below are the ones I would want a buyer to ask me. They are intended to help you choose a developer and agree a project you can evaluate, even if you do not write code yourself.

Start with the outcome and the current process

Write down who does the work today, what starts it, what information they use, and what a correct result looks like. Include the awkward cases. A support workflow might look straightforward until an order is missing, a customer requests an exception, or two documents disagree about the policy.

Bring a small collection of representative examples to the first conversation. Redacted messages, a sample report, or a recording of the current process can be enough. Include at least one example that should be escalated to a person and one that should produce no action. Those examples reveal whether a developer understands the business decision or is only designing a convincing interface.

Then agree how you would recognize improvement. It might be less time spent gathering information, fewer incomplete records, or faster preparation of a response. Avoid treating a hypothetical calculation as a measured saving. A pilot should establish what happens on your work, with your team reviewing the output.

Identify which kind of developer you need

An AI project may primarily be an application project, an information-retrieval project, or an automation project. Those overlap, but the most important engineering questions differ.

For an existing product that needs summarization or structured extraction, look for LLM integration experience. The developer needs to understand the application's authentication, validation, user interface, and failure behavior, as well as the model request.

For an assistant that answers questions from company documents, look at RAG and document search. Ask about source quality, updates, deletion, access permissions, and how retrieval quality will be measured. A database full of embeddings is not the same thing as a useful search product.

For work that should move through multiple steps, look at AI workflow automation. The key questions concern completion checks, permissions, retry limits, and escalation. If the work follows fixed rules, an ordinary script may be the appropriate implementation.

For a complete new application, you also need product engineering. The login, billing behavior, navigation, and release process do not disappear because one feature uses AI. You may need web development or native iOS development alongside the model integration.

Ask to see something you can inspect

A screenshot shows that someone produced a screenshot. A live application, a walkthrough of its important flows, and an explanation of the failure cases provide more useful evidence.

Ask what the developer personally built. Ask which parts use a model and which are ordinary application code. Ask what the system cannot do. A clear answer about a limitation is often more informative than another list of supported frameworks.

For example, my AI Operations Lab separates a fictional, prewritten example from live analysis using a visitor's key. It checks that supporting quotes occur in their stated source, but that does not prove the source is true. It prepares drafts but cannot send them. Those boundaries are part of the demonstration, not footnotes to discover later.

Similarly, my ai-os case study describes an independent work control plane and its completion checks. It is evidence of a particular implementation approach. It is not evidence that every business would save the same amount of time by using an agent.

Use the first call to test the developer's questions

A productive first call should help both sides understand the situation. You should expect questions about the inputs, the volume, the acceptable error rate, the people involved, and the systems the work touches.

The developer should distinguish what is known from what needs investigation. If the project depends on a third-party API, access restrictions, or difficult source documents, those are dependencies to resolve. A delivery estimate made before understanding them should be treated as provisional.

It is also reasonable for a developer to recommend a smaller first step. The right answer may be a bounded assessment, a simpler workflow, or an improvement to the source data. A useful partner can explain why those choices serve the outcome you described.

You do not need a perfectly written specification before talking. You do need a shared description of the first result you are paying to reach. Ask the developer to explain it back to you without hiding behind product names or technical vocabulary.

Ask how the result will be checked

The most useful question in an AI project is often: “How will we know this is correct?” The answer should involve more than the model reporting confidence.

For extraction, the application might check required fields, permitted values, source passages, and whether the result fits the business rules. For a document assistant, the evaluation might inspect whether the retrieved source supports the answer and whether an inaccessible document stays inaccessible. For an action-taking workflow, the check might be a record in the target system or a verified change in state.

These are different checks for different problems. Ask to see a few concrete examples before the project begins. Include missing information, contradictory information, malformed requests, and messages that try to instruct the AI to ignore its purpose.

Not every check can prove correctness automatically. A recommendation may still require a person to assess the context. The important distinction is between what the system verifies and what the human is expected to review. Both should be visible in the product and the project plan.

Discuss permissions before connecting accounts

An assistant that reads a customer record has a different responsibility from one that changes it. Drafting an email is different from sending it. Preparing a refund is different from issuing it.

Ask for a list of actions the system will be allowed to perform and how each permission is enforced. The application should authenticate the user and authorize the action. A sentence generated by a model should not grant access to an account or bypass a normal approval rule.

For an initial pilot, read-only access or draft-only output is often enough to evaluate usefulness. If a later stage adds actions, agree the approval path, what will be recorded, and how a failed or duplicated action will be handled.

You can read more about this part of my work in AI guardrails and audit. The practical purpose is to make the system's reach understandable before it is connected to anything important.

Separate the build price from operating costs

A project quote should explain what is included in implementation and what you will pay to operate the system. Depending on the product, ongoing costs can include model calls, hosting, document processing, retrieval infrastructure, monitoring, and maintenance.

Ask what usage drives the estimate. A short classification task and a long document analysis have different consumption patterns. Retries, background jobs, and user volume can change the total even if the interface looks the same.

Ask how usage will be measured and bounded. Is there a per-request output cap? Can a user trigger repeated requests? What happens when the provider rejects a request or the budget is exhausted? Can a retry duplicate a billable action elsewhere?

These questions do not require you to memorize model pricing. They require the implementation to make costs observable and to avoid promising an operating figure that has not been tested against representative usage.

Scope a pilot you can finish and evaluate

A useful first pilot has one workflow, representative inputs, an agreed output, and a person responsible for reviewing it. It should be small enough to understand, while complete enough to test the business assumption.

For an inbox workflow, the pilot might prepare a prioritized queue and response drafts without sending anything. Your team can compare the drafts with its normal process, record corrections, and see whether preparation actually reduces handling time. Connecting a CRM and automatically taking action can be a later decision.

Agree the acceptance criteria before evaluating the result. Otherwise, an attractive demonstration can replace the original goal. “The team can inspect the source behind each draft and export reviewed work” is more testable than “the system feels intelligent.”

Also agree the conditions for stopping or changing direction. If the underlying documents are unreliable or every case requires a different judgment, that finding is useful. A pilot should be allowed to show that the initial approach needs revision.

Know what you should receive at handoff

The final deliverable should be more than a hosted link. Ask where the source code lives, who owns the service accounts, how configuration is documented, and what is needed to deploy a new version.

For an AI integration, you should also understand which model is used, where prompts and evaluation examples are maintained, what limits apply, and how a provider change would be tested. For an automation, ask for the schedule, permission map, failure notifications, and runbook.

Ownership should not be ambiguous. Production accounts should be under your control, with the developer receiving the access required for the engagement. A handoff should allow another competent engineer to understand the system without depending on private knowledge or an account only the original developer controls.

Maintenance is a separate conversation worth having before launch. Decide who receives alerts, who reviews recurring errors, and what happens when an upstream service changes. Even a small product needs someone who notices when its assumptions stop holding.

A checklist for your shortlist

Before choosing a developer, look for clear answers to these questions:

• Can they describe your desired outcome without repeating a tool name?
• Have they shown work you can inspect and explained their own contribution?
• Can they identify a simpler alternative when AI is unnecessary?
• Have they proposed representative acceptance checks and failure cases?
• Are data access, action permissions, and human review explicit?
• Are implementation costs separated from operating assumptions?
• Is the first scope small enough to evaluate but complete enough to use?
• Will you control the code, accounts, and information needed for maintenance?

The answers matter more than a long list of fashionable frameworks. Good engineering should make the project easier to understand and its result easier to assess.

If you want to discuss a specific workflow, contact me with a short description and a redacted example. You can also explore the services or try the Operations Lab to see how I present evidence, review, and operating boundaries in a working interface.