Table of Contents
- Why most AI projects fail before a single model is trained
- How do you brief an AI developer before you hire one?
- What an AI project brief must include before you hire anyone
- Why the data section quietly sets your timeline
- How do you define success for an AI feature?
- AI integration versus building AI-native: brief the right ambition
- The one-page AI brief template
- How to brief an AI developer so the project actually ships
- Frequently Asked Questions
- The brief is the cheapest model you will ever build
Quick answer: Foundry 5 treats how to brief an AI developer as a one-page decision made before you hire anyone: name the business problem, describe the data you actually have, and define what a good answer looks like. MIT’s 2025 State of AI in Business report found 95% of generative AI pilots deliver no measurable profit. The brief is how you beat that number.
Most AI projects don’t die in training. They die in the brief, in the quiet gap between what a founder pictured and what the team actually built. Learning how to brief an AI developer is the cheapest and fastest thing you can do to close that gap, and it matters most when you are building an AI product as a startup and every week of runway counts.
The stakes are not theoretical. According to MIT’s State of AI in Business 2025 report, 95% of generative AI pilots deliver no measurable impact on the bottom line. Read that again: not 95% of ideas, but 95% of pilots that companies chose to fund and run. The technology rarely fails. The framing does.
An AI project brief is not a forty-page specification. Done right, it fits on a page. It answers a short list of questions so clearly that a developer can scope the work, price it honestly, and start on Monday without guessing. This guide covers what that page contains, why each answer matters, and how to write it before you hire anyone.
Why most AI projects fail before a single model is trained
AI projects fail for organizational reasons far more than technical ones. The recurring causes are consistent: no clear definition of success, weak or missing data, and a solution chosen before the problem was understood. A brief exists to force those three decisions early, while changing your mind still costs nothing but thought.
Think about what a developer does with a blank in the plan. They do not stop to ask about every ambiguity, because there are hundreds of them. They make a reasonable guess and keep moving. With conventional software that produces a product that is subtly wrong. With AI it produces something worse: a model confidently optimized for the wrong target.
Picture a founder who asks for a chatbot to “improve customer support” with no other detail. One developer builds a bot that deflects tickets. Another builds one that answers faster but escalates more. Both technically satisfy the request. Only one matches what the founder meant, and nobody wrote down which. This is the same discipline behind AI development for startups, where the brief is the product decision, not the paperwork around it.
How do you brief an AI developer before you hire one?
Foundry 5 answers how to brief an AI developer with three questions you settle before hiring: what business decision the AI is meant to change, what data you already hold, and what a good answer looks like in numbers. Nail those three and a developer can scope almost anything. Leave them open and no amount of talent rescues the build.
Notice what is missing from that list: the model. Founders love to brief the solution. They arrive asking for a large language model, a recommendation engine, or an agent, rather than describing the decision they need to get right. The best briefs invert this. They describe the job to be done and let the developer choose the tool, because the tool is the one thing a good AI team is qualified to pick.
A brief written around a decision travels well. A brief written around a technology ages the moment a better technology ships, which in this field is roughly every quarter. Describe the outcome you are buying. Let the people you hire own the how.
What an AI project brief must include before you hire anyone
A complete AI project brief includes six things: the business decision, the user and context, the data you hold, a definition of a good answer, one success metric, and your real constraints. The three that founders skip most, and pay for most, are the data, the definition of a good answer, and the metric. Those are the ones an AI developer cannot invent for you.
The business decision the AI is supposed to change
State the decision the AI will influence, in one sentence, from the user’s side. “Underwriters spend three hours a day manually reading documents to price a policy” is a decision you can improve. “We want AI in underwriting” is a wish. The first tells a developer what to optimize. The second tells them nothing they can build against.
The data you have, described honestly
AI runs on your data, not on your ambition. Describe what you actually hold: how much, in what format, how clean, and who is allowed to touch it. Founders routinely overstate this, and the overstatement surfaces in week two rather than week one. An honest paragraph about messy data is worth more to a developer than a confident promise of data that turns out to live in six incompatible spreadsheets.
What a good answer actually looks like
Define correct before anyone builds. For a classifier, that means labelled examples of right and wrong. For a language model, it means sample questions with the answers you would accept and the ones you would reject. This is your ground truth, and without it there is no way to tell a working model from a plausible-sounding one. A brief that skips this ships a feature nobody can grade.
Why the data section quietly sets your timeline
On most AI builds, preparing the data takes longer than training the model. Collection, cleaning, labelling, and permissions routinely eat the majority of the schedule, which is why a vague data section turns a firm quote into a guess. The developer is not padding the estimate. They are pricing the fog you handed them.
This is the reason the UK Government’s own service manual puts a full discovery phase ahead of any build, precisely to understand users, data, and constraints before code starts. Your brief is a compressed version of that discipline: the same questions, answered on a page rather than over a month.
Data also drives the bill. Clean, ready data means a shorter build; scattered, unlabelled data means weeks of preparation before anyone trains a thing. If you want to understand the cost of building an AI product with any accuracy, start by being honest about the state of the data, because that single answer moves the number more than any other.
How do you define success for an AI feature?
Before you brief an AI developer, Foundry 5 pins one success metric to real behaviour rather than to model accuracy. A model can be 98% accurate and still useless if it is confident on the easy cases and wrong on the ones that matter. Name the number that means the feature earned its place: hours saved, tickets deflected, fraud caught, conversions lifted. One number, tied to the business.
Accuracy is a lab score. Value is a business outcome. Confusing the two is how teams ship a technically impressive model that changes nothing on the P&L, which is exactly the failure MIT measured across the market. The metric in your brief is the difference between a science experiment and a product.
A good AI metric is specific, measurable, and honest about the threshold. “The model must be right often enough that a human only reviews the 20% it flags as uncertain” is a target a team can build toward. “It should be accurate” is a target nobody can hit, because nobody defined the finish line.
Not sure how to turn your idea into a metric a developer can build toward? A short scoping call converts a vague AI ambition into a brief with a number in it. Book a free 30-minute discovery call with Foundry 5. No pitch deck, no pressure, just a sharper brief by the end of it.
AI integration versus building AI-native: brief the right ambition
One line in your brief changes everything downstream: whether you are adding intelligence to a product that exists, or building a product whose core is the intelligence itself. Deciding between AI integration versus building AI-native sets the scope, the cost, and the kind of team you need, so it belongs at the top of the brief, not as an afterthought.
AI integration is the lower-risk path: a support inbox that drafts replies, a CRM that scores leads, a report that writes its own summary. The product still works if the AI is switched off. AI-native is a different animal, where the intelligence is the product and there is no fallback. Both are legitimate. They are not the same brief.
Here is the honest concession. Plenty of founders should not build AI-native yet, and a good studio will say so. If your real question is whether a technical approach even works, a small proof of concept answers it for a fraction of the cost, rather than a full build that discovers the same thing in month four. Brief the smallest thing that removes your biggest unknown. That is maturity, not caution.
The one-page AI brief template
Foundry 5 keeps every AI project brief to a single page on purpose, because how to brief an AI developer is really an exercise in leaving things out. The structure below is the whole thing. It borrows its backbone from writing an MVP brief, then adds the three rows that are unique to intelligence: the data, the definition of a good answer, and the acceptance threshold.
| Section | What it answers | Example |
| Business decision | The decision the AI improves, from the user’s view | Underwriters spend three hours a day reading documents to price a policy |
| User and context | Who uses the output and where it fits their workflow | In-house underwriters inside the existing policy admin tool |
| Data you have | How much, what format, how clean, who can use it | Five years of scanned PDFs, no labels yet, GDPR restricted |
| A good answer | What correct looks like, with real examples | Extracts the ten key fields with a human checking flagged cases |
| Success metric | The one number that means it worked | Cuts document review time per policy from three hours to thirty minutes |
| Constraints | Budget, deadline, must-use tools, compliance | Live in twelve weeks, UK GDPR, integrates with the current CRM |
Add one honest line for the constraints a developer cannot guess: your real budget range, the deadline that genuinely matters and why, the systems the AI must plug into, and any compliance rules such as UK GDPR. Hiding the budget does not win you a better price. It wins you a quote for something you cannot afford.
How to brief an AI developer so the project actually ships
The briefs that ship share one trait: they lock scope before code starts. The Standish Group’s long-running CHAOS research found that a clear statement of requirements is among the strongest predictors that a project succeeds, and that incomplete or changing requirements are among the leading causes that it fails. AI does not repeal that finding. It sharpens it, because a vague AI brief fails more expensively than a vague website ever could.
The same brief discipline scales across every shape of AI work. Whether you are scoping AI agents that take actions on a user’s behalf, or AI automation that removes a manual back-office task, the questions are identical: what decision, what data, what a good answer looks like, and what number proves it. The subject changes. The brief does not.
This is also why the brief compresses the calendar. The same scoping rigour that lets a team ship a four-week MVP is what lets an AI build hold a date instead of drifting into an open-ended research project. Every hour then goes into building the agreed thing, rather than relitigating what the agreed thing was.
Already know the decision your AI needs to get right? Start a conversation with Foundry 5 here, or keep reading for the questions people ask most before they brief a build.
Frequently Asked Questions
What is an AI project brief?
An AI project brief is the short document Foundry 5 uses to answer how to brief an AI developer before a build starts: the business decision, the user, the data you have, a definition of a good answer, one success metric, and your constraints. It fits on a page. Its job is to let a developer scope and price the work without guessing, and to give the whole team one shared definition of what correct means.
How do you brief an AI developer with no technical background?
You do not need to name the model. Foundry 5 briefs an AI developer by describing the business decision, the data you hold, and what a good answer looks like in plain language, then letting the developer choose the technology. Non-technical founders write stronger briefs than they expect, because the hardest parts, the problem and the definition of success, are business questions, not engineering ones.
How much data do you need before briefing an AI project?
Enough to describe honestly, which matters more than a magic number. Some problems need thousands of labelled examples; others run on a modern language model with almost none. The right move is to state exactly what you have, how clean it is, and who can use it, then let the developer tell you whether it is enough. An honest data paragraph beats an optimistic one every time.
Should you brief an MVP or a proof of concept for an AI feature?
Brief the smallest thing that removes your biggest unknown. If the question is whether an approach can work at all, a proof of concept answers it cheaply. If the question is whether users will value it, an AI-powered MVP is the right build. Founders often say MVP when they mean proof of concept and get charged for the wrong thing, so state which one you want at the top of the brief.
Who should write the AI brief, the founder or the studio?
The founder writes the first draft, because only the founder owns the problem, the users, and the definition of success. A studio like Foundry 5 then pressure-tests it, flags hidden scope, and sharpens the data and evaluation sections, but it should not invent your answers for you. The strongest briefs come from a founder’s honest first pass, refined in one conversation with the people who will build it.
The brief is the cheapest model you will ever build
Everything expensive about AI happens downstream of a weak brief: the wrong target, the missing data, the polished model that moves no number anyone cares about. Foundry 5 treats how to brief an AI developer as the highest-leverage page in the whole project, because it is the one place where a founder’s clarity converts directly into a shorter, cheaper, more certain build.
Write the answers down before you hire. The decision the AI will change. The data you honestly hold. What a good answer looks like. The single number that proves it worked. Do that, and you have already done the hardest and most valuable work in the project, the part no model can do for you.
If you want a second pair of eyes on your brief before you commit a budget, book a free 30-minute discovery call with Foundry 5. No pitch deck. No pressure. Just an honest read on what to keep, what to cut, and what your developer needs to hear before day one.
Brief it right, and the model almost builds itself.
