The problem
The AI project gets approved on a slide and then spends six months becoming a demo that runs on a laptop. Nobody set a date for the first version to run on real data, so it never does.
What goes wrong
- Scope grows. The build starts with one workflow and ends with four, none of them finished, and the date moves every time a new one is added.
- The demo avoids production. It runs on a sample file with a test login and skips the integration that was hard, so the hard part is still waiting.
- Nobody owns it. The first version goes live, no one on your side is accountable for it, and it quietly stops being used within a month.
The approach
- Start with the 10-day assessment. Working with your team, we deliver an AI inventory, risk tiers, the top 3 workflows with today's numbers and a 90-day plan.
- Start the build with one use case and a named owner on your side before the first line of code.
- Connect to your real systems and real data first, because that is where the hard part lives. No sample files, no test logins, no integration left for later.
- Put an approval, owned by a named person, in front of every action that moves money, contacts a customer, or changes production. Log every action. Hand over the runbook and credentials on the day it goes live.
When it works
It works when there is one workflow with a number attached, a person on your side who owns it, and systems we can reach from the start. It does not work when the first version needs five integrations before it does anything, or when the goal is a platform rather than a workflow.
Why a first version
Most AI projects die in the gap between the slide and the first working version. The slide gets approved. Then the scope grows, the data is messier than anyone said, and six months later there is a demo on a laptop and nothing in production. A narrow first version closes that gap on purpose.
How it runs
The build starts after the assessment, not instead of it. The assessment is 10 days: with your team in the room, we deliver an AI inventory, risk tiers, the top 3 workflows with today's numbers and a 90-day plan.
Then the build starts. One use case.
Connect
We connect to the systems the workflow actually runs on: the store, the inventory feed, the inbox, the CRM, with access you grant and can revoke. The hard integration happens first, because that is where the surprises are and we want them early.
A first version in front of people
The first version runs on your real data and the people who will use it see it. Not a deck about it. They use it beside their current process and tell us what is wrong. Every correction becomes a rule or a fix.
Corrections and controls
We work through the corrections and put the controls in place. An approval owned by a named person sits wherever the system would move money, contact a customer, or change production. Every action is logged so you can see what ran and why. A fixed set of real cases is re-run after every change.
Live, owned, handed over
The first version goes live on accounts you own, with credentials you hold. Your named owner runs it. We hand over a written runbook on the day it goes live.
What a first version is
Some teams call it an MVP, a minimum viable product: the smallest version that does real work for real users. A first version is not a prototype. It runs on your data, on accounts you own, and named people use it for real work. Turning it off would make someone's week worse.
It is also deliberately narrow. For a consumer brand, that might be one agent on the storefront that answers product questions and hands warm buyers to checkout, or one workflow that drafts the restock request when stock crosses your threshold. Not both. The second comes after the first has earned it. For a manufacturer, it might be one workflow that reads customer POs into the ERP.
What you get at go-live
- The first version, live on accounts you own, with credentials you hold.
- A written runbook: what it does, what it needs, and who runs it.
- The approval rules and the action log.
- The fixed set of real cases it is tested against, so your team can re-run them.
- The written list of requests that did not make this build, ready for the next one.
When it does not work
It does not work when the first version needs five integrations before it does anything: that work goes to a forward-deployed pod instead, measured at day 90 or 120. And it does not work when the goal is a platform rather than a workflow.
Where it starts
The paid 10-day assessment is where this build starts, and where every other build or pod starts too. For a straight answer before that, ask Roo, Webaroo's AI: What would a first version of our AI workflow look like? AI product development covers the build that follows a first version.
