How to Brief an AI Developer (So You Don't Waste Money)

We've seen $20,000 projects fail because the brief was "we want AI." We've also seen $5,000 projects succeed brilliantly — because the owner knew exactly what problem they were solving before they picked up the phone.

The difference between those two outcomes almost never comes down to the technology. It comes down to the brief. A good brief saves everyone time, keeps the budget under control, and gives the developer the clarity they need to build something that actually works. A bad brief leads to scope creep, mismatched expectations, and a tool that sits unused because it doesn't quite do what you needed.

We're going to give you the exact template we wish every client would fill in before our first conversation. Five questions. That's it. Answer them honestly and you'll be ahead of 90% of the briefs we receive.

Why the brief matters more than the technology

Here's something most business owners don't realise: the technical part of an AI project is rarely the hard bit. The hard bit is figuring out what you actually need. Once a developer understands the problem clearly — the real problem, not the imagined one — the build is usually straightforward.

A vague brief doesn't just waste the developer's time. It wastes yours. You'll sit through discovery meetings that go in circles. You'll get a proposal that doesn't quite match what you had in mind. You'll approve a build, see the first demo, and say "that's not what I meant." Then everyone goes back to the drawing board, the timeline doubles, and the budget follows.

A clear brief avoids all of that. It gets you to a working tool faster, for less money, with fewer surprises. It's the single highest-leverage thing you can do before spending a dollar on development.

The 5-question brief template

Print this out, open a blank document, or just jot the answers on the back of an envelope. The format doesn't matter. The thinking does.

Question 1: What specific problem are you solving?

This is where most briefs go wrong. "We want AI" is not a problem — it's a solution looking for one. "We want to automate things" isn't much better. You need to name the actual pain.

Good answers sound like this:

• "We miss about 30% of incoming phone calls during busy periods, and those patients rarely call back."
• "Our office manager spends two hours every day sorting email and manually entering data from referral letters."
• "We get 50+ enquiries a week through our website form, and it takes a full day to triage and respond to all of them."
• "Staff spend 20 minutes after every appointment typing up clinical notes."

Notice the pattern? Each one describes a specific, measurable frustration. Not a technology wish — a business problem. If you can attach a number to it (calls missed, hours wasted, dollars lost), even better. Numbers turn a vague feeling into a business case.

Question 2: What does the current process look like?

Walk through the process step by step, exactly as it happens today. Don't skip the messy parts — they're usually the most important.

For example: "A patient calls. If the receptionist is free, she answers, checks the schedule in our practice management software, and books them in. If she's busy with someone at the desk, the call goes to voicemail. About half of those people leave a message. We call them back when we can, but sometimes it's end of day. Some never answer when we return the call."

That paragraph tells a developer more than a ten-page requirements document. We can see exactly where the process breaks — the handoff between the desk and the phone — and we can design something that catches the calls that fall through. Without this context, we'd be guessing.

Question 3: What data do you have?

AI needs data to work with. The developer needs to know what's available before they can design anything. Be specific:

• What software do you use? (Practice management system, CRM, accounting package, email provider)
• Are your records digital or paper?
• How far back does your data go?
• Is it searchable? Can you look up a customer by name or date?
• Is there an API? (If you don't know, just name the software — the developer can check.)

You don't need to be technical here. "We use Cliniko for bookings and Xero for invoicing, everything's digital going back to 2019" is a perfect answer. It tells us what we're working with.

Question 4: What does success look like?

This is the question that keeps projects on track. If you can't describe what "done" looks like, neither can the developer. Make it measurable:

• "Answer 100% of calls, even after hours."
• "Reduce data entry from 2 hours to 15 minutes per day."
• "Respond to every website enquiry within 5 minutes, automatically."
• "Clinical notes completed before the patient leaves the chair."

These aren't just goals — they're acceptance criteria. When the build is done, you can look at these statements and say "yes, it does that" or "no, it doesn't." That clarity protects both sides. You know what you're paying for, and the developer knows when the job is finished.

Question 5: What's your budget and timeline?

Be honest. "I have $10,000 and I need it working in three months" is a brilliant answer. It lets the developer scope the project to fit your reality instead of designing a dream system you can't afford.

"Money is no object" is never true, and saying it doesn't help anyone. It just means the first proposal will come in higher than it needs to, because the developer has no guardrails. Give them a range — "$8,000 to $12,000" or "under $15,000" — and they'll design to that number. If your budget doesn't match your expectations, a good developer will tell you honestly and suggest a smaller starting point. That's a much better conversation than finding out six weeks in that you're over budget.

Not sure what a reasonable budget looks like? We've written a transparent cost breakdown for different types of AI projects. It'll give you a realistic range before you talk to anyone.

A real example brief

Here's what a strong brief looks like when you put it all together. This is based on a real project (details changed):

"We run a dental practice with 4 staff. Our receptionist misses about 30% of calls during busy periods — when she's helping someone at the desk, the phone just rings out. Patients who hit voicemail rarely call back, and we know we're losing bookings because of it."

"We use [practice management system] for all our scheduling. Everything's digital going back five years. The system has an API."

"We want an AI that answers the calls we can't get to, books appointments into our real schedule based on availability, and sends us a summary of every call it handles. It needs to know our services, hours, and basic policies."

"Budget: $8,000–12,000. Timeline: 6 weeks."

That's seven sentences. It took the owner maybe fifteen minutes to write. But it gave us everything we needed to scope the project, write an accurate proposal, and start building within a week. No discovery workshops. No requirements gathering phase. No $3,000 "strategy engagement" before work even begins.

Compare that to: "We want to use AI in our practice. Can you come in for a chat?" That second brief will take three meetings just to get to the same starting point — and those meetings cost both of us time.

Red flags in your own brief

Before you send your brief, read it back and check for these. If any of them sound familiar, it's worth revising before you reach out:

• "We want to use AI" — That's a solution, not a problem. Go back to Question 1. What hurts? What's slow? What's costing you money? Start there.
• "Automate everything" — Pick one thing. The businesses that get the most value from AI start with a single, well-defined problem, nail it, and then expand. Trying to automate everything at once is how projects blow out. Starting focused is always smarter.
• "ASAP" — Rushed projects fail. They skip testing, cut corners on edge cases, and launch with bugs that erode trust in the tool. A realistic timeline is always faster in the end, because you don't spend months fixing something that was built too quickly.
• "Like ChatGPT but for our business" — This is too vague to act on. ChatGPT does a thousand things. Which one do you actually need? Answering customer questions? Drafting emails? Processing documents? Narrow it down to a specific use case and the brief gets a lot stronger.
• "We're not sure what we need, but we know we need something" — This is more common than you'd think, and it's actually fine to feel this way. But instead of sending it as a brief, spend thirty minutes answering Questions 1 and 2 above. Walk through your day, find the bottleneck, and name it. That turns uncertainty into a starting point.

Why we're giving you this template

We'll be honest — this post saves us time too. Clients who've read it give us better briefs. Better briefs lead to tighter scopes, faster builds, and happier outcomes on both sides. We'd rather spend our first meeting discussing solutions than trying to figure out the problem.

It also protects you from developers who are happy to take a vague brief and run with it — because vague briefs lead to open-ended invoices. When you show up with clear answers to these five questions, you're telling the developer "I know what I need, give me a straight answer on cost and timeline." That changes the dynamic entirely.

Ready to write your brief?

Open a blank document right now. Copy the five questions. Answer them as honestly as you can. It shouldn't take more than twenty minutes. If you get stuck on any of them, that's useful information too — it tells you where you need to think more before spending money.

Once you've got your answers, send them through to us. We'll read your brief, tell you honestly whether the project makes sense, and give you a realistic scope, cost, and timeline. No fluff, no jargon, no surprise invoices. Just a straight conversation about what AI can do for your specific business.