The first 30 days of an AI project

Most of the risk in an AI project is visible early, if you go looking for it. Can we get the data? Is it good enough? Does the approach work on real cases? Will anyone actually use the result? The first 30 days are for answering those questions with evidence instead of opinions, so the decision at the end is easy to make.

A month is long enough to test an idea on real data and short enough that stopping is cheap. It forces the hard questions to the front, where they belong.

Here’s what that month looks like when we run it.

Week 1: Discovery

We start with people, not models. We meet the stakeholders who own the outcome, the experts who do the work today and the team that runs the systems involved.

• Goals: what changes for the business if this works, and how we’ll measure it.
• Constraints: budget, deadlines, compliance requirements and the systems we can’t touch.
• Stakeholders: who decides, who will use it and who will support it after launch.
• Data access: what exists, where it lives and which approvals we need to reach it.

We also ask what has been tried before. Earlier attempts, even failed ones, are often the fastest way to learn where the real problems are.

Access approvals can take time, so we start them on day one.

Week 2: Assessment and a written plan

With access in hand, we look at the real data: its quality, its gaps and how it changes over time. We measure how the current process performs, so there’s a baseline to beat, and we test the riskiest assumptions first. If the data can’t support the idea, this is where we say so: it’s far cheaper to change course in week 2 than in month six.

The week ends with a written plan: the approach, the architecture, what the prototype will and won’t do, how we’ll judge it, and the risks we can already see. It’s short enough to read in one sitting and specific enough to disagree with.

Weeks 3–4: A working prototype on your data

Then we build. Not a slide deck or a mock-up, but a working prototype running on your real data and shaped like the production system it could become. It handles the core job end to end, even if some edges are still rough.

• We demo progress every week, to the people who will actually use it.
• We evaluate it against the baseline and the bar we agreed on in week 2.
• We keep a running list of what production would need: integrations, security, monitoring and support.

By the end of week four, the people who will use the system have already tried it, and their feedback has shaped what gets built next.

Day 30: A decision

At the end of the month you have three things: a prototype you’ve seen working on your own data, results measured against a bar you agreed to, and a clear view of what production would take in time and cost. The decision is then straightforward:

• Go to production: the prototype cleared the bar and the path is clear.
• Adjust: the idea holds, but something has to change first, such as the scope, the data or the approach.
• Stop: the evidence says it isn’t worth it, and you found out in a month instead of a year.

Whichever way it goes, you decide with evidence in hand rather than a hunch.

Stopping at day 30 isn’t a failure. Finding out a year later would have been.

What we need from you

A month moves quickly when a few things are in place: a decision-maker who can make calls fast, someone who can unblock access to data and systems, and a few hours each week from the people who know the work best. Their judgment is the difference between a prototype that impresses and one that’s genuinely useful.

If any of these are hard to arrange, tell us early. We would rather plan around a constraint than discover it in week three.