Most AI projects don't fail because the technology doesn't work. They fail because nobody agreed on what it was supposed to do.
The brief was vague. The scope kept shifting. The developer built what they understood, which was not quite what the client meant, which was not quite what the client's team actually needed. Six months later, something technically functional exists and nobody quite uses it.
This is the most common failure mode in AI implementation. And it is almost entirely preventable.
The problem with vague briefs
When someone commissions a build without a clear specification, decisions get made informally throughout the project. The developer makes choices. The client gives feedback mid-build. The scope shifts. What started as one thing ends up as another.
In standard software development, this is expensive and frustrating. In AI development, it is worse.
AI systems have more variables than standard software. The model, the prompts, the context, the output format, the edge cases, the verification steps: each one is a decision that needs to be made deliberately. When those decisions get made informally, mid-build, the result is a system that is hard to iterate on, hard to explain to the team, and hard to know if it is working correctly.
The specification is what prevents this.
What a spec actually is
A specification is not a 50-page technical document. It does not take months to produce. It is not the same as a lengthy requirements brief from a corporate IT project.
A working AI specification covers five things:
- The workflow being automated (the current state, step by step)
- The desired output (what should come out, and in what format)
- The edge cases (what happens when inputs are unusual or incomplete)
- The success measure (how will we know this is working)
- The human checkpoints (where does a person review the output before it is acted on)
That is it. A clear answer to those five things is enough to build from. Without them, every decision during the build is a guess.
Why we do not start without one
We have declined projects where a client could not answer these questions. Not because the project was uninteresting, but because building without a spec wastes everyone's time.
Without a spec, a build does not have a definition of done. Every client review surfaces new requirements. Every iteration changes direction slightly. The project runs over time and budget, and the output at the end may be further from what the client actually needed than what existed at the start.
A specification gives the project a spine. It says: this is what we are building, this is what done looks like, and this is how we will know when we get there. Everything else is a deviation from the spec, which becomes a conversation, not a surprise at handover.
Path A: you already have a spec
Path A is for clients who arrive with a specification already written.
This is common for clients who have completed an AI audit, have a technical team that has mapped the workflow, or simply have a clear enough picture of what they need that they can write it down.
The process is straightforward. You share the spec, we review it for feasibility within a day or two, we agree on scope and timeline, and we build. No extended discovery phase, no lengthy back-and-forth before a line of code is written.
The spec review is not just a sign-off. We push back where the spec has gaps. We flag edge cases that have not been addressed. We point out where a desired output does not match what is technically achievable at the stated budget. But the review takes days, not weeks, because the hard thinking has already been done.
Path B: you have a problem, not a spec
Path B is for clients who know the outcome they want but have not mapped the path to it.
"We want to stop doing X manually" is a clear business goal. It is not a specification. To build from it, we need to understand what X actually involves: the inputs, the steps, the outputs, the decisions inside the process, the exceptions that come up regularly.
The scoping phase does that work. It typically takes one to two weeks. We talk to the people who currently do the process. We map it step by step. We identify where AI can genuinely help and where human judgment still needs to stay in the loop. At the end, we produce a specification.
You approve the spec before any build begins. If it does not match what you had in mind, we revise it. If the scope turns out to be different from what you expected (smaller or larger), we update the price and timeline before proceeding.
Nothing gets built until you have confirmed exactly what is being built.
What the spec protects you from
A specification that both sides have agreed to does three specific things.
It stops scope creep. When a new requirement comes up mid-build, the spec is the reference point. Is this in scope? If yes, we build it. If no, we discuss whether to add it, at what cost, before any work starts. There are no surprises at the end.
It makes done mean something. Without a spec, done is a negotiation at handover. With a spec, done means the spec has been delivered. The handover is clean and both sides know it.
It prevents the wrong thing being built. This is the most important one. A spec you have approved means the thing being built is the thing you agreed to. If the output does not match the spec, that is a bug we fix. If the output matches the spec but is not quite what you wanted, that means the spec needs updating. We have a clear conversation about what to change and what it costs, not a argument about who was right.
A note on the scoping fee
Path B clients pay for the scoping phase before the build is priced. This is intentional.
Scoping is skilled work. Understanding a workflow, identifying the right AI approach, mapping edge cases, writing a spec that will actually hold up during a build: this takes real effort and real expertise. We charge for it because it is valuable in itself.
There is also a practical reason. Clients who have paid for scoping are serious. The scoping session is focused and productive. The spec that comes out of it is better. The build that follows it is faster.
If you proceed to the full build, the scoping fee is credited against the total cost.
The rule is simple
We build what the spec says. We build when the spec is approved. We do not build on a brief, a conversation, or a slide deck.
This is not inflexibility. It is how we protect the quality of what we produce, and how we protect you from the most common way that AI builds go wrong.
If you have a spec ready, bring it to Grapine Build and we will review it within 48 hours. If you have a problem but not a spec, the scoping phase is where we start. Either way, nothing gets built until the spec is right.