There’s a tempting move when you’re building a tool that handles a specific type of document: expand the scope. The tool extracts from leases, so why not add support for contracts? It handles financial documents, so why not sales agreements? Every expansion feels like more value — more users served, more use cases covered, a larger total addressable market. The tool that handles more must be better than the tool that handles less.

But scope is not just what the tool covers. Scope is what allows the tool to be good at what it covers. When you narrow the scope, you’re not just deciding what to include — you’re deciding what you can afford to understand deeply. A tool built for one document type can encode every structural variant of that type, every quirk of every vendor template, every edge case that shows up in the messy real-world pile. A tool built for ten document types can encode none of them to the same depth, because the same development effort is now spread across ten domains rather than concentrated in one.

This isn’t a statement about resources — it’s a statement about complexity. Every document type has its own failure modes, its own vocabulary, its own structural conventions, its own long tail of weird variants. Learning a document type well enough to handle that tail takes real contact with real documents, real iterative improvement, real accumulation of cases handled. When you expand scope, you start that process over from scratch for each new type. You get the head of the distribution quickly — the clean, standard examples that any general approach handles — and then you hit the same long tail problem everywhere, simultaneously, with less focus available to work through any of it.

The result of wide scope isn’t a tool that does more. It’s a tool that does many things at the same level of quality you could get from a general-purpose approach — which is to say, not much beyond what the underlying model gives you for free on clean inputs. Narrow scope is what lets a tool do something the general approach can’t: handle the tail of a specific domain with genuine depth, because all the focus that would have been distributed across many domains is concentrated in one. That concentration is what makes excellence possible. Breadth is the enemy of depth, and depth is where the actual value lives.

So scope is a design decision about where to concentrate competence. It’s not about being small — it’s about being focused enough to be genuinely good within the scope you chose. A tool that does one thing at the 95th percentile of quality beats a tool that does ten things at the 60th percentile, every time, for users who care about that one thing. And users who need a tool for a specific document type care about exactly that.