Small teams are often told they are too small for AI. The opposite is closer to the truth. A first AI project rarely fails because it lacked headcount — it fails because the scope drifted, the data was an afterthought, and nobody defined success. A small team with clear ownership moves faster than any committee. This guide lays out a planning process you can finish in an afternoon, before anyone writes a line of code.
Start with a workflow, not a model
The most common planning mistake is picking the technology first and searching backwards for a use case. Flip the order. Sit with the team, list the work everyone actually does, and find the tasks that are repetitive, text-heavy, and judged against a standard people already agree on. Drafting replies to common customer questions, summarising reports into a fixed structure, classifying incoming tickets, and extracting fields from messy documents are strong candidates.
What they share matters more than what they do: a human can verify the output in seconds, and good output is already well defined. Avoid workflows where a mistake is expensive and slow to discover; anything with legal, medical, or financial consequences can wait for a more mature project. The goal of a first project is a credible win, not a heroic one.
Scope a proof of concept you can finish
Write the plan as a six-week effort, and treat that box as load-bearing. Long-running pilots lose sponsorship, and models left half-integrated become everyone's second priority. Name the roles even if one person holds two: someone who knows the data, someone who owns the workflow and can judge its outputs, and someone who builds. On a small team, two people can wear those four hats as long as both perspectives are genuinely present.
Just as important is what the plan excludes. A proof of concept does not need a polished interface, single sign-on, or production scale. It needs real inputs, honest output, and a score. Write the exclusions down — no integration, no interface polish, no new data collection — because scope creep on a six-week project is a certainty to pre-empt, not a risk to monitor.
Treat the data check as the real plan
Every AI plan is secretly a data plan. Before promising anything, collect fifty to a hundred real examples of the task: the input exactly as it arrives, and the output a competent person would produce. Two days with real examples beats a month of architecture debates. Then ask three questions:
- Do the examples exist in a form we can legally and practically use — customer data may be contractually off-limits?
- If the work must stay private, do we have the hardware and tooling to keep it in-house?
- If the data does not exist, who can write a hundred representative examples, and how long will that take?
A no to any of these is a finding, not a failure — a pilot built on hand-written examples still answers the core question, at a fraction of the cost.
Measure a baseline before you build
Before anyone touches a model, measure how the work is done today: minutes per item, cost per item, and the error rate a careful human produces. These numbers form the baseline — the only fair comparison for the prototype. Teams that skip this step end up defending vague impressions — the demo "seems pretty good" — which is the argument a sceptical stakeholder will win. Agree on two success numbers in writing before the first build. One is a quality measure, such as the share of outputs a reviewer accepts without editing. The other is an efficiency measure, such as time per item from arrival to approved result. State the targets plainly — for example, seventy percent accepted without edits, and half the current handling time. If the prototype reaches them, expanding is justified; if it half-reaches them, the gap shows exactly what the second iteration must fix.
Budget for the boring half of the project
Half of any working AI system is unglamorous plumbing, and the plan should say so. Set aside time for an evaluation set: labelled examples kept apart from development and used to score every change. Plan who owns the system after the pilot ends, how quality will be watched in the first month of real use, and how often prompts or the model will be re-checked as the work shifts.
Then close the project with a one-page decision memo: what was built, what it scored against the baseline, what it costs per month to run, and a recommendation: expand, pivot, or stop. The memo sounds bureaucratic; it is what turns a demo into an organisational decision.
Decide in advance when to stop
Write a kill criterion while everyone is still optimistic: if, after two full iterations, quality is still below the baseline, the project stops and the team picks a different workflow. That is not pessimism — it is the discipline that prevents zombie pilots from consuming a year of attention. Teams that plan honestly for a possible stop can afford to test several — which is how the one worth scaling eventually gets found.
A first AI project with a small team is mostly an exercise in restraint: one workflow, six weeks, a measured baseline, and a written definition of done. Get those four right and the technology is usually the easiest part.
