Next workshop If you need the tech to explain it, you don't have a product RSVP now

subCancel

The worked example used across the 27 framework ideas. Assumptions, intentional gaps, open questions and deferred decisions for subCancel, a subscription tracker for solo operators and small studios.

Read the code: github.com/vibe2value/subcancel

Start from the template: subCancel was cloned from the vibe2value base at github.com/vibe2value/vibe2value. Clone it to start your own.

This page is the short version of subCancel, the worked example built across the 27 framework ideas. Anywhere a Shape, Build or Launch post says "for subCancel...", the decision it references is written up in the repo. This page tells you what subCancel is and why it is built the way it is; the repo holds the detail.

What subCancel is

subCancel is a subscription tracker for solo operators and small studios. The operator manually adds each subscription service as they sign up, with a short note on what it does and how long they expect to keep using it. The free tier tracks up to seven subscriptions and sends a quarterly reminder email. The paid tier ($2/month) unlocks unlimited records and a more frequent reminder cadence: monthly by default, with quarterly available as a softer option. Each reminder asks, for every tracked subscription, "still using this? still worth the cost?" so the operator can update notes or mark services for cancelling.

The 27 ideas

subCancel is built one idea at a time across the framework. Each idea has its own post and produces one file in the repo. The post works through the idea; the file is subCancel's worked result. The whole set reads in about ten minutes.

IdeaWorked example
1.1.1 - If You Can't Name the User, You're Guessing What They Wantshape/user.md
1.1.2 - Describe the Pain Without Mentioning the Solutionshape/problem.md
1.1.3 - The One-Line Promise That Keeps Your Build Honest Throughoutshape/promise.md
1.2.1 - Can You Explain This in 30 Seconds Without Mentioning the Tech?shape/positioning.md
1.2.2 - What Does "Success" Actually Mean for the First Version You Ship?shape/success.md
1.2.3 - The Risks You're Avoiding Naming Are the Ones That Bite Youshape/risks.md
1.3.1 - The One Outcome That Makes This Build Worth Doing in the First Placeshape/goal.md
1.3.2 - What This Will Not Do (On Purpose) Is Half the Decisionshape/scope.md
1.3.3 - Describe One Main Path First, Then Ignore Everything Elseshape/path.md
2.1.1 - The Only Path Your Prototype Actually Needs to Walkbuild/prototype-path.md
2.1.2 - Where the User First Feels Value Is Where to Start Buildingbuild/first-value-moment.md
2.1.3 - What This Build Is Meant to Teach You, Not Just to Shipbuild/learning-goal.md
2.2.1 - The Routine Work Checklist Nobody Talks Aboutbuild/routine-checklist.md
2.2.2 - Buy vs Build Is a Strategy Choice, Not an Engineering Onebuild/buy-vs-build.md
2.2.3 - Understanding the Shape of the System Before You Change Itbuild/system-shape.md
2.3.1 - Where the Real Differentiation Actually Lives in Your Buildbuild/differentiation.md
2.3.2 - Why Cutting Features Is a Design Skill Most Builders Skipbuild/feature-cut.md
2.3.3 - The One Metric That Proves This Works for Real Usersbuild/proof-metric.md
3.1.1 - Why Sharing Early Creates the Learning Your Build Needslaunch/early-sharing-plan.md
3.1.2 - Ask for Signals, Not Opinions, From the People You Trustlaunch/decision-signal.md
3.1.3 - Decide in Advance What Would Change Your Mindlaunch/decision-threshold.md
3.2.1 - The Difference Between Learning and Being Stucklaunch/learning-signal.md
3.2.2 - Explain Your Decisions Before Asking for Reviewlaunch/review-context.md
3.2.3 - Iteration Should Increase Value, Not Just Add Surface Arealaunch/iteration-value-test.md
3.3.1 - What "Ready" Actually Means Once Real Users Are Lookinglaunch/readiness-rule.md
3.3.2 - Name the Risks Yourself Before Users Find Them in Productionlaunch/launch-risks.md
3.3.3 - Are You Comfortable Putting Your Name on This Build?launch/ownership-check.md

The fuller picture

Beyond the per-idea files, the repo's product/ folder holds the at-a-glance view: the spec, the named assumptions, the intentional gaps, the open questions and the deferred decisions. That is where the context behind the decisions lives.

Why these files exist

The shape+build+launch framework forces decisions. Nine ideas in the Shape phase, three lines each: who the user is, what pain you are solving, what you promise, how you describe it, what success looks like, what could go wrong, the one outcome that justifies it, what stays in and out, the one main path.

What the framework deliberately leaves out is everything else: the assumptions under those decisions, the actors deliberately left out, the questions parked for later. Those things still matter for subCancel just like they would for any real product. They live in the repo, alongside the decisions they qualify.

A specification that captures every assumption, every edge case and every alternative is a specification nobody reads. The Shape files stay lean because that is how decisions actually get made and how the build actually gets done. Lean shapes are easier to share, easier to defend, easier to update. Leanness only works if the things you cut have a place to live. That is what the repo is for.

Lean is the work

The framework files are short on purpose. Three lines per idea. Nine ideas in Shape. Eighteen more across Build and Launch. By the end the entire knowledge-base/ folder reads in about ten minutes.

The temptation, every time, is to add another paragraph for completeness. Resist it. The version that ships is the version that is short enough to read in five minutes and clear enough that two people would make the same decision from it.

If a Shape file grows past a screen, ask whether you are adding a decision or hiding indecision. Most of the time you are hiding indecision. The fix is to make a clearer call, not a longer file.

Iteration is the work

The Shape files are not signed contracts. They are the current best version of decisions you have made, written down so the team and the AI tools you work with read from one source.

Every file in knowledge-base/ has the same shape: easy to write, easy to update, easy to throw away. When a decision changes, you change the file and commit it. The git history is the decision log.

If a Shape file has not been touched in three months, that is a signal too. Either the decision still holds (good) or the team has stopped looking at it (less good). The Build and Launch phases catch this by referencing back: a feature that contradicts user.md should fail review, not get merged with a TODO.

How the repo fits the framework

The framework asks you to ship the lean version and learn. The repo is what makes that honest.

  • Shape forces the irreducible decisions. Nine files, three lines each, no room for hedging.
  • Build adds the technical decisions on top of Shape. Each Build idea drops another file into knowledge-base/.
  • Launch adds the operational decisions on top of Build. The folder keeps growing.

At every phase, the product/ folder is the parallel track. It captures what was assumed, what was deferred, who was deliberately left out. When the build hits an unexpected reality, that is the first file that gets updated, because the reality usually contradicts an assumption before it contradicts a decision.

Key takeaway

The Shape files are the decisions. The repo's product/ folder is the context that lets them stand alone: the assumptions they rest on, the actors deliberately left out, the questions parked for later. Both kinds of writing matter. Keep the framework lean, let the context breathe and use this page as the door to both.