How do I plan and scope my first AI project?

Most first AI projects do not fail because AI is hard. They fail because the scope was wrong before a single line of code was written.

A founder picks an exciting idea, the team starts building, and six months later the project has expanded from "a chatbot that answers customer questions" to "a full intelligence platform that learns from every interaction and auto-segments our CRM." The original chatbot never shipped. The platform is 40% built and going nowhere. McKinsey's 2023 survey found that 56% of companies attempting AI pilots stall or cancel them before reaching production. The most common reason: the problem was too broad to measure or deliver.

The good news is that scoping failure is entirely avoidable. It just requires a different set of questions at the start.

Start here before anything else: a good first AI project has a problem that already exists, costs something measurable, and can be tested in weeks rather than months.

That sounds obvious. But most teams skip it. They ask "what could AI do for us?" instead of "where does our team spend hours on work a machine could handle?"

A useful mental filter has three parts. The problem must be repetitive, meaning the same task happens dozens or hundreds of times a week. It must be bounded, meaning there is a clear input and a clear output. And it must be measurable, meaning you can look at the result and know whether it worked.

A customer support team that handles 300 similar questions per week about order status, return policies, and delivery times: repetitive, bounded, measurable. An AI that "improves our marketing": none of the three.

HBR's 2023 analysis of early enterprise AI pilots found that projects targeting a single, well-defined task reached production 3x more often than those targeting broad process improvement. The companies that shipped their first AI project did not start with the most ambitious idea. They started with the most annoying one.

Good starting candidates are document summarization, first-draft email or report generation, FAQ and support triage, and data extraction from unstructured text. Each of these is repetitive, bounded, and testable with a small sample before any major investment.

One sentence. That is the rule.

If your problem statement needs two sentences, your scope is already too wide. The format that works is: "We want to use AI to [do one specific thing] so that [one measurable outcome]." Every word that does not fit that template is scope creep waiting to happen.

Here is how it plays out in practice. "We want to use AI to improve our customer experience" is not a problem statement. It is a goal, and a vague one. "We want to use AI to draft a first response to every incoming support ticket so that our team spends 10 minutes on each ticket instead of 30" is a problem statement. It has a specific task, a specific workflow, and a number you can check after 30 days.

The one-sentence test also tells you whether you are solving a real problem or chasing a capability. "We want to use AI because our competitors are" fails the test immediately. There is no outcome to measure.

Once you have the sentence, write down three things: what counts as success, what data you already have that can feed the AI, and what happens if the AI is wrong 15% of the time. That last question matters more than most founders expect. A tool that drafts support replies with 15% errors is useful if a human reviews each one before it sends. The same error rate on automated outbound emails is a liability. Knowing your tolerance for AI mistakes before you build shapes the entire architecture of the project.

A Stanford HAI report from late 2023 found that teams who defined success metrics before starting an AI project were 2.4x more likely to reach production than teams who defined metrics after. Write the measurement down first.

Off-the-shelf. Every time, for a first project.

Custom AI means training or fine-tuning a model on your data. That requires a clean, labeled dataset, a team with machine learning expertise, significant compute costs, and months of iteration before you know whether it works. For a first project, that is the wrong sequence. You are spending the most money and time before you have learned anything about whether the problem is worth solving.

Off-the-shelf AI means using an existing model, like GPT-4, Claude, or Gemini, through an API and connecting it to your workflow. The model is already trained. You write instructions that tell it what to do with your specific inputs and outputs. A working prototype can exist in days.

The cost gap between these two paths at the first-project stage is significant. Building a custom model for document summarization from scratch costs $40,000–$80,000 and takes four to six months, depending on the size and quality of your dataset. Connecting an existing model to the same workflow costs $3,000–$8,000 and takes two to four weeks at an AI-native agency. Western agencies running traditional workflows quote $15,000–$35,000 for the same off-the-shelf integration, because the inefficiency in their process gets baked into your invoice.

The off-the-shelf path also gives you something custom development cannot: early evidence. You learn within weeks whether AI actually solves the problem, how often it makes mistakes, and whether your team will actually use it. That evidence shapes every decision that comes after.

There is one case where custom becomes worth considering: after your first project ships and proves value, and you have enough real usage data to know exactly where the off-the-shelf model falls short. That is the right moment to explore fine-tuning. Not before.

Six to ten weeks from kickoff to a working tool in the hands of real users. That is the honest range for a well-scoped first AI project with an experienced team.

Week 1 is discovery: you document exactly what the AI needs to do, what data feeds it, and what the human review process looks like. Week 2 is a prototype: a rough working version that processes a small set of real examples. Weeks 3–4 are refinement: the team adjusts how the AI is instructed, reviews the outputs, and catches the edge cases. Weeks 5–6 are testing with your actual team on real work. Weeks 7–10 are a buffer for integration with existing tools and any fixes that come out of internal use.

That timeline assumes the scope stayed at one sentence. Every additional requirement adds one to three weeks. Adding a second use case mid-build typically doubles the total timeline.

Gartner's 2023 AI adoption research found the median enterprise AI project takes 17 months from idea to production. The gap between that and six to ten weeks is almost entirely explained by scope. The 17-month projects were trying to transform a process. The six-week projects were trying to fix a task.

A few things that push timelines out, regardless of team quality. Data readiness is the biggest one. If the AI needs information that lives in three different systems and has never been cleaned or structured, getting it ready takes longer than building the AI itself. If your data is already organized and accessible, that phase shrinks dramatically.

Review and approval processes inside your organization add time too. A team of five with a founder who can make decisions ships faster than a larger company with a change management process. Budget for it if approvals are part of your reality.

Here is what the cost picture looks like across the realistic range:

The 3–5x gap between AI-native and traditional Western agency pricing on AI projects follows the same pattern as product engineering. The models being used are identical. The difference is how long it takes to integrate and refine them, and what the team building the integration costs per hour.

A first AI project that ships in six weeks and costs $6,000 gives you something no amount of planning can replicate: proof that AI works in your specific workflow, with your specific data, for your specific team. That proof is worth more than the tool itself. It tells you exactly where to invest next.

Book a free discovery call