Scope your AI projectbefore anyone pitches you
Most AI projects don’t fail in the code — they fail in the first two weeks of conversation. This is the working toolkit we use to turn vague AI ambitions into briefs that great engineers fight over.
Get the pack as a printable PDF
The brief template, checklist, budget bands, and vendor questions in one clean document you can fill in and share internally. Free, straight to your inbox.
The one-page AI project brief
Every field maps to something an engineer actually needs. If you complete this page, you’ve done 80% of the scoping most projects never do.
The problem, in one paragraph, no technology words
What takes too long, costs too much, or goes wrong today? Who feels it?
Who will use this, and how often?
Job titles, headcount, daily / weekly / rarely.
What “working” means — three measurable outcomes
Not “improves efficiency.” Numbers with dates: “claims summaries drafted in 5 minutes instead of 40, for 80% of standard claims, by March.”
Your data, honestly
Where does the relevant information live (systems, formats)? How messy is it really? Nobody’s data is clean — saying so early is a credibility signal, not a confession.
Systems it must touch
What does it read from, write to, or live inside?
Hard constraints
Compliance regimes, data that can’t leave your walls, approvals required, deadlines that are real vs. aspirational.
Budget band and timeline expectation
$25–50k / $50–100k / $100–200k / above — and 4–6 weeks (pilot) vs. 8–12 weeks (production v1). See the reality bands before answering.
Who decides, and by when?
Name the actual decision-maker and the date a yes/no will be made.
The sink question
Of the eight disciplines in the checklist, which two or three would sink this project if your engineer got them wrong?
The 8-discipline checklist
Every AI project lives or dies on a few of these. Most vendors are strong on two or three and quiet about the rest — your job is to know which ones your project needs before anyone pitches you. Circle your two or three sink risks and put them in the brief.
Ask yourself: Does this need to answer from our information, accurately, with sources?
Sink risk if: your documents are many, messy, or the answers must be right.
Ask yourself: How will we prove it’s good enough to trust — before and after launch?
Sink risk if: wrong answers are expensive or embarrassing.
Ask yourself: Do we actually need a custom-trained model, or do we just think we do?
Sink risk if: a vendor proposes it early and can’t say why in plain english.
Ask yourself: Should this do things on its own, or draft for a human to approve?
Sink risk if: anything runs unsupervised where a mistake compounds.
Ask yourself: What must never leak — to the model provider, to users, to a clever prompt?
Sink risk if: customer data, contracts, anything regulated.
Ask yourself: What does this cost per month at real usage, not in the demo?
Sink risk if: usage will scale; nobody has named a monthly number.
Ask yourself: What has to happen to our data before any of this works?
Sink risk if: the honest answer to the data question was “it’s rough”.
Ask yourself: Which parts of the ambition should be version 2 — or never?
Sink risk if: the pitch says yes to everything.
Budget & timeline reality bands
What money actually buys in 2026, from watching real projects. Ranges assume senior, vetted builders — cheaper exists, and usually costs more by the end.
One workflow, one user group, real data, a real eval suite, human review kept in the loop. Deliverable: a working system plus evidence about whether to invest further.
Not: Integrations with everything, autonomy, or “the platform.”
One core use case shipped to real users: monitoring, failure handling, handoff documentation, your team trained to maintain it. Where most mid-market projects should start once the problem is proven.
Not: Multiple workflows or deep systems-of-record integration.
Multiple workflows or deep integration with systems of record; security review; staged rollout.
Not: Sanity — unless a pilot has already de-risked the core.
Timeline honesty: 4–6 weeks buys a pilot; 8–12 weeks buys a production v1. A vendor promising the integrated system in six weeks is pricing in a discovery you’ll pay for later. The two-week rule: whatever the size, insist on something observable every two weeks — real projects show working fragments early; troubled ones show slide decks.
Want a range for your project? The AI Cost Estimator turns six questions into an honest build-and-run estimate.
Ten questions that expose weak vendors
Ask these in the first meeting. The pattern in the answers matters more than any single one.
1.“Tell me about a project you refused, or talked a client out of.”
Good answer: A specific story with a reason.
Bad answer: “We can usually find a way.”
2.“How will we know it’s working? What will you measure from week one?”
Good answer: Testing designed before building, with numbers.
Bad answer: “We iterate based on feedback.”
3.“What happens when it gives a wrong answer to someone important?”
Good answer: Failure modes named upfront; human review where stakes are high.
Bad answer: “The latest models are very accurate.”
4.“Would you fine-tune a model on our data?”
Good answer: “Probably not, and here’s what we’d do instead — and here’s what would change my mind.” (This question is a trap on purpose.)
Bad answer: An enthusiastic yes with no question about your data volume.
5.“What will this cost to run each month — not to build?”
Good answer: A number with assumptions.
Bad answer: Surprise that you asked.
6.“Walk me through the most boring parts of your last architecture.”
Good answer: Proud of boring; novelty only where it earned its place.
Bad answer: Everything is cutting-edge.
7.“Who maintains this after handoff, and what does that take?”
Good answer: A maintenance story sized to your team.
Bad answer: An ongoing retainer as the only option, presented late.
8.“What will you do when our data turns out messier than we said?”
Good answer: A laugh of recognition, then a plan — because it always is.
Bad answer: “We’ll assess that during discovery” (translation: change orders).
9.“Which parts of our idea should NOT use AI?”
Good answer: Names one immediately.
Bad answer: It’s AI all the way down.
10.“If week two reveals the real problem is different, what happens?”
Good answer: A re-scoping mechanism that doesn’t punish honesty.
Bad answer: Rigid change-control theater, or a breezy “we’re agile.”
Scoring: Any vendor who answers seven or more well is worth a second meeting. The ones who ace #1, #4, and #9 are the ones we’d hire.
When not to use AI at all
The cheapest project is the one you correctly don’t do. Three patterns:
The rules are already known
If a human can write down the exact steps — invoice totals, record matching, data moving between systems — traditional software is cheaper, faster, and doesn’t hallucinate. AI belongs where judgment and language live, not where rules do.
A wrong answer is unrecoverable
Crisis communications, legal commitments, anything medical, money that moves irreversibly. AI can draft for expert review here, but “human approves before send” must be structural, not aspirational. If review would erase the savings, skip the project.
The data doesn’t exist yet
“Learn from our history” requires history — recorded, retrievable, and more consistent than folklore. If your data answer was “mostly in people’s heads,” your first project is capture, not intelligence. That’s still a good project. It’s just not an AI project yet.
A vendor who tells you one of these to your face is showing you discipline #8. Keep their number.
Five prompts that do the prep work with you
Run these with any capable AI assistant, pasting in your own context. Replace anything in [brackets]. Want more like these? Our free AI Prompt Library has 40, organized by role.
The problem sharpener
Interview me one question at a time about a workflow I want to improve with AI. Ask about who does it, how long it takes, what goes wrong, and what a good outcome would be worth. After 8 questions, write a one-paragraph problem statement with no technology words.
The data reality check
Here are 3 representative samples of the documents/data involved: [paste]. List the quality problems an AI project would hit with data like this, ranked by how much trouble each causes, and what preparing each would involve.
The success-criteria drafter
Based on this problem statement: [paste] — draft 8 testable acceptance criteria, each with a number and a measurement method a non-engineer could run. Mark the 3 that matter most.
The build-or-don’t check
Steelman the case for solving this with (a) plain software rules, (b) process change and no technology, (c) AI. Problem: [paste]. Tell me which you’d choose and what evidence would change your mind.
The brief assembler
Turn my answers into a one-page project brief with these sections: problem, users, success criteria, data reality, systems touched, constraints, budget band, timeline, decision process. Flag every section where my input was vague. Here’s everything: [paste].
Scoped it? Two paths.
Bring your brief to us — a 15-minute scoping call, then introductions to 2–3 vetted engineers or consultancies matched to your sink-risk disciplines. Or take this pack to any vendor you like; if they handle the ten questions well, you found a good one.
Related Content
AI Development Cost Estimator
An honest range for your project in six questions.
AI Readiness Assessment
See where your team stands — free.
AI ROI Calculator
See what stalled AI adoption costs you.
AI Prompt Library
40+ copy-paste prompts by role.
AI Readiness Checklist
25 checks with a live readiness score.
AI Engineer Rate Calculator
Turn a target income into defensible rates.