1.3.2 - What This Will Not Do (On Purpose) Is Half the Decision

promise.md already names one explicit boundary on what the product is deliberately not trying to do. scope.md is the broader inventory: every feature, edge case or workflow being kept out of version one, with the reason each cut protects the core path. promise.md was the headline boundary; scope.md is the detailed map.

Scope boundary

Is this on-purpose exclusion clear enough before you build?

The call

Say what this will not do before scope pressure makes the decision for you. AI will happily expand a product with no boundary.

Explainer

A scope boundary is not a vague future note. It is a deliberate statement of what stays out so the main path can stay strong. Until you can say what is in, what is out and why the cut makes the product stronger, the scope is still too loose. AI can help generate options, but it will happily expand a product with no boundary.

Make the scope boundary concrete

Compare the broad version with a version you can actually test.

• Too vague: Version one will stay focused and not do too much.
• Concrete enough to test: Version one will help a content creator search using their saved context. It will not support multiple saved contexts per user yet because that would complicate the core search flow before it is proven.

The second version lets two people cut the same feature from it.

Check the scope boundary

• Pass: You can say what stays in, what stays out and why the cut protects the core path.
• Fail: If the boundary still depends on later, flexible or maybe, it is not a real boundary yet.

Do not move into feature, build or roadmap work until this passes.

What you'll walk away with

In the members-only section below we put this into practice. You'll come out with a scope boundary clear enough that every later decision flows from it. Estimates, priorities, what waits for version two and the prompts you write to AI all inherit that clarity.

How it fits together

This is how the work is done in practice on the Cloudflare Workers stack with AI-assisted coding tools. The thoughts and ideas apply equally on any other platform.

The project is a monorepo so the scope boundary (alongside the rest of the framework files) lives in one shared knowledge-base/ folder that every app, every package and every AI prompt reads from. The three products in the vibe2value build-in-public stack (subCancel, ghostMarketingFlow and flowRun) each carry this layout, so look at any of them to see the structure in practice.

You write the scope boundary before you accept any new request, so every "could we also..." gets compared against the cut that already exists. The file is called scope.md because that is what it is: the scope of version one, with the deliberate cuts named. The post calls it a "scope boundary" because the act here is drawing the line, not enumerating every possible feature.

If you sign up, this idea continues with how it all fits together, a worked example, how to use it with AI, how to evaluate it on a real change, the risks worth naming and how to mitigate them, the key takeaways and a copy-paste AI prompt you can drop straight into your next chat. Examples are shown on the Cloudflare Workers stack with AI-assisted coding tools; the ideas apply equally on any other platform.