7 Questions to Ask Before You Build Anything With AI
The most expensive AI mistakes happen before any code is written. They're baked in during the fuzzy enthusiasm phase, when "let's use AI for this" outruns "should we, and how?"
Print this. Fill it in with the decision-maker in the room. Bad answers aren't failures — they're early exits that save a quarter. Good answers sharpen the build into something worth shipping.
1. What specific problem are we solving?
If the answer is "use AI," stop. Name the painful, concrete thing — slow onboarding, manual triage, a report that eats a day a week. AI is a tool in service of that, not the goal itself.
Bad answer: "We need to be more AI-forward." / "Competitors are doing AI, so we should too." / "Something around customer experience."
Good answer: "New support tickets sit in the queue for 40+ minutes before a human triages them. We want first-pass routing to the right queue in under two minutes for the top three ticket types."
Write yours here:
Problem (one sentence): ________________________________
Who feels the pain today: ________________________________
2. How do we know it worked?
Pick one number and a baseline. Time-to-resolution, conversion, hours saved. Without it, every outcome is a "success" and nothing actually improves.
Bad answer: "We'll know it when we see it." / "Productivity goes up." / "Leadership will be happy with the demo."
Good answer: "Baseline: average first-response triage is 42 minutes. Target in 30 days of production use: under 8 minutes for the three ticket types in scope, measured in the existing helpdesk report — not a slide."
Write yours here:
Metric + baseline: ________________________________
Target + timeframe: ________________________________
3. Can we do this with what exists today?
Plans that depend on a model arriving "soon" are bets, not plans. Design for the capabilities you can deploy now; treat future improvements as upside.
Bad answer: "Once GPT-X / Claude-Y drops, this gets easy." / "We're waiting on the vendor roadmap." / "It almost works — we'll ship when the model catches up."
Good answer: "We tested the current model on 20 real tickets this week. Accuracy is good enough on types A and B; type C stays human. We ship A and B now and revisit C when we have evidence, not hope."
Write yours here:
What we can deploy this month: ________________________________
What we're explicitly not waiting on: ________________________________
4. Do we need to build, or just use a tool better?
A surprising amount of value is training and process, not software. Be honest about whether the gap is a missing product or a missing habit.
Bad answer: "We should build our own because off-the-shelf isn't custom." / "We'll figure out buy vs build in discovery." / "A custom platform will unlock everything."
Good answer: "We already have Claude Team seats. Nobody uses a shared prompt library. Before we budget a build, we're installing one workflow (call prep) for two weeks and measuring whether reps actually run it. If habits stick and the gap is still product-shaped, then we build."
Write yours here:
Tool/habit we haven't exhausted: ________________________________
Why a build is (or isn't) required: ________________________________
5. Who owns it after launch?
A pilot with no owner is a demo with a countdown. Name the person who runs it before the build, not after.
Bad answer: "IT will support it." / "The AI committee." / "We'll assign someone once it's live." / "Everyone owns adoption."
Good answer: "Jordan (Support Ops) owns the weekly metric review, prompt updates, and escalation path. Engineering owns uptime. Jordan's name is on the definition of done — not a shared Slack channel."
Write yours here:
Named owner (one person): ________________________________
What they own week-to-week: ________________________________
6. Where does our data go?
Know the data path before you start. What's sensitive, which tools are approved, what's off-limits. Ambiguity here stalls projects and creates real risk.
Bad answer: "We'll handle security later." / "People should use judgment." / "Legal is reviewing" (with no date or decision).
Good answer: "Approved: Claude Team with our org settings; no customer PII in personal ChatGPT. Off-limits: raw health data, full contract text with pricing, anything under NDA without redaction. Written on one page, shared in onboarding."
Write yours here:
Approved tools + settings: ________________________________
Explicit off-limits: ________________________________
7. What's the smallest version that proves it?
Define the narrowest slice that delivers real value in production. If a focused version can't show its worth in two to three weeks, the scope is wrong.
Bad answer: "Phase 1 is the platform; features come in phase 2." / "We need all ticket types, all channels, and the dashboard." / "MVP means a clickable prototype for the board."
Good answer: "Production: auto-route email tickets of types A and B for one support pod, with a human override and the triage-time metric live. Everything else is backlog until that number moves."
Write yours here:
Smallest production slice: ________________________________
What we cut from v1 on purpose: ________________________________
How to use this worksheet
Run the idea in one sitting — 45 minutes, decision-maker present. Score each answer honestly:
- Clear and specific → keep going
- Fuzzy but fixable → rewrite before any build spend
- Optics, hope, or "someone else will own it" → park or kill
If you can't fill boxes 1, 2, 5, and 7 without hedging, you don't have a project yet. You have a wish. That's fine — wish lists are cheap. Builds aren't.
After the worksheet, the next fork is usually vehicle: buy a tool, build a narrow slice, or wait with a revisit date. That's the build / buy / wait framework — use it only once these seven answers are honest. Diligence first; vehicle second.
When the answers point to a real build (or to "buy / train instead"), that's the right moment to scope it. I use this same diligence on a free consultation — and if you want a sharper read on whether your team is even ready to adopt what you build, start with the two-minute readiness scorecard.
Frequently asked
Often no. A lot of value comes from advisory and training — better decisions and a team that uses existing tools well. A custom build only makes sense once the problem and the metric are clear, which is exactly what a free consultation is for.
Answer the hard questions before you build. Clarity on the problem, the owner, and the success metric costs nothing and prevents the most expensive failures. Print this worksheet and fill it in with the decision-maker in the room.
Whoever can kill or fund the project. If the person writing answers can't decide, you're documenting enthusiasm, not diligence. Bring the owner, not a committee of note-takers.