The features we deliberately left out: writing a spec by what it excludes

We had one job to ship: integrate an existing browser sales-copilot extension into a client platform. Around that one job sat a whole phase-2 roadmap — a management API, multi-provider routing, memory, and a mobile app — each of them plausible, each of them wanted, none of them due yet. So we wrote the integration as a standalone specification, and the most important sentences in that document were the ones naming the four features it did not cover.

A specification is defined as much by what it excludes as by what it includes. Leave the edges soft and the deliverable quietly absorbs the roadmap until it stops being shippable. We drew the boundary in writing instead.

TL;DR: We scoped a browser copilot's integration into a client platform as its own spec and explicitly fenced out four phase-2 items — management API, multi-provider routing, memory, mobile app — stating none were part of or required by this scope. Naming the excluded features, rather than leaving scope implied, is what kept the integration shippable.

The extension already existed. It ran as a Chrome extension, it worked as a messenger sales-copilot, and the ask was to wire it into a client platform so the two behaved as one product. On its own, that is a bounded, finishable piece of work.

The trouble is that a working copilot invites a roadmap. Once you can integrate it, someone reasonably asks whether it should also expose a management API. And whether it should route between multiple providers. And whether it should remember past conversations. And whether it should have a mobile app. Every one of those is a fair question. Every one of them is also a different, larger project.

The cost of leaving those questions open isn't hypothetical. Ambiguous scope is how a two-week integration turns into an open-ended platform build. Nobody decides to do that; it happens one reasonable-sounding addition at a time, because nothing on paper says where the deliverable ends.

The obvious fix is to write one big specification that covers the integration and the roadmap — describe the whole future so everyone can see it. It feels thorough. It's the wrong move.

A spec that documents the roadmap alongside the deliverable makes the roadmap feel committed. The moment the management API and the mobile app appear in the same document as the integration, they read as part of the same commitment, on the same timeline. Reviewers plan around them. Estimates swell to cover them. The shippable core gets held hostage to features that were never supposed to block it.

The other tempting move is to say nothing — write only the integration and stay quiet about the rest. That fails differently. Silence isn't a boundary. When a spec simply omits multi-provider routing or memory, it hasn't excluded them; it's just left a gap that anyone can fill mid-project with "well, obviously this needs memory too." Unnamed scope is ambiguous scope, and ambiguous scope drifts.

So neither documenting the roadmap nor ignoring it works. One over-commits; the other leaves the door open.

We wrote the integration as a standalone specification — one deliverable, self-contained — and inside it we named the exclusions explicitly. The document stated that the management API, multi-provider routing, memory, and the mobile app were not part of this scope and not required by it.

That second half matters as much as the first. It isn't only that those features are out of scope; it's that the integration does not depend on them to be complete. A reader can't argue that the deliverable is unfinished because it lacks memory, because the spec already says memory is neither included nor a prerequisite. The boundary is explicit in both directions: these four things are outside the fence, and nothing inside the fence needs them.

The tradeoff we accepted is that the document looks less ambitious than the roadmap behind it. That's the point. A spec's job here was not to describe everything the product might become. It was to describe one thing precisely enough that it could ship, and to protect that one thing from everything else.

Think of the spec as a fence around a single deliverable. Inside the fence: the browser copilot integrated into the client platform — the extension, the platform, and the wiring between them. That is the whole in-scope surface.

Outside the fence, named individually, sit the four phase-2 items:

The instinct we had to push against was completeness. Writing down four features and then writing that you won't build them feels like leaving the job half-described. Every engineer's reflex is to specify the whole system, because a fuller picture feels safer.

What surprised us is that the exclusions did more work than most of the inclusions. The lines that prevented the most confusion weren't the ones describing how the copilot talks to the platform — they were the four naming what this deliverable is not. Those sentences are where scope decisions actually get made or lost.

The uncomfortable part is that naming a phase-2 feature can read as a promise. Put "mobile app" in a document and someone infers it's coming soon. The phrasing had to carry weight: not part of, and not required by, this scope. Not "later," not "planned" — deferred, and explicitly non-blocking. The exact words are load-bearing.

The integration stayed a standalone deliverable. By fencing the browser copilot's integration into the client platform as its own specification and excluding the management API, multi-provider routing, memory, and the mobile app, the work kept the shape it needed to ship. The larger roadmap stayed on the roadmap instead of migrating into this scope.

We're reporting this as a scoping decision, not a benchmark — the measurable win is qualitative: a deliverable that could not be argued into growing, because the document already said, in writing, where it ended and what it did not depend on.

• A spec is defined by its exclusions. What you leave out, stated plainly, shapes the deliverable as much as what you put in.
• Name the excluded features; don't imply them. A vague "phase 2 is out of scope" invites reinterpretation. A named list — management API, routing, memory, mobile — cannot be quietly redrawn.
• Exclude in both directions. Say a feature is not part of the scope and not required by it. The first stops new work sneaking in; the second stops the deliverable being called unfinished.
• Standalone beats comprehensive when you need to ship. Documenting the whole roadmap alongside a deliverable makes the roadmap feel committed and holds the shippable core hostage.
• Fence the deliverable in writing. Soft edges get absorbed by the roadmap one reasonable addition at a time; a written boundary is what keeps a bounded job bounded.