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.

This page is the working notes behind subCancel, the worked example used across the 27 framework ideas. Anywhere a Shape, Build or Launch post says "for subCancel...", the decision they reference comes from here.

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.

knowledge-base files

Each framework idea drops one file into knowledge-base/. These are the real files for subCancel, building up across the framework. Each links back to the idea that produces it.

user.md

A product someone else buys to solve a recurring pain. The user is not the operator; they have their own job and the product helps with it on a regular cadence. Use this shape if you are building a SaaS or tool for someone other than yourself.

# knowledge-base/user.md

User: A solo operator who runs a 3-person studio and signs up for new subscription services whenever a job needs one

Trigger: A quarterly check-in lands asking "still using this?" for each tracked subscription and the operator works through the list

Outcome: A short list of subscriptions to cancel before the next billing cycle plus updated notes on what the rest are still worth

From 1.1.1, If You Can't Name the User, You're Guessing What They Want.

problem.md

A pain that builds quietly through inattention, costing money in small increments. The user does not actively make the bad decision; the system around them does. Use this shape if the pain you are naming is about omission or compounding cost rather than a single bad event.

# knowledge-base/problem.md

Pain: Subscriptions pile up on the card and the only thing that prompts a review is the renewal notice, by which point another month has already been billed

Trigger: A subscription quietly renews for the sixth month in a row that nobody on the team has opened

Cost: A few hundred dollars a month on tools the team has drifted away from, plus the friction of digging through old emails to remember what each one was even meant to do

From 1.1.2, Describe the Pain Without Mentioning the Solution.

promise.md

A promise framed around a passive user: the product does the work between actions. Boundaries protect against feature creep into things the user did not ask for. Use this shape if your user expects you to remove cognitive load.

# knowledge-base/promise.md

User: The solo operator of a 3-5 person studio who pays for every subscription service on one company card and wants a deliberate check-in instead of waiting for the renewal to surprise them

Promised outcome: A tracked list of every subscription with the operator's own notes, plus a monthly check-in prompt so the operator decides which to keep, change cadence on or cancel

Boundary: Does not connect to bank or card data, does not detect subscriptions automatically and does not cancel on the operator's behalf

From 1.1.3, The One-Line Promise That Keeps Your Build Honest Throughout.

positioning.md

Positioning aimed at the buyer's pain (subscriptions cost too much; this trims them). The useful result is a delivered service. Use this shape if your product solves a recurring tax-like pain.

# knowledge-base/positioning.md

User: A solo operator running a 3-5 person studio who pays for every subscription service on one company card

Problem: Subscriptions pile up faster than the operator notices and the only moment to think about each one is when the renewal hits

Useful result: A monthly email check-in that asks "still using this?" so the operator answers, updates notes or queues services to cancel before they renew

From 1.2.1, Can You Explain This in 30 Seconds Without Mentioning the Tech?.

success.md

Success measured in user behaviour: did the paid action actually happen. Use this shape if the value of version one depends on the user doing something with the product, not just being able to.

# knowledge-base/success.md

Outcome: Paid subscribers act on the monthly check-in email instead of ignoring it

Metric: Percentage of monthly check-in emails that get at least one click-through to update a note or queue a service for cancel

Threshold: 50% action rate across the first 20 paid accounts before adding any feature beyond the email check-in

From 1.2.2, What Does "Success" Actually Mean for the First Version You Ship?.

risks.md

A risk about user inattention: the value depends on engagement and engagement is fragile. Use this shape if your product depends on the user paying attention to whatever signal you send them.

# knowledge-base/risks.md

Likely failure: Paid subscribers ignore the monthly check-in email and renewals keep slipping through anyway, so the paid wedge becomes a tax with no benefit

Affected user or workflow: The solo operator paying $2/month for the cadence that is meant to be the wedge feature; if the wedge fails, the paid tier loses its reason to exist

Mitigation: Track open and click rates per account; for accounts with low engagement, change the subject line, change the day or step the cadence back down to quarterly before the operator cancels in frustration

From 1.2.3, The Risks You're Avoiding Naming Are the Ones That Bite You.

goal.md

A goal about behaviour change (passive to active). Use this shape if your product's value is about shifting how the user relates to a recurring problem.

# knowledge-base/goal.md

User outcome: Operators move from "surprised by renewal emails" to "in active control of every subscription on the company card"

Why it matters: Small studios bleed money on subscriptions that signed up once and got forgotten; the operator's job is to spend the studio's money deliberately, not by default

Proof signal: Operators cancel at least one drifted-into-unused subscription per check-in window and their tracked list stops growing without an explicit reason for each new entry

From 1.3.1, The One Outcome That Makes This Build Worth Doing in the First Place.

scope.md

Cuts that protect against scope expansion into adjacent product categories (auto-detection, multi-user). Use this shape if your scope is at risk of drifting from your category into bigger ones.

# knowledge-base/scope.md

Keep in: Manual subscription add with a one-line note, the email check-in cadence (quarterly free, monthly paid) and one-tap actions in the email to update notes or queue cancel

Leave out: Any form of auto-detection (bank or card integration, email parsing), team or multi-user features and direct API cancellation against vendor billing systems

Why the cut helps: The wedge is the operator's own discipline plus an honest reminder; auto-detection turns the product into an integration race against banks and team features push the price beyond what a 3-person studio will pay

From 1.3.2, What This Will Not Do (On Purpose) Is Half the Decision.

path.md

A path that crosses time (first action, then months of no action, then check-in, then action). Use this shape if the value lands across multiple sessions spread over weeks or months.

# knowledge-base/path.md

User: A solo operator who has just signed up for subCancel

Trigger: They land on an empty subscription list after onboarding and want to capture what the studio is paying for right now

Path to outcome: Add the first subscription with a one-line note, add several more from memory, receive the first quarterly check-in three months later, click through to update notes or queue a service to cancel, take action on at least one before the next renewal

From 1.3.3, Describe One Main Path First, Then Ignore Everything Else.

build/prototype-path.md

A prototype path that tests user behaviour around an attention surface (will they act on the email). Use this shape if your build needs to prove a behavioural assumption about user attention.

# knowledge-base/build/prototype-path.md

Learning goal: Whether a solo operator who captures their subscriptions by hand will actually act on a check-in email instead of ignoring it like every other notification

Path to test: The operator adds three or four real subscriptions with a one-line note each, then receives one check-in email listing them and clicks through to mark one for cancel

Proof signal: At least one subscription gets queued for cancel or has its note updated straight from that first email, with no prompting beyond the email itself

From 2.1.1, The Only Path Your Prototype Actually Needs to Walk.

build/value-moment.md

A value moment in seeing reality compress into a number (the total). Use this shape if your product's wedge is making something invisible visible.

# knowledge-base/build/value-moment.md

User: A solo operator who has been meaning to get a handle on subscription spend but has never seen it all in one place

First value moment: The moment they finish adding their subscriptions and see the full monthly total with their own notes beside each one, usually larger than they guessed

Step that gets them there: A fast add form that takes a service name, rough monthly cost and a one-line note, so the list fills in within a few minutes of signing up

From 2.1.2, Where the User First Feels Value Is Where to Start Building.

build/learning-goal.md

A hypothesis about user behaviour driven by a small UX choice. Use this shape if the build's central bet is a tweak to user-side mechanics.

# knowledge-base/build/learning-goal.md

Hypothesis: Operators will pay a small monthly fee for a reminder cadence they could set themselves, because the captured note is what makes the reminder worth acting on

Question: Does a per-subscription note plus a recurring prompt change whether the operator actually cancels things, compared with a plain calendar reminder

Signal that answers it: Operators who write a note when adding a subscription act on the check-in more often than operators who leave the note blank

From 2.1.3, What This Build Is Meant to Teach You, Not Just to Ship.

build/routine-checklist.md

Routine work that is the wedge feature itself; if it fails the product loses its reason to exist. Use this shape if your routine work IS the value proposition.

# knowledge-base/build/routine-checklist.md

Recurring task: Before each monthly check-in batch goes out, confirm every paid account's due subscriptions are pulled correctly and the email renders with the right notes and costs

Owner: The operator-owner during the prototype phase, since this is the task that stays manual longest because a wrong or empty email erodes the wedge faster than a missing feature ever would

Done condition: A test send to the owner's own account lists every due subscription with current notes and working update and cancel links before the real batch sends

From 2.2.1, The Routine Work Checklist Nobody Talks About.

build/buy-vs-build.md

A buy decision that protects build time for the wedge. Use this shape if you have one clear value-creating feature that needs every available hour.

# knowledge-base/build/buy-vs-build.md

Decision area: Whether to build sign-up and login in-house or hand authentication to Clerk

Reason to buy or build: Buy it through Clerk, because secure password handling, sessions and account recovery are solved work that takes weeks to get right and that no operator ever chose a product for

Deciding constraint: The product lives in the check-in email and the captured note, not the login screen, so the limited build time has to go toward the wedge rather than rebuilding auth an operator only notices when it breaks

From 2.2.2, Buy vs Build Is a Strategy Choice, Not an Engineering One.

build/system-shape.md

A shape with two clear runtime owners (web + job) sharing one data store. Use this shape if your system has long-running interactive and short-running scheduled halves.

# knowledge-base/build/system-shape.md

Boundary: The web app owns the operator's screens and notes; the monthly job owns deciding what is due and sending the email; the two meet only through the shared subscriptions store

Dependency: Both the web app and the job depend on the one subscriptions store; email delivery and auth are external services the studio gains nothing by owning

Handoff: The job reads the due rows, sends the check-in email, and the operator's click hands control back to the web app to update a note or queue a cancel

From 2.2.3, Understanding the Shape of the System Before You Change It.

build/differentiation.md

Differentiation in user-side context that only the user can supply at the right moment. Use this shape if your edge is data the user creates that competitors cannot capture later.

# knowledge-base/build/differentiation.md

Real advantage: The one-line note captured at sign-up, while the operator still remembers why they subscribed, is context no bank feed or spreadsheet recreates later

Where it shows up: In the monthly check-in, where each subscription arrives with the operator's own words beside it so the keep-or-cancel call takes seconds instead of a research session

What stays standard: Auth, billing and email delivery stay off-the-shelf, since nothing about how the operator logs in or pays is worth making different

From 2.3.1, Where the Real Differentiation Actually Lives in Your Build.

build/not-in-v1.md

A cut that protects against decoration features that feel useful but do not move the wedge metric. Use this shape if your v1 risk is browsing-without-deciding features.

# knowledge-base/build/not-in-v1.md

Core path: Add a subscription with a note, receive a check-in, act on at least one subscription before it renews

Feature to cut: Spending charts and category breakdowns, tempting for a first version but sitting to the side of that path

Why the cut strengthens it: Charts let the operator browse and feel informed without deciding anything, and the product only earns its fee when a subscription gets cancelled, so v1 spends its surface on the decision rather than the dashboard

From 2.3.2, Why Cutting Features Is a Design Skill Most Builders Skip.

build/proof-metric.md

A metric on the user doing the thing the product exists to enable. Use this shape if your value depends on a specific user action you can measure directly.

# knowledge-base/build/proof-metric.md

Metric: The share of check-in emails that lead to at least one acted-on subscription, whether a note update or a queued cancel

User behaviour: An operator opening the check-in and making a real decision on the list, rather than archiving the email unread

Threshold: Half of check-ins across the first twenty paid accounts produce at least one action before any feature beyond the email is built

From 2.3.3, The One Metric That Proves This Works for Real Users.

launch/sharing-plan.md

An audience that already shares the pain: peers in the same role facing the same recurring tax. Use this shape if your product is a tool for a defined occupational pain.

# knowledge-base/launch/sharing-plan.md

Audience: Three or four fellow studio operators who already complain about subscription creep, shown the product privately before any public launch

What to show: A working account preloaded with a few of their own real subscriptions, so they feel the check-in on services they actually pay for rather than a demo

Question to answer: Whether the check-in email changes what they do, not whether they like the screens

From 3.1.1, Why Sharing Early Creates the Learning Your Build Needs.

launch/decision-signal.md

A signal read from in-product behaviour (acted on the email). Use this shape if your signal is a discrete user action your system can record.

# knowledge-base/launch/decision-signal.md

Observable signal: Whether an operator queues or cancels a subscription after their first check-in, read from their account rather than from what they say in a call

Behaviour behind it: An operator trusting the prompt enough to act on it, which is the whole product working as intended

Decision it changes: Whether the monthly cadence is the right paid default, or whether a different rhythm is needed before charging for it

From 3.1.2, Ask for Signals, Not Opinions, From the People You Trust.

launch/decision-threshold.md

A threshold for the user-action wedge. Use this shape if your launch hinges on a single user behaviour being common enough to monetise.

# knowledge-base/launch/decision-threshold.md

Threshold: If fewer than half of the early operators act on their first two check-ins, the cadence or the email is the problem, not the polish

Evidence source: Acted-on counts from the shared accounts across their first two check-in windows

Action if met: Hold the paid launch and rework the check-in email and its timing before asking anyone to pay for it

From 3.1.3, Decide in Advance What Would Change Your Mind.

launch/learning-signal.md

A diagnostic question that separates two failure modes by splitting on observable metrics. Use this shape if you have one outcome failure and need to know which of two upstream causes is responsible.

# knowledge-base/launch/learning-signal.md

Question: Are operators ignoring the check-in because the timing is wrong or because the email gives them nothing new to act on

Signal that answers it: Healthy open rates with flat action rates point at the email content, while low open rates point at the timing and subject line

Decision that follows: Fix whichever the split points to first, rather than changing both at once and learning nothing from either

From 3.2.1, The Difference Between Learning and Being Stuck.

launch/review-context.md

A trade-off between simplicity (one batched send) and per-line precision. Use this shape if your reviewable decision is whether to batch or split a delivery mechanism.

# knowledge-base/launch/review-context.md

Decision: We send one monthly check-in covering every due subscription at once, rather than a separate reminder per subscription as it nears renewal

Trade-off: A single email is easier to act on in one sitting but can land before or after a given renewal, so the timing is never perfect for every line

Question for the reviewer: Is one batched check-in more likely to get acted on than several smaller per-renewal nudges, for an operator who already gets too much email

From 3.2.2, Explain Your Decisions Before Asking for Review.

launch/iteration-value-test.md

An iteration that adds context to a delivery surface to make the call easier. Use this shape if your iteration is enriching what the user already sees.

# knowledge-base/launch/iteration-value-test.md

What changed: The check-in email moved from listing subscription names only to showing each one with the operator's note and monthly cost

Meant to improve: How quickly an operator can make the keep-or-cancel call without leaving the email to look things up

Signal it worked: A higher share of check-ins produce an action, and produce it sooner after the email lands, than before the note and cost were shown

From 3.2.3, Iteration Should Increase Value, Not Just Add Surface Area.

launch/readiness-rule.md

Readiness measured by a real user completing the wedge action without breakage. Use this shape if your launch readiness is about one user action working reliably.

# knowledge-base/launch/readiness-rule.md

What has to be true: A new operator can add subscriptions, receive a real check-in on schedule and act on at least one, with the email rendering correctly across the common mail clients

How it is checked: A fresh test account run end to end through one real check-in cycle, plus the email previewed in the mail clients the target operators actually use

Who owns remaining risk: The operator-owner signs off each check-in send until the action rate holds steady, since a broken or empty email is the one failure that loses trust outright

From 3.3.1, What "Ready" Actually Means Once Real Users Are Looking.

launch/launch-risks.md

A launch risk about a silent failure surface (deliverability). Use this shape if your launch's biggest risk is a system layer that fails quietly while the surface stays up.

# knowledge-base/launch/launch-risks.md

This file accumulates one named risk at a time. Each risk follows the
same three-line shape: the likely failure, what triggers it and the
response that is ready before users hit it.

---

## Risk 1: The check-in email never reaches the inbox

Failure mode: The check-in email lands in spam or the promotions tab and the operator never sees it, so the product silently stops working while still charging

Trigger: A batch send to many accounts at once from a new sending domain with no warm-up

Response: Warm the sending domain gradually, authenticate it properly and show the operator their next check-in date in the app so a missed email is recoverable

From 3.3.2, Name the Risks Yourself Before Users Find Them in Production.

launch/ownership-check.md

An imperfection that comes from deliberately not collecting data. Use this shape if your launch ships a less-precise version because the more-precise version would compromise the user's trust or privacy.

# knowledge-base/launch/ownership-check.md

Still imperfect: The check-in fires on a fixed monthly date rather than each subscription's real renewal, so some prompts arrive after a renewal has already billed

If it failed: An operator could be reminded about a subscription the day after it renewed and feel the product was a step too late

Why shipping is acceptable: Even a late first prompt still catches the next eleven renewals, and aligning to true renewal dates depends on data the product deliberately does not collect, so a fixed cadence is the honest version to launch

From 3.3.3, Are You Comfortable Putting Your Name on This Build?.

Why this page exists

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. This page is where they live.

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 this page 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.

Named assumptions

The Shape decisions for subCancel rest on six load-bearing assumptions. Each one is named so it can be challenged, tested or referenced in a later post. If any of them turn out to be wrong, the file or files in knowledge-base/ listed alongside the assumption are where the decision would need to be revisited.

Action over awareness. Operators want to act on subscriptions, not just see them. If tracking is enough and acting on the list is not where the value is, the whole product collapses into a spreadsheet. Load-bearing for goal.md and success.md.

Email is open. Email is a reliable channel for this audience. If inbox fatigue means the monthly reminder gets archived without opening, the paid wedge stops working. Load-bearing for promise.md and path.md.

Impulse price. Two dollars a month is a price point operators will commit to without thinking. Higher and we lose impulse adoption; lower and we look like we do not believe in the product. Load-bearing for promise.md.

Curation over capture. Operators want a deliberate list they curated, not a noisy list scraped from a card statement. If they would rather have everything captured automatically and pruned later, the manual-entry constraint is wrong. Load-bearing for scope.md and positioning.md.

Reminder gradient. Quarterly on the free tier and monthly on paid is the natural value gradient. If quarterly is too slow to be useful, the free tier becomes a static spreadsheet; if monthly is too noisy, paid users churn. Load-bearing for promise.md and success.md.

Single-operator studios. A small studio has one operator who owns these decisions. If two people share the responsibility, the product needs team features and the version-one cuts no longer hold. Load-bearing for user.md and scope.md.

Why these decisions, not the obvious ones

It is worth naming the alternatives that were considered and dropped, so the next person who hits the framework does not redo the work.

Manual entry, not auto-detection from card data. Auto-detection is the obvious feature for a "subscription manager". It was rejected because the wedge is the operator's own deliberate discipline; outsourcing the curation step makes us a connector business competing against banks.

Email, not an in-app dashboard. The operator's attention is already in their inbox; pulling them into a new tab is a tax. A dashboard might come later; the email is the wedge.

Two dollars a month, not nine ninety-five. A low price point makes the upgrade decision a non-event. Pricing can move up later; it is much harder to move it down.

Quarterly reminders on the free tier, not zero reminders. If the free tier is a static list, it is a spreadsheet with extra steps. The reminder cadence is the loop, even at a lower frequency.

One operator per studio, not a team of editors. Team features are the path to a much bigger product, but they are also the path to a much longer build. Version one stays single-actor.

Intentional gap: secondary actors

The Shape files model one user: the studio operator. They do not model the studio's finance lead, the support staff at subCancel, the integrator who might want to automate the workflow or the colleague the operator delegates to next year.

This is deliberate. Version one of any product has to serve one user well before it can serve many. The cuts that make subCancel good for the operator (manual entry, no team features, no API) only hold if there is no secondary user pulling them the other way.

Multisided systems can be built using the same framework. Each actor gets their own pass through the nine Shape ideas: their user.md, their problem.md, their promise.md and so on. The discipline that protects the version-one cuts is the same discipline that lets you safely add a second actor later: you treat the new actor as a fresh build, not as a retrofit.

For now, the second actor is out. When subCancel needs one, the page that gets added first is actors.md listing who else might show up and what changes once they are in scope.

Strategy for open questions

Some decisions need evidence before they can be made. Capturing them as questions, with a trigger for when to revisit, keeps them from being lost or pre-emptively answered.

The shape of an open question is three lines: the question itself, the signal that would tell you it is time to decide and the file that would change once the decision is made.

For subCancel, the open questions today are:

Custom cadence on paid. Should the paid tier offer a custom cadence (weekly, fortnightly)? Revisit if 25% of paid accounts ask for it. Would change scope.md.
Right price point. Is two dollars the right price? Revisit after 25 paid accounts if the conversion rate from free is under 5%. Would change promise.md and success.md.
Bank integration. Should bank integration be on the roadmap at all? Revisit if more than three operators ask for it directly. Would change scope.md.
Web dashboard. Does subCancel need a web dashboard or is the email enough? Revisit if operators ask for it more than three times. Would change path.md.

Each question is parked, not ignored. The condition for unparking is in the question itself.

Strategy for deferred decisions

Some decisions are made but the implementation is paused. They are decided in principle but not implemented in version one because the build has not earned them yet.

For subCancel, the deferred decisions are:

Year-end summary. Decided to ship eventually for paid users, deferred until 50 paid accounts make it interesting to assemble.
Spreadsheet migration. Decided to support an import path from spreadsheet, deferred until someone actually asks.
Anniversary reminders. Decided not in version one, revisit after the cadence proves useful.

Deferred is different from open. Deferred decisions have answers; the question is timing, not content.

How this page fits the framework

The framework asks you to ship the lean version and learn. This page 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, this page is the parallel track. It captures what was assumed, what was deferred, who was deliberately left out. When the build hits an unexpected reality, this is the first page that gets updated, because the reality usually contradicts an assumption before it contradicts a decision.

Key takeaway

The Shape files are the decisions. This page 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, but only one of them gets read every day. Keep the framework lean. Let this one breathe.