Write a clear spec for your project — free.
Most projects do not fail in the build. They fail at the spec — where the problem is defined too vaguely to ever solve. Define it well first, and the rest gets a lot easier.
Why most projects fail before a line is written
Modern AI has made output cheap. Producing a draft, a summary, a first-pass answer is now nearly free and almost instant. That collapses the old bottleneck — and moves all the leverage upstream, to the input.
The input is the real work. The value was never in raw generation; it is in structuring the messy, judgement-heavy input: the requirements, the assumptions, the edge cases, the data, the definition of done. A team that skips straight to building skips exactly the part where the value lives — and ships an impressive demo that solves nothing real.
So a good project spec is not paperwork. It is the work. Get the problem defined sharply and the output mostly follows. That is what the dimensions below — and the free tool further down — are built to help you do.
How to define an project well
A spec that a team can scope, price and build against covers nine dimensions. Most weak AI briefs are missing three or four of them — usually the data, the stakeholders, and the success metric.
ICP — who it is for
Name the exact person whose work changes. "Our delivery leads" is sharper than "our team". A spec written for everyone is a spec for no one.
Problem dimensions
What specifically breaks today, and what it costs. Be concrete: the missed deadline, the under-priced deal, the hours lost — not "things are inefficient".
Segments
Which slices or cases differ. Most workflows have edge cases that behave differently; a spec that ignores them ships a tool that only works on the happy path.
Feature set
What the solution would actually need to do — the capabilities, not the UI. Distinguish must-haves from nice-to-haves so scope is honest from day one.
Stakeholders
Who is involved, who approves, who is affected. projects stall on the approver nobody mapped. Name them in the spec.
Current workflow
How the work is done today, step by step. You cannot automate or augment a process you have not written down. The steps reveal where AI actually helps.
Data and systems
Where the data lives and which systems the workflow must touch — CRM, billing, the data warehouse. An output that cannot reach a system is a demo, not a result.
Volume and frequency
How often, and at what scale. A workflow run twice a quarter and one run ten thousand times a day are different projects with different specs.
Success metric
The single number or outcome that proves it worked. Without it, the project has no finish line and no way to tell a win from a nice demo.
Turn your idea into a sharp spec — below.
Use the free AI intake below to turn a rough "we should use AI for X" into a structured Problem Brief. It asks one question at a time, sharpens the problem across the dimensions above, and hands you a brief you can download as a PDF or take straight into a call.
No sign-up, no charge. It is a working taste of how we scope a real engagement — the input is the real work, and we help you define the problem better than you could alone.
AI Intake
Scoping assistant · one question at a time
Writing an project spec
How do I write a spec for an project?+
Start from the problem, not the technology. Write down who the project is for, what specifically breaks today and what it costs, how the work is done now step by step, what data and systems are involved, and the one metric that would prove success. The hardest part is not the prose — it is defining the problem precisely. Use the free AI intake on this page to turn a rough idea into a structured brief by answering one question at a time.
What should an project brief include?+
A good project brief covers nine dimensions: the ICP (who it is for), the problem dimensions (what breaks and the cost), the relevant segments or edge cases, the feature set (what it must do), the stakeholders (who approves and who is affected), the current workflow, the data and systems it touches, the volume and frequency, and a clear success metric. Capture those and you have a spec a team can scope and build against.
How do I define requirements for an AI feature?+
Define requirements by describing the outcome and the constraints, not the model. State what the feature must do, the inputs it receives, where its output has to land, who reviews or signs off, and what "correct" means for your case. Requirements that name the data, the approval step, and the success metric are far more buildable than a one-line "add AI to X".
Why do so many projects fail at the spec stage?+
Because output is now cheap and input is the real work. Modern AI makes producing a draft almost free, so the bottleneck moves upstream to defining the problem: the messy requirements, the assumptions, the edge cases, the success metric. Teams that skip straight to building skip the part where the value actually is — and end up with an impressive demo that solves nothing real.
Is the AI intake tool free?+
Yes. The intake on this page is free to use and asks you one question at a time to sharpen your idea into a Problem Brief you can download as a PDF or take into a call. There is no charge and no obligation to engage us afterwards.
Want to see the framework applied to a live workflow? Explore our AI services.