How to Brief an AI-Assisted Development Team

Why briefing changed when AI joined the team

On a traditional project, a vague brief was survivable because everything moved slowly — there were months of meetings in which misunderstandings could surface. On an AI-assisted build there is no such buffer. Your brief is read on day one and compiled almost directly into working software: workflows become tickets, tickets become prompts and generated code, success criteria become acceptance tests. By day three the build reflects whatever you wrote, precisely.

That direct line is a gift if the brief is sharp and a tax if it is not. An ambiguous sentence no longer costs a clarifying meeting; it costs a wrongly-built feature that must be noticed and redone. The good news is symmetrical: one page of genuinely clear thinking now buys more correct software than it ever has.

The requirements data: most project failures start in the brief

The research on why software projects fail keeps arriving at the same doorstep. PMI's Pulse of the Profession research found that 47% of unsuccessful projects fail to meet their original goals because of inaccurate requirements management, and an earlier edition of the same study found 37% of organisations naming inaccurate requirements as the primary cause of project failure — ahead of budgets, technology and talent.

The scale of the waste sits behind those percentages. Research by McKinsey with the University of Oxford across more than 5,400 IT projects found large projects delivering 56% less value than predicted while running 45% over budget, and the Standish Group's CHAOS research has reported only around 31% of software projects finishing on time, on budget and with full scope in recent editions. Nobody on those projects typed too slowly. They built the wrong things, confidently, from briefs that let them.

The brief is therefore the cheapest point of intervention you will ever get. Every downstream fix — redesigns, change requests, rebuilds — costs multiples of the afternoon it takes to write six clear sections. That was true before AI; the direct brief-to-build pipeline simply raised the exchange rate on clarity.

The one-page brief: six sections

Here is the structure we ask every client for. Write it in plain language — it should read like you explaining the business to a competent friend, not like a specification.

• Problem — two or three sentences on what hurts today and what it costs you. "Bookings arrive on WhatsApp and get lost; we miss maybe five a week."
• Users and roles — who touches the system and what each may do. "Customers book; two staff manage the calendar; the owner sees reports."
• Core workflows — the three to five journeys that matter, each as one plain sentence from trigger to outcome.
• Integrations — every external system involved: Stripe for payments, Google Calendar, HubSpot, WhatsApp Business API, that one critical spreadsheet.
• Out of scope — what version one deliberately excludes: no mobile app yet, no multi-location, English only.
• Success criteria — how you will judge it in week one. "A customer books and pays without phoning us; staff see the day's schedule at a glance."

The details that most improve your quote

Beyond the structure, a handful of concrete details do disproportionate work, because they answer the questions a builder would otherwise have to pad the price against. Attach the artefacts you already have: the spreadsheet the software will replace, a screenshot of the tool you like, ten anonymised rows of real data. One genuine example beats three paragraphs of description, and generated first drafts get dramatically better when they can imitate something real.

State your volumes honestly, even roughly — ten bookings a day and a thousand are different builds. Name your worst edge case, the messy situation you secretly hope nobody asks about, because handling it is often the project's real point. And say what happens today when things go wrong; error paths are where unbriefed software fails first.

What to leave out

Almost every weak brief fails the same few ways, and each one narrows the solutions you can be offered. Prescribing the technology — "build it in React with MongoDB" — spends your influence on the one decision your team is best placed to make; describe the outcome and let them justify the stack. Describing a solution instead of a problem hides the actual need: "add a dashboard" might really mean "I find out about problems too late", which may have a far cheaper fix than a dashboard.

Length is the other trap. A forty-page document does not remove ambiguity, it hides it — contradictions between page 6 and page 31 that nobody reconciles until the build exposes them. And "like X but simpler" briefs against a competitor's product, which you know from the outside only; list the five things you would actually use, and you will pay for five things instead of an imitation.

Vague versus useful: the same brief, rewritten

The difference between a brief that produces an accurate quote and one that produces a padded guess is usually a single rewrite per line. Some real patterns, anonymised:

What a clear brief buys: numbers from 79 projects

Across PINCLER's 79 documented projects — every one delivered from a brief shaped like the six sections above — the median build is $1,450 and ships in 13 days, with all 79 fixed-priced between $500 and $2,500 and delivered inside 30 days. The full dataset is public at pincler.com/research/what-you-can-build, and it doubles as a calibration tool: find the project type that resembles yours and you have a realistic anchor before any call takes place.

The brief also decides which budget band you land in, because vagueness prices as risk. The table below shows how far each budget reaches across those 79 projects — and the practical difference between a $1,000 project and a $2,000 one is usually scope decisions made, or not made, on the page. Builders price uncertainty; a tight out-of-scope list is how you stop paying for it.

A worked example: the same project, briefed twice

Take the clinic booking system from the table earlier and price the vague version first. "Customers should book easily, it needs reporting, make it secure" forces any builder to pad for the unknowns. At a typical agency's $85 per hour with a defensive estimate of 120 hours, that is $10,200 — a general market observation, not a quote — and the padding is rational, because nobody yet knows whether "reporting" means one screen or twelve.

Now the tight version: two practitioners, 30- and 60-minute slots, Stripe deposits, WhatsApp confirmations, a 24-hour cancellation cutoff, no mobile app in version one, success measured by bookings arriving without phone calls. Same product intent — but every unknown has become a decision, and it prices as a fixed $1,500-to-$2,200 build delivered in about two weeks. The afternoon spent tightening the brief moved the price by thousands and removed the change-order risk entirely. No other hour in the project pays that well.

When one page is not enough

Fairness demands the exception list, because a minority of projects genuinely need more than a page. Migrations from a legacy system need an inventory of what exists — data volumes, integrations, the undocumented behaviour staff rely on — and that inventory can run to several pages of useful fact without becoming padding. Regulated workflows need the rules written down, or at least pointed at, so the build can capture what an auditor will later ask for; the rules themselves remain a matter for your licensed advisor. And multi-phase products deserve one page per phase rather than one long document, so each phase keeps a scope you can approve and test independently.

The principle survives even in the exceptions: every extra page must carry facts the builder cannot guess, not prose that restates ambition. Length added for confidence is padding; length added for inventory is information.

What happens to your brief on our side

At PINCLER the pipeline is short. We read the brief before the free 30-minute call, spend the call on the gaps and the edge cases, and send a written fixed quote — between $500 and $2,500, never more for a single phase — within one working day. The quote restates your scope and your exclusions in plain language, so the thing you approve is the thing that gets built.

Then the brief goes to work: workflows become the ticket list, success criteria become the acceptance tests we run before you ever see staging, and the out-of-scope list protects the price for both sides. If you have a rough idea and a blank page, the six sections above are the fastest route to a real number — write them, book the call, and you will have a quote this week.