Getting started
Where to start with enterprise AI
A first project should not be the most technically impressive one but the one whose result is most clearly measurable. Chosen well, it produces a number within eighty days, and that number unlocks the next budget. Chosen badly, it leaves a demo nobody can defend six months later.
- Published
- Built by
- Zero-Shot Team
- 3 min read
Criteria for the first project
Four questions are enough. How much time does this task take, and from how many people? Can the result be measured with a number? Is the cost of a wrong output tolerable? And do you already hold the data?
A task with a clear answer to all four is a good start. If any answer is 'we don't know', answering that question is the real project.
The most common mistake is picking the most visible task. A demo that impresses the board and a system that earns money are frequently not the same thing.
What good starting projects look like
Repetitive work whose rules are unwritten but where an expert can say 'this is right, this is wrong'. Extracting fields from incoming documents, routing support tickets, answering questions over a long archive, drafting text.
What these share: a wrong output can be caught and corrected. The system does not have to be perfect; shortening a person's work is enough.
Weak choices for a first project: autonomous systems that speak directly to customers, flows that make irreversible decisions, and tasks whose data has not been collected yet.
The first eighty days
The first two weeks go to measurement: establishing today's number and building an evaluation set of fifty to two hundred cases. Skip this and the project ends with no answer to 'did it get better'.
Weeks three and four produce the first working version. Narrow scope, one flow, real data. The goal is not to impress but to see it run end to end.
The rest goes to two things: adding failures to the set and fixing them, and placing the system inside the workflow of the people who will use it. The second is routinely underestimated; most technically finished projects die there.
What has to be delivered
A working system alone is not a delivery. Alongside it: the evaluation set, the prompts, the code, the data pipeline and a short document describing when the system gets things wrong.
Without those, the system becomes an unmaintainable box within three months. When the provider changes a model version, nobody can say what broke.
When to move to the second project
When the first produced a number. 'Sixty percent of support tickets now close on first contact' is the sentence that unlocks the next budget.
Moving on without one leaves three half-finished systems in the organisation, and by the fourth proposal nobody is convinced.
In short
- Choose the first project for measurability, not visibility.
- Four questions: whose time, which number, cost of being wrong, is the data already here.
- The first two weeks go to measurement — today's number and the evaluation set.
- Delivery is more than the system: the set, the prompts, the code and a written note on its limits.
- Move to a second project only after the first produced a number.
Common questions
- Should we build in-house or bring someone in?
- On a first project outside help speeds things up, because the delay is the learning curve. But do not start without a handover plan: who maintains the evaluation set and the prompts should be settled on day one. A setup that creates permanent dependency looks cheap in year one and expensive in year two.
- Our data is a mess — should we fix that first?
- Usually no. Cleaning all of it is a multi-year effort with no end. Cleaning the data one narrow task needs takes weeks, and by the end of that task you also know what was worth cleaning.
- How much budget should we set aside?
- For a first project the right question is duration, not budget: if no measurable result appears within eighty days, the scope was drawn too wide. Narrowing scope works more often than increasing budget.