1.3.2 - What This Will Not Do (On Purpose)

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.

Why it matters

What this will not do on purpose is a strategy decision that protects focus before implementation pressure expands scope. AI can generate many possibilities quickly, but human judgement decides which requests stay out so the intended outcome remains clear. The difference is between disciplined progress and a build that tries to do everything and explains nothing.

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.

How to use AI for the scope boundary

• AI chat: Rewrite the scope boundary until you can state all three parts clearly.
• vibeCoding: Build the thinnest flow that tests this scope boundary in practice before broader build work.
• AI-assisted coding: Carry the same scope boundary into implementation and review so the live system keeps the same decision.

Sharpen the scope boundary

Copy this prompt into AI chat, replace the bracketed lines with your real scope boundary and keep the instruction exactly as visible here.

You are checking whether this scope boundary is clear enough before you move forward.

Constraint:
The scope boundary must be specific enough that two people would cut the same feature from it.

Working draft:
Keep in: [what stays in scope]
Leave out: [what stays out]
Why the cut helps: [why the cut protects the core path]

Task:
Decide whether this scope boundary is specific enough to guide the next decision. If it is vague, rewrite it so two people would make the same decision from this scope boundary.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Does it meet this bar: You can say what stays in, what stays out and why the cut protects the core path.

Return:
- A corrected scope boundary
- A short explanation of what was vague

Evaluation

Before accepting the result, check whether two people would cut the same feature from it.

Example

To help you work through this, here is a real example. StartWithYourContext is an AI search tool built as part of the vibe2value project. Here is how its scope boundary was written using the three parts:

• Keep in: One saved context per user that shapes every search result.
• Leave out: Multiple saved contexts, shared contexts between users, and browsing history as a context source.
• Why the cut helps: Adding multiple contexts before the single-context flow is proven would blur what the tool actually does and make it harder to tell whether results improve because of context or despite it.

That boundary is specific enough that two people would cut the same feature from it.

When there is more than one side

Not every product has a single scope boundary. When a system serves more than one side, each side has different expectations about what should be included and a cut that protects one side may frustrate the other.

Multi-sided worked example

For example, StartWithYourContext has two different scope boundaries:

• Content creator: Version one searches using one saved context. It will not suggest topics the user has not asked about, even if the content gap is obvious.
• Developer: Version one deploys as one project with a fixed stack. It will not support swapping in alternative databases or auth providers, even though that would make it more flexible.

Both cuts protect focus, but they protect different things. If only one boundary is stated, the other side’s scope creeps in by default.

Risk and mitigation

• Risk: Weakening intentional exclusions after new requests arrive, which blurs purpose and slows decisions.
• Mitigation: Define one exclusion rule up front and require clear user-impact evidence before any exception is allowed.

Key takeaway

Do not move forward until you can say what stays in, what stays out and why the cut protects the core path.

Work through this in a workshop

If your scope boundary is still unclear, bring it to a free weekly workshop. Bring the messy part of your AI-assisted build and leave with a clearer next step. In some sessions, we walk through practical examples on the Cloudflare Workers stack to show how a rough idea turns into something that actually runs.

What do you think?

How are you deciding what your build will not do on purpose and how is AI helping you enforce those boundaries?