What a first AI project actually looks like

The largest reason first AI projects fail is not technical. It is that nobody agreed what success was, so the project could not end. This is the shape that avoids that.

Before anything is built

Scoping

We start with how the work is done today, not with what the technology could do. Who does it, how long it takes, what happens when it goes wrong, and what a wrong answer actually costs. That last question decides most of the design.

The output of scoping is one sentence describing the task, and a number describing acceptable performance. If we cannot write both, the project is not ready and building would be premature.

Data review

We ask for real examples. Twenty or thirty actual documents, a few hundred actual messages, whatever the work runs on. Not curated samples.

This is not a formality. Data condition is the largest single cost driver on almost every project, and it is where quotes given without looking turn out to be wrong. Sometimes the review finds that the data is not in a state to support the project at all, and the right advice is to fix that first. See why your data is the hard part.

The quote

A fixed scope and a fixed price, with running costs stated separately so you know what it costs to own as well as to build. Priced per project rather than per month, because a build has an end and charging monthly for something that finishes creates the wrong incentive on both sides.

The four things that move the price

Any vendor quoting without asking about all four is guessing. You are entitled to ask which of them is driving your number.

What the weeks look like

1. Scoping and data review. Conversations and a look at real examples. Ends with a written scope, a definition of working, and a quote.
2. The narrow build. The smallest version that does the real job on real data. Not a demonstration, not a prototype you throw away.
3. Review on working software. You use it, on your own material. Feedback comes from something running rather than from a document describing what will run.
4. Measurement. Performance against the number agreed at the start, on examples the system has not seen. This is the moment the project either succeeded or did not.
5. Parallel running. Alongside the existing process, so nothing is at risk while you find out whether it holds in ordinary conditions.
6. Handover. Code, prompts, artefacts, data and documentation, written so another developer can take it on without us.

What you get at the end

• A working system, doing one job properly.
• The source code and the prompts, which are yours.
• The data and any artefacts produced along the way.
• Documentation written for a developer who has never met us.
• A measured accuracy figure and the test set it was measured on, so you can check it again in six months.
• The running costs, in writing.

That fifth item is the one people forget to ask for, and it is the one that protects you. Without the test set you cannot tell whether the system has degraded, and you are back to trusting rather than knowing.

What "done" means

Done means the agreed task performs at the agreed level on data it has not seen, it is running where the work happens, and someone other than us could maintain it. It does not mean the system is finished forever, and it does not mean you are committed to a second phase.

A first project should be small enough that being wrong about it is survivable, and real enough that being right about it is useful.

Reasonable things to insist on

• A written definition of working, agreed before the build. Without it there is no way to say whether the project succeeded.
• Ownership of everything at handover. Code, prompts, data, artefacts.
• A stated failure mode. What the system does when it does not know. If the answer is that it always produces something, that is a design flaw.
• Running costs separated from build costs.
• Documentation as a deliverable, not a favour if there is time.

There is a longer list of questions to put to any vendor in buying AI in Algeria: what to ask before you sign.

And the outcome we sometimes reach

Occasionally scoping ends with the conclusion that the project is not worth doing: the volume is too low, a simpler tool solves it, or the data is not there yet. We say so, and there is no charge for reaching that conclusion. Turning down a project costs us one invoice. Delivering one that gets abandoned costs the relationship and every referral behind it.