How to Hire an AI Developer: A Founder’s Practical Guide

First decide what the AI needs to do

You might want an assistant inside your SaaS, answers from company documents, or a tool that turns source information into a report. Those requests can involve different engineering work, even when every proposal says “AI development.”

In Arsum’s founder’s experience, the starting point is often software built around an existing model API. The developer connects the model to your data, interface and business process. Training a model is a separate decision.

Use this table to describe the job before comparing people:

These capabilities can overlap in one person. Ask for evidence of the part you need. A training experiment does not establish that someone can deliver your customer application; a useful application does not establish model-research experience.

Retrieval adds relevant information to a model’s context. Fine-tuning changes model weights through training. A document-search requirement does not, by itself, justify training a model. Google Cloud’s explanations of retrieval and supervised tuning describe the distinction.

Also ask whether the steps should be fixed in software or chosen by the model. Anthropic’s workflow and agent guidance makes this distinction useful: add flexibility when the task requires it. Our AI architecture guide explores the design choices in more detail.

The hiring question is straightforward: can this person explain the simplest suitable approach, what could fail, and how your product would handle it?

Ask for one working product and their part in it

The founder’s first instinct is to ask for proof of work. He wants to see “real users, real data,” with evidence that the candidate understands the system behind the interface.

Choose one relevant past project and walk through these questions:

1. What did the user need to accomplish? Ask them to demonstrate the complete journey and explain what they personally built.
2. What shows that people used it? Request a public product, a permitted demonstration, a reference or anonymized usage evidence. Respect client confidentiality.
3. What failed after the first version? Follow a specific example from the user’s problem to diagnosis and repair.
4. How did you know the repair worked? Ask to see a permitted example of a test, reviewed change or release record.
5. Who looked after it afterward? Find out what they monitored, what changed and where their responsibility ended.

Listen for clear boundaries. “I built the report interface; another engineer owned the model service” is useful evidence. A broad claim to have built everything needs a more detailed explanation.

Public buyer requests illustrate why this matters. One B2B SaaS brief asks for an existing demo to become a live product through separately reviewed phases. An AI dashboard brief combines AI integration with application and billing work. A Lovable website brief requests permissions, integrations and human review. These are three individual requests, not a market survey or pricing benchmark.

The founder does not normally start with an artificial candidate test. Where past work leaves a material question unanswered, our recommendation is an agreed, paid pilot with a narrow deliverable, spending limit and exit decision. It should produce evidence about your project. Avoid asking applicants to build the product for free.

If you cannot assess the technical explanation, bring an experienced engineer into this walkthrough. Give them your user need and the candidate’s proposed scope so they can evaluate the relevant work.

Look at how they make changes

Arsum’s founder strongly prefers developers who use AI coding tools. For him, refusing those tools is a warning sign. The useful follow-up is how the developer plans, checks and ships the resulting work.

Ask them to take one proposed feature and break it into smaller tasks. Each task should describe the expected behavior and how someone will test it. A request to “build our whole platform” is too vague to evaluate progress against.

His working rule is “one task, one commit.” A commit is a saved change in the code’s history. Small, understandable changes help a team inspect what happened and find the change to reverse when something breaks.

Ask to see how code review and automated tests fit into that process. Who checks assumptions? What happens when a test fails? How do they protect an existing feature while changing another? Reversing a code change may also require handling changed data or external actions; the developer should explain those limits.

Using an AI tool alone does not answer these questions. The hiring evidence is a controlled sequence from requirement to working change, with someone accountable for the result.

What two Arsum projects show about delivery

The founder chose Attuned Health as the strongest public example for this discussion. The Attuned Health case study describes a Shopify-connected application that brings source information, AI-assisted report preparation, practitioner review and customer access into one journey.

The hiring lesson is in that complete path. Report content is prepared in stages, assembled and reviewed. A practitioner can request regeneration and decides when the result is ready for the customer. Arsum’s work also includes the application, tests and ongoing production support.

That shows specific software responsibilities a buyer can ask about. The case study does not establish measured revenue gains or clinical outcomes.

The founder also described DreamTalk AI, an avatar-generation MVP. In his account, the system trained an existing image model using a person’s pictures. Training jobs were queued, GPU machines were started for the work and shut down afterward.

He was equally clear that the project did not take off and is no longer live. It is an account of building a training workflow, not evidence of commercial success or quantified cost savings.

Both examples belong in a hiring conversation. Ask what was built, what the engineer owned and what happened to the product. A candid explanation of a discontinued MVP can be more informative than an unexplained portfolio logo.

Planning an implementation? See what an Arsum build can include →

Choose the relationship your product needs

A product can continue changing as users encounter it. The founder emphasizes finding someone who will care about those changes: missing information, unsuitable answers and new requirements still need attention after launch.

Choose an arrangement that covers the work and the management it needs:

One experienced freelancer may be the right partner for a substantial product. An agency may still leave you coordinating disconnected people. Ask about the proposed people, their availability and the work included in the agreement.

If a ready-made tool already does the job, verify it with your workflow before commissioning a custom build. If your product’s users or requirements are still changing, discuss how the relationship can accommodate iteration without leaving scope and spending open-ended.

Write a brief you can compare proposals against

Give every candidate the same starting information. You can use this brief in a marketplace job post or a conversation with a development team:

Users and job: Who will use this, and what should they accomplish?
Starting point: What application, demo or manual process exists?
Inputs: Which systems and data are involved, and who can authorize access?
First release: Which complete workflow must work? What is excluded?
Acceptance: What will we open, try and inspect before accepting it?
Ownership: Who decides product behavior, approves outputs and handles failures?
Constraints: What budget, timing, privacy and integration limits apply?
Support and handover: What happens after launch or when the engagement ends?

Describe the problem and expected behavior clearly, then ask the developer to propose the solution. That leaves room for useful expertise while giving you a basis for comparing proposals.

For cost, request separate visibility into implementation, data preparation, model/API usage, hosting and ongoing support. Ask which accounts you control, what usage assumptions the estimate uses and who approves extra spending. A low hourly rate tells you little about the total responsibility included. The AI app development cost guide offers a broader budgeting worksheet.

Agree support duration, contact route, response expectations and the boundary between fixing a defect and building a new feature. The founder advocates continued care after launch; the actual period and price must be negotiated.

Agree what you will open and test before launch

The founder asks for “the working version that is accessible.” For a web product, that can be a staging application; for mobile, a test build distributed to the client. Use it yourself and involve the people who will rely on it.

The following is an illustrative acceptance worksheet for an AI report feature, developed from the interview. It is not an Attuned Health test report or a measured Arsum result.

Before work begins, save examples of the current manual result or existing product behavior as the baseline. Agree which outcomes are required, which mistakes are unacceptable and how the reviewer will judge ambiguous cases. Set cost and waiting-time limits appropriate to your users; there is no universal pass percentage for every AI feature.

At each milestone, inspect the evidence and record pass, fail or unresolved against each check. Before launch, resolve failed critical checks. For this report example, an access leak or release of unapproved content should stop the rollout until corrected.

Agree what rollback means: disable generation, hold publication or restore the previous application version as appropriate. Assign who can trigger it and how they will handle reports or records already created. For systems that take actions, the AI security guide helps frame permissions and approval boundaries.

After launch, set a review cadence and repeat the relevant checks when prompts, models, data sources or application behavior change. As the founder puts it, “it can fail sometimes.” Your agreement should make the response to that possibility concrete.

Start with one useful piece of the product

Arsum’s founder describes the approach as caring for the product as though “we build our own business.” In practical terms, that means understanding what the user needs, making working changes and staying involved in the delivered system.

A useful first scope can be one AI integration, a connection between existing systems or an MVP with a clear user journey. Bring the current product or demo, the relevant data sources and the outcome you need to a conversation about building an AI product with Arsum. Define the first release and its support responsibilities before expanding the commitment. The MVP scope and acceptance guide provides a worksheet for that conversation.

Source note: This guide draws on a supplied reconstructed transcript of an interview with Arsum’s founder on 7 September 2026. Short quotations retain the founder’s wording, with punctuation and speech fillers lightly edited where needed. Project accounts are attributed firsthand experience or first-party case evidence; the worksheets are editorial synthesis. Linked buyer posts are qualitative examples. No project prices, measured savings or hiring-success rates are claimed.