Scope before you build

Most AI projects that stall don’t stall because the model wasn’t good enough. They stall because nobody ever pinned down what the system was actually supposed to do. “Add AI to our product” is not a scope. It is a mood. And a mood cannot be built, tested, or finished.

The projects that ship have something the stalled ones don’t: a tight frame. A specific input, a specific output, a measurable definition of right, and an explicit statement of what the system will not do. Get those four things and the build is mostly mechanical. Skip them and you will demo forever and ship never.

What a tight frame looks like

When I built InferLens, the scope was not “understand documents.” It was: answer a question about one uploaded document, and cite the exact page each claim comes from. One document. Questions in, cited answers out. Right means the citation supports the claim. That frame is small enough to evaluate and small enough to finish, and it is still genuinely useful.

Axiom was the same kind of move. Not “automate accounting,” which is unbounded, but: read a financial document, extract its transactions, and push structured rows to QuickBooks or Xero. The boundary is sharp. Bank statement in, reconciled transactions out. You can measure extraction accuracy. You can tell when you are done.

Why broad scope quietly kills projects

A broad scope feels ambitious, but it removes the two things a project needs to make progress:

• No definition of done. If the goal is “understand documents,” there is no point at which you have succeeded, so the work never converges. Every demo raises three new “can it also…” questions and the finish line keeps moving.
• No way to evaluate. You cannot write an eval for a mood. Without a crisp input/output contract you have nothing to score, which means you cannot tell improvement from regression, which means you are flying blind.

Broad scope is also how you end up with the classic trap: an impressive demo that never becomes a product, because “works on the happy path in a meeting” and “holds up in production” are different projects, and only the second one had to be scoped.

The practice

Before writing code, I try to write three things down:

1. The contract. Exactly what goes in and exactly what comes out.
2. The eval. How I will measure whether an output is correct, on real examples.
3. The non-goals. What this system is explicitly not responsible for, so scope creep has somewhere to bounce off.

This is the same instinct as learning the problem domain before touching the code: the narrower and more honest the frame, the better the thing you build inside it. A small system that ships and is correct beats a grand one that demos well and never survives contact with real data.