The AI Feature Brief: What to Send Your AI Developer

Most AI projects start with a sentence like "we want a chatbot for our docs" and a request for a price. Any honest developer will answer with questions, because the price depends on details that sentence leaves out: how many documents, what happens when the answer is wrong, who is allowed to see what. The brief below answers those questions up front.

It takes about an hour to fill in. You do not need technical knowledge, and blanks are fine: a section marked "not sure" tells the developer where scoping effort will go.

Why does an AI feature need a different brief?

AI features need a measurable definition of "good enough", because unlike a normal feature they are never right 100% of the time. A login page either works or it does not. A support assistant answers correctly most of the time, and the business question is how often is often enough, and what happens the rest of the time.

Anthropic's guidance on defining success criteria for AI applications says good criteria are specific, measurable, achievable and relevant. It suggests replacing "good performance" with something like "accurate sentiment classification", and lists dimensions such as task fidelity, consistency, latency and price. A brief is where you write those down in business terms, before anyone builds anything.

It also keeps the project small. Anthropic's engineering team recommends "finding the simplest solution possible, and only increasing complexity when needed" when building with models. A brief with a clear problem and metric makes it obvious when a simple approach is enough.

The one-page template

Copy these seven headings into a document and answer each in a few lines. The prompts under each heading are there to guide you; you do not need to answer every one.

1. The problem

• What task is slow, expensive or error-prone today?
• How is it done now, by whom, and roughly how often?
• What happens if nothing changes?

2. Users and workflow

• Who will use the feature: staff, customers, or both?
• Where does it appear: inside your app, in email, in a chat tool, in the background?
• Does a person review the output before it reaches anyone else?

3. Data

• What information does the AI need: documents, database records, emails, call transcripts?
• Where does it live and roughly how much is there?
• Does it include personal, financial or health data?
• Can you share 20 to 50 real examples, with the answer you would expect for each?

4. Success metric

• What number tells you it works? For example, the share of answers a reviewer marks correct, minutes saved per ticket, or fields extracted without correction.
• What target would make it worth launching?
• How fast does it need to respond, and what is an acceptable running cost per use or per month?

5. Constraints

• Systems it must connect to, and whether they have APIs.
• Any required model provider, cloud or hosting region.
• Budget range and deadline, even if approximate.
• Compliance rules your industry applies, and laws such as the EU AI Act if you serve EU users.

6. Risks and approvals

• What is the worst thing a wrong answer could cause?
• Which actions must always have human approval, such as sending, deleting, paying or publishing?
• Who needs to approve the use of each data source?

7. Sign-off

• Who decides the feature is ready to launch?
• Who owns it after launch, and who will review its quality each month?

Section 4 matters most. If you only have time for one section, fill in that one, because it becomes the developer's test plan. Hamel Husain's guide to evaluation argues that unsuccessful AI products "almost always share a common root cause: a failure to create robust evaluation systems". Your 20 to 50 examples are the start of exactly that system, the eval suite the developer builds on.

A filled-in example

Here is the template completed for a hypothetical company, to show the level of detail that helps. The business and numbers are invented for illustration.

Notice what this brief makes easy. The developer can see it is a draft-for-review feature, which is the safest kind to start with. The data and personal information are clear, so privacy questions can be answered early. And the success metric can be measured from day one by tracking how much agents edit each draft. My guide to adding AI to an existing app explains why this kind of first feature is usually the right one.

Common mistakes in AI briefs

A few patterns make briefs less useful, and they are easy to avoid:

• Naming the solution instead of the problem. "Build us an agent" leaves out what the agent is for. Describe the task and let the developer propose the approach.
• No examples. Without real inputs and expected outputs, nobody can estimate quality or effort.
• A vague metric. "It should be accurate" cannot be tested. "Correct on at least 9 in 10 of these 50 examples" can.
• Hiding the risky part. If the feature will touch payments or medical data, say so in the brief. It changes the design and the price.
• No owner after launch. AI features need someone to review quality and costs over time, because models, prices and user behaviour change. Cutting LLM app costs shows what that review can find.

What should you get back from the developer?

A good developer replies to a brief with three things: a quote or a scoping proposal, a short list of focused questions, and a plan for how they will measure the success metric. If you get only a price, ask how they will test the feature against section 4.

If you are still choosing who to send it to, 15 questions to ask before you hire an AI developer covers vetting, and Toptal vs Arc vs Upwork vs direct covers where to find candidates. The brief works the same way whichever route you take, and it makes quotes from different people comparable.

Work with me

Send me a brief, even a half-finished one, and I will reply with focused questions and an evaluation plan before we talk price. See AI integration and SaaS MVP development, or browse my work and book a scoping call.