AI Roadmap in 90 Days — From Discovery to a Production Pilot

"We want to get started with AI, but nobody dares to take the first step." We hear this in almost every initial conversation with SMB executives — and it describes the real problem precisely. The question is rarely whether AI can deliver value for the business, but how to set up the first productive pilot within a manageable timeframe and budget, without getting lost in a multi-year strategy discussion. Across more than two dozen pilot projects with German SMBs, a 90-day rhythm has proven to be the most robust framework for us: long enough to deliver substantial value, short enough to sustain the attention, budget, and energy of everyone involved. This article shows what such a 90-day roadmap looks like in practice — from Day 1 Discovery through Day 90 production pilot — including real-world pitfalls, KPIs for each phase, and an honest look at what is and is not achievable within this timeframe. For the broader context we recommend the overview article on AI Strategy for SMBs.

Why 90 Days Is Realistic

Three quarters, twelve months, or two years — many AI consultancies sell programs that are unnecessarily drawn out. In our experience this is a systematic mistake, for three reasons. First: attention is the scarcest resource in an SMB. Executives who personally sponsor a pilot project sustain that attention for three months. Anyone who takes longer gets their final review in a half-empty steering committee. Second: technology stacks in the AI space move fast. A twelve-month plan that starts in January with GPT-5 runs into a completely different world by December — new models, new pricing, new vendors, new regulatory requirements. Third: the learning effect of a short, clear iteration is higher than that of a long, vague plan. A 90-day pilot forces real decisions.

90 days is realistic, however, only under clear conditions. We are talking about a single use case, a manageable user group of ten to fifty people, available data in acceptable quality, and a committed stakeholder constellation with clear ownership. Anyone planning an enterprise-wide rollout, a custom model with proprietary training, and three use cases in parallel in 90 days has misunderstood the framework. The roadmap described here is a 90-day roadmap for exactly one pilot — the second and third wave follows afterward, with the advantage that internal experience, tooling, and governance are already in place.

One observation from practice: across the projects we have run with this model, the average time to first measurable impact for end users was 67 days, and the time to formal pilot sign-off was 86 days. This is not magic, but the result of discipline: every day has a defined goal, every week has a fixed review point, and every phase has a handover point with clear acceptance criteria.

Days 1 to 30 — Discovery

The first thirty days determine the success or failure of the entire pilot. In this phase the focus is not on technology but on three classic consulting disciplines: use case definition, data review, and stakeholder mapping. Anyone who completes these three building blocks cleanly has already done the hardest work of the entire 90 days.

Use Case Workshop. In the first or second week we facilitate a full-day workshop with three to seven people from the business and IT departments. The goal is a list of eight to fifteen potential use cases, ranked by estimated value contribution, data availability, complexity, and political sensitivity. From this list exactly one use case is selected — not two, not three. The selection is a management decision because it determines the budget for the next 60 days. Typical candidates in SMBs are proposal generation, supplier correspondence, technical documentation, service request triage, or internal knowledge search.

Data Review. In weeks two and three we examine the data relevant to the selected use case: completeness, currency, structure, access rights, and data protection implications. This review is often uncomfortable because it surfaces unspoken data quality problems. It is, however, essential, because AI running on dirty data produces plausible but incorrect results. If the data review raises red flags, the honest path is to shift the pilot to a use case with a better data foundation, or to schedule a four-to-eight-week data preparation phase upfront — this extends the roadmap to 120–150 days, which is healthier than a failing pilot. For deeper coverage see our cluster on GDPR-compliant AI use.

Stakeholder Mapping. In parallel we establish who plays what role in the organisation: an executive sponsor, a business owner, a technical lead, a data protection contact, a works council representative, and selected end users for the pilot group. One name, one point of contact, and a time budget per role. This mapping is not bureaucracy for its own sake — it is the foundation that ensures that on Day 65, when the first end users give feedback, the right person makes the right decision immediately.

The discovery phase concludes with a two-page brief: the use case in one sentence, success criteria in three to five KPIs, data inventory and gaps, stakeholder list, estimated effort for phases two and three, and a data protection assessment. This brief is formally approved by management in a steering meeting on Day 30 — or the project is cleanly stopped here, which is far better than a pilot without a mandate.

Days 31 to 60 — Pilot Build

With the approved brief, the build phase begins. The goal is a functional MVP — a Minimum Viable Product — that a small pilot group can use in real working situations. The phase is divided into three blocks: tooling selection, build, and data protection setup.

Tooling Selection on Days 31 to 35. Within the first week of this phase we define the technology stack. This is a far-reaching decision that we deliberately keep short — five days, not five weeks. The selection is guided by the chosen use case, existing licenses, data protection requirements, and internal know-how. For SMBs, the pragmatic choice is often a combination of Microsoft Copilot or ChatGPT Enterprise for standard use cases, supplemented by specialised vendors for industry-specific requirements. A comprehensive overview of vendors can be found in our AI Tools Comparison 2026.

MVP Build on Days 36 to 55. The actual build runs for three weeks. During this time a usable system is created for the pilot group: integration into the existing work environment, connection to the relevant data sources, a simple frontend or plugin, and basic logging functions. What matters is staying within the boundaries of what the pilot group truly needs — no fully developed admin interfaces, no SSO integration with every shadow-IT application in the building, no complete role model. All of that comes in phase three or in the scaling project after Day 90.

Data Protection Setup on Days 50 to 60. In parallel with the MVP build we establish the data protection foundation: a data protection impact assessment, data processing agreements with the tooling vendor, technical and organisational measures, notification to the works council, and training materials for the pilot group. This work is thankless because it produces nothing visibly productive — but it is essential, because a pilot without a data protection foundation will be blocked at the latest when scaling. Cutting corners here burns your roadmap.

The build phase ends on Day 60 with a formal MVP sign-off: the system is running, the pilot group has access, the data protection documents are signed, and the steering committee approves. If important components are missing at this point, it is better to extend the build phase by two weeks and shorten the pilot phase accordingly — launching an incomplete MVP produces only frustration and poor KPIs.

Days 61 to 90 — Testing and Scaling

The final phase is the proof of concept. The MVP is built, the pilot group is using it, and now the goal is to collect reliable data over thirty days, iteratively improve the system, and lay the groundwork for the scaling decision. The phase is divided into three sub-blocks: test run, iteration cycles, and scaling preparation.

Test Run on Days 61 to 70. In the first ten days the system runs under real conditions. The pilot group works with it, logs are collected, and short feedback sessions take place twice a week. Importantly: during this time we deliberately change as little as possible in the system, because we need clean baseline data. Anyone who constantly patches in week one cannot later say which improvement was caused by what.

Iteration Cycles on Days 71 to 85. With the first two weeks of data, targeted iterations begin. Typical levers are prompt optimisation, connecting additional data sources, adjusting response formats, and correcting misunderstood use cases. Each iteration runs in a clearly bounded mini-cycle of two to four days with a hypothesis, a change, and a measurement. This is methodologically classic product development — nothing AI-specific, but unfamiliar in many SMBs.

Scaling Preparation on Days 81 to 90. In parallel with the final iterations, the decision document for scaling is prepared. It contains: target vs. actual KPI comparison, identified obstacles, estimated effort for scaling to one hundred, five hundred, or one thousand users, licence cost projections, risk assessment, and a management recommendation. On Day 90 a closing meeting decides: scale, sharpen further, or stop. All three options are legitimate — a pilot that has not demonstrated its value should be honestly stopped rather than pushed into production out of pride.

Pitfalls from Practice

Across multiple pilot projects, three pitfalls have emerged as the most common reasons why 90-day roadmaps go off track — and they have surprisingly little to do with technology.

• Internal PoliticsThe most common killer of SMB AI pilots is not the technology but internal resistance: departments unwilling to open up their data, managers who do not want their area scrutinised, IT staff worried about their own standing. The effective countermeasure is a clear mandate from management, a visible sponsor, and honest communication that the goal is augmentation and relief — not replacement.
• Data QualityData is more poorly structured in almost every SMB than the IT department assumed at the last planning offsite. Scattered spreadsheets, half-maintained CRM records, duplicate customer master data, and knowledge silos in email inboxes are the norm. The pilot must deal with this — either through use case selection with a good data foundation or through an honest data preparation phase.
• Skill GapInternal teams rarely combine domain expertise, AI experience, and data protection knowledge simultaneously. The pragmatic solution is a mixed setup: an internal business owner plus an internal IT lead plus an external support team with clearly defined weekly hours. Anyone working purely in-house needs senior capacity — and that is rarely available in an SMB.
• Expectation ManagementExecutives who perceive AI as magic through public coverage come into the pilot with inflated expectations. Realistic KPIs set during the discovery phase are the antidote — a pilot that saves 15 minutes per employee per day is a success, not a failure.
• Vendor Lock-in CostsAnyone who ties the stack too tightly to a single vendor pays double when switching. Modular architectures with an interchangeable model layer and clean interfaces reduce the risk without materially slowing build speed.

KPIs per Phase

Reliable steering requires KPIs that are appropriately chosen for each phase. What you measure in Days 1 to 30, Days 31 to 60, and Days 61 to 90 is different — applying the same KPIs across all phases means optimising for the wrong target.

Phase	KPI	Target
Discovery (Days 1–30)	Use case selection made	1 use case by Day 14
Discovery (Days 1–30)	Data availability assessed	Written assessment by Day 22
Discovery (Days 1–30)	Stakeholder mapping complete	All roles filled by Day 25
Build (Days 31–60)	MVP readiness	Pilot group using it by Day 58
Build (Days 31–60)	Data protection impact assessment	Signed by Day 55
Build (Days 31–60)	Pilot group training	100% trained by Day 60
Test (Days 61–90)	Active usage rate	Over 60% of pilot group weekly
Test (Days 61–90)	Value contribution metric	Use-case-specific, e.g. processing time –20%
Test (Days 61–90)	Scaling decision	Document by Day 88, decision by Day 90

The KPI table is not an end in itself but a steering tool. Every row belongs in the weekly status report, and every target is communicated openly. Anyone who hides KPIs because they are uncomfortable has a culture problem that will not disappear after a successful pilot. For detailed coverage of financial measurement see Calculating AI Costs and ROI.

Reepa Support

We support 90-day roadmaps in two configurations. In the full support model we handle workshop facilitation, technical architecture, build guidance, data protection setup, and steering communications — the effort is approximately 35 to 60 person-days spread across the 90 days, scaled by use case complexity. In the sparring model the company provides the build team and we deliver workshop facilitation, architecture review, KPI setup, and escalation backup — approximately 12 to 25 person-days. Which model fits becomes clear during the discovery phase.

Our strength lies in combining AI technology with classic project methodology and cybersecurity expertise. Data protection and security aspects are often the real blockers in German SMBs — and this is precisely where our experience from the cybersecurity business comes to bear. An AI pilot that fails its first data protection audit is an expensive lesson we want to spare our clients.

Frequently Asked Questions