Most AI project quotes are wrong before the first call ends — not because agencies are bad at estimating, but because the spec they're estimating against doesn't contain the information that actually drives cost. A non-technical founder who writes a good AI spec will get quotes that are 30–50% tighter, timelines that hold, and a product that matches what they imagined. This guide shows you exactly how to write one, with a complete worked example you can copy.
Why AI specs are different from normal software specs
A traditional software spec describes deterministic behavior: when the user clicks X, the system does Y. Every requirement is either met or not met, and a developer can read the spec and know exactly what "done" looks like.
AI products break this model in three ways:
Behavior is probabilistic. An AI feature doesn't "work" or "not work" — it works some percentage of the time, at some quality level, on some distribution of inputs. "The system summarizes support tickets" is not a requirement. "The system produces summaries that a support lead would rate acceptable on at least 90% of real tickets" is. If your spec doesn't define the quality bar, the developer defines it for you — usually as "whatever the demo produced."
Data is a first-class requirement. Normal software runs on logic; AI products run on your data. What data exists, how clean it is, where it lives, and whether you're allowed to use it determines feasibility more than any feature list. A spec that omits the data inventory forces the agency to guess — and they'll guess conservatively, which means padding the quote.
Cost and latency are design constraints, not afterthoughts. Every AI interaction costs real money and real seconds. A feature that's viable at 2 cents per request may be a business-killer at 30 cents. Your spec has to state the economics you can live with, because they change the architecture. Our AI build cost calculator is a good way to get grounded numbers before you write this section.
The 7 sections of a good AI spec
1. Problem and user
One paragraph. Who has the problem, how often, and what it costs them today in time or money. Be specific: "Support agents at B2B SaaS companies spend 20–40 minutes per shift manually categorizing and routing inbound tickets" beats "companies struggle with support efficiency." This section anchors every scoping decision downstream.
2. Workflow map
Describe the workflow as it exists today, step by step, then mark exactly which steps the AI takes over. Numbered list, plain language:
- Ticket arrives in helpdesk inbox
- Agent reads it and assigns a category — AI takes this over
- Agent sets priority — AI takes this over
- Agent routes to the right team — AI takes this over
- Team member responds — human, unchanged
This single section prevents the most expensive failure in AI development: building automation for a step nobody needed automated.
3. Data inventory
List every data source the system will need. For each one: what it is, roughly how much of it exists, what format it's in, where it lives, and who controls access. Include historical examples of the task done correctly — past tickets with their correct categories, for instance. Labeled historical data is gold; say so explicitly if you have it, because it can cut development time significantly.
4. Quality bar — with concrete examples
This is the section most founders skip and the one developers need most. Write out 3–5 real example inputs, and for each one show what a good output looks like and what an unacceptable output looks like. Actual text, not descriptions of text. Then state the threshold: what percentage of outputs must be good, and who judges?
If you can't write these examples, you're not ready to commission the build — which is itself valuable information.
5. Latency and cost constraints
Two numbers: how long the user can wait, and what each AI action can cost. "Response must appear in under 5 seconds; we can spend up to 3 cents per ticket processed at our target price point." These two constraints eliminate half the possible architectures immediately, which makes quotes dramatically more accurate.
6. Failure handling
AI will be wrong some percentage of the time — your spec must say what happens then. Answer three questions: How does the system detect a low-confidence output? What does the user see when it fails? Which decisions require a human sign-off before anything irreversible happens? "When confidence is low, the ticket routes to the manual queue exactly as it does today" is a complete, buildable failure requirement.
7. Success metrics
How you'll judge the project after launch, in numbers you can actually measure: time saved per agent per day, percentage of tickets auto-routed correctly, reduction in misrouted tickets. Pick 2–3. These become the acceptance criteria for the engagement, which protects both sides.
Worked example: a support-ticket triage agent
Here is a complete mini-spec in the format above. It's short — a good AI spec is 2–4 pages, not 20.
Problem and user. Our 6-person support team handles roughly 400 tickets/day. Each agent spends 25–35 minutes per shift categorizing and routing tickets before any actual support work begins. Misrouted tickets add an average of 4 hours to resolution time and are our top driver of bad CSAT scores.
Workflow map. (1) Ticket arrives via email or in-app form into Zendesk. (2) Agent reads and assigns one of 12 categories — AI takes over. (3) Agent sets priority P1–P4 — AI takes over. (4) Agent assigns to one of 4 teams — AI takes over. (5) Team member responds — human, unchanged.
Data inventory. 90,000 historical tickets in Zendesk, all with final category, priority, and team assignments (i.e., labeled). Export available as CSV. Internal routing guidelines exist as a 14-page Google Doc, last updated March 2026. Tickets contain customer PII; processing must stay within our cloud region (EU).
Quality bar. Example — input: "Hi, I was charged twice this month and the duplicate charge overdrew my account, please fix ASAP." Good output: category Billing – Duplicate Charge, priority P1, route to Payments team. Unacceptable output: category General Inquiry, priority P3, route to Tier 1. We require 90% agreement with our senior support lead's judgment on a held-out sample of 200 real tickets, measured before go-live.
Latency and cost. Triage must complete within 30 seconds of ticket arrival (tickets aren't read instantly, so this is generous). Cost ceiling: 2 cents per ticket, or roughly 240 dollars/month at current volume.
Failure handling. Any ticket where the system's confidence is below threshold goes to the existing manual triage queue, flagged "needs human triage." The system never sends anything to a customer. P1 assignments always notify a human before escalation paging fires.
Success metrics. (1) 80%+ of tickets auto-triaged without human correction within 60 days. (2) Agent triage time cut from 30 minutes/shift to under 10. (3) Misrouted-ticket rate reduced by half.
That spec is roughly 300 words, contains zero technical jargon, and a competent team could quote it accurately in one call. This is the shape of spec we work from in every AI MVP development sprint — and when a founder arrives with one like it, the first working prototype often ships within the first week.
What to leave OUT of your spec
Just as important as what goes in:
Model names. Don't write "must use GPT-5" or "built on Claude." Model choice is an engineering decision driven by your quality bar, latency, and cost constraints — the three things you did specify. Models also change every quarter; specs that hardcode them age badly. State the constraints and let the engineers pick the tool that meets them.
Architecture. No vector database selections, no "use RAG," no agent frameworks, no diagrams of orchestrators. If you write "we need a RAG pipeline with a reranker," you've turned your spec into a solution — and if it's the wrong solution, you'll pay for it twice. Describe outcomes; a senior team will tell you whether your problem needs retrieval, fine-tuning, or a well-crafted prompt, and they'll justify the choice. (If you're curious what those decisions look like in practice, our RAG and LLM integration page walks through when retrieval is the right call.)
Implementation timelines by phase. State your deadline and let the team propose the plan. Founders who dictate phase-by-phase schedules for work they haven't scoped get politely inflated quotes.
How a good spec changes the quotes you get
Agencies price uncertainty. When a spec is vague, an honest agency pads the estimate to cover the unknowns, and a dishonest one quotes low and change-orders you later. Both outcomes cost you.
A spec with a concrete quality bar, a real data inventory, and explicit cost constraints does four things to your quotes:
- Tightens the range. Known data plus a measurable quality bar removes the two biggest unknowns, and the padding disappears with them.
- Makes quotes comparable. When five agencies quote the same well-defined outcome, price differences reflect efficiency and seniority — not different guesses about what you meant.
- Filters out the wrong vendors. Teams that can't engage with your quality bar and failure-handling sections are telling you they haven't shipped production AI before. That's a cheap filter.
- Converts to acceptance criteria. Your success metrics become the contract's definition of done. Disputes about "is it finished" disappear because you defined finished in section 7.
A fixed-scope engagement is only possible when the scope is actually fixed — that's why our pricing is built around specs like this one. The spec is the thing that makes a fixed price honest.
Ready to build?
If you have a spec — or a half-formed idea you want help turning into one — send it to us and we'll give you a straight answer on scope, cost, and timeline.