Short answer
Start with the work, not the technology. Spend month one finding a task your people do often, that has a checkable right answer, and where a mistake is recoverable. Ship exactly one use case to production in month two. In month three, measure hours returned — then expand it, hold it, or switch it off.
Key takeaways
- Choose the task before the tool. The first month is research, not procurement.
- One use case in production beats five pilots stuck at eighty per cent.
- Test on your messiest real files from day one, never on a curated sample.
- A human approves everything that leaves the building, and every correction is logged.
- At day 90, decide in writing: expand, hold, or stop. All three are legitimate outcomes.
Most AI programmes in mid-size companies do not fail because the technology did not work. They fail because nobody could say, three months in, what had actually changed. A pilot ran, a demo impressed somebody, a licence was bought, and then the thing quietly stopped being used because it never became part of how the work gets done.
This is a plan for the first ninety days, written for a company of roughly fifty to five hundred people that has not deployed AI in anger yet. It assumes you have no data science team, no AI budget line, and a lot of other things to do. All three of those are normal and none of them is a blocker.
Days 1–30: find the work, not the technology
The instinct is to start by choosing a tool. Resist it. The first month is spent finding out where your people actually lose time, and the answer is almost never where the executive team assumes it is.
Sit with four or five people in different roles for an hour each and ask one question: what did you do yesterday that you resented doing? Not what is hard — what is repetitive, mechanical, and requires you but does not deserve you. Write down what they say verbatim. You are looking for tasks with three properties: they happen often, they follow a pattern, and getting them slightly wrong is recoverable.
- 1Frequency beats importanceA task that happens forty times a week and takes eight minutes is worth more than a task that happens twice a month and takes a day. Automate the forty. The twice-monthly task is where your experienced people should be spending their judgement anyway.
- 2Pick work with a clear right answer"Does this order match the drawing?" has a right answer. "What should our pricing strategy be?" does not. Start where you can tell, unambiguously, whether the output was correct — otherwise you will never know if it is working.
- 3Avoid anything where a mistake is expensive and invisibleThe worst first project is one where errors are rare, costly, and only surface months later. You want fast feedback, and you want the cost of being wrong to be an annoyance rather than a nonconformance report.
Days 31–60: one use case, in production, with real data
Pick exactly one. Not three, not a portfolio. One use case, taken all the way to people using it for real work, is worth more than five pilots that all reach eighty per cent and stop.
Run it on your own messy data from day one. Not a curated sample, not the clean examples from the vendor's demo — the actual inbox, the actual drawings your customers send you, the actual product descriptions with the typos in them. Systems that work on tidy data and collapse on real data are the single most common reason a promising pilot never ships.
Two rules for this month. First, a human approves everything that leaves the building — no exceptions, no matter how good the accuracy looks. Second, log every correction. Those corrections are the most valuable dataset you will produce this year, and almost every company throws them away.
Days 61–90: measure honestly, then decide
At the end of the quarter you need a number and a decision. The number is not "accuracy" — accuracy on a benchmark tells you nothing about your business. The number is time or money: hours returned to a named team, or errors caught before they became cost.
| Measure this | Not this |
|---|---|
| Hours a named team got back per week | Model accuracy on a benchmark |
| Errors caught before they reached a customer | Number of documents processed |
| Share of outputs a human accepted unchanged | Number of people with a licence |
| Time from request to usable answer | Number of pilots running |
Then make one of three decisions, in writing: expand it, keep it running as it is, or turn it off. "Turn it off" is a legitimate and underused outcome. A company that can kill an AI project in ninety days will try five things a year. A company that cannot will spend three years on its first one.
What to do in parallel, at almost no cost
- Write down, on one page, what data may leave your infrastructure and what may not. You will need this the moment a vendor conversation gets serious, and writing it under deadline produces bad policy.
- Get five people trained well rather than fifty trained badly. The bottleneck in year one is never model capability; it is the number of people who can tell a good output from a plausible one.
- Tell the organisation what you are doing and why. Silence gets filled with the assumption that this is about headcount, and that assumption will cost you the cooperation you need.
The companies that get somewhere with AI in the first year are not the ones with the best technology. They are the ones that picked a boring problem, measured it properly, and were willing to switch it off.
After the first ninety days
If the first project worked, the second one is easier and the third one is easier still — not because the technology improved, but because you now have people who know how to specify, test and correct this kind of system. That capability compounds. The tooling does not.
In short
Ninety days is enough to learn whether AI helps your company, provided you spend the first thirty finding the right problem instead of shopping. The teams that get somewhere in year one are rarely the ones with the best tooling — they are the ones that picked a boring, checkable task, measured it honestly, and kept the right to switch it off.
Frequently asked questions
How long does it take to implement AI in a small company?
Published timelines run from about a week for configuring an off-the-shelf tool to six months for custom work. Plan 90 days minimum for a first use case that matters: roughly 30 days to deploy it properly and 60 to find out whether the results hold once real work goes through it.
How much does a first AI project cost?
2026 benchmarks put first-year AI spend for a company of 10–50 people at roughly $5,000–40,000 where the work is SaaS configuration and light automation, rising to $30,000–100,000 for complex custom workflows. Our own pilots start at €3–4k and a typical implementation is €12–18k, because the cost sits in integration and rules rather than licences.
Do we need a data scientist to start?
No. For a first project the binding constraint is not model capability, it is having a few people who can tell a good output from a plausible one. Train five people well rather than fifty badly, and hire specialists only once you know which problem you are solving.
What if our data is messy?
Everybody's is. That is the argument for testing on it rather than against starting. The systems that fail in month three are the ones evaluated on a clean sample, so make your worst files part of the selection process instead of something you discover later.
Should we build or buy?
Buy anything commoditised — drawing checks, transcription, summarising. Build or integrate only where the value comes from something specific to you: your templates, your specifications, your ERP. Building a commodity is the most expensive way to learn it was a commodity.
What makes a good first use case?
High frequency, a verifiable right answer, and a recoverable mistake. A shared inbox, incoming quotation requests and document checking all qualify. Anything where errors are rare, expensive and only surface months later does not.