shape
1.1.1 - If You Can't Name the User, You're Guessing What They Want - Name the user definition: say who the user is, what starts the need and what result they are trying to reach.
Shape it. Build it. Launch it. Run it. Close it.
Vibe it, then make it real, then iterate on that.
Making it real is these five stages, a way of thinking for building with AI that survives change. Work through the decisions that matter and write each one down. Those short notes become the documentation you and your AI build from. What you learn once it is live is what you shape next, so it is a loop and not a line. Pick the stage you are in below, or read all 35 ideas.
Five stages, 35 decisions.
Each stage sorts its decisions into three kinds. Pick the one you are actually facing.
Shape framework ideas
Shape is where you decide what the next change actually is, before anyone writes code. Skip it and you'll build the wrong thing fast.
shape
1.1.2 - Describe the Pain Without Mentioning the Solution - Describe the pain statement: say who is affected, what happens right before the pain appears and what it costs the user or the team.
shape
1.1.3 - The One-Line Promise That Keeps Your Build Honest Throughout - Write the one-line promise: say who it is for, what result it creates and what it is deliberately not trying to do.
shape
1.2.1 - Can You Explain This in 30 Seconds Without Mentioning the Tech? - Explain the 30-second explanation: explain who it is for, what problem it fixes and what useful result appears without adding a second paragraph.
shape
1.2.2 - What Does "Success" Actually Mean for the First Version You Ship? - Define the version one success definition: say what has to happen, how it will be measured and what number or threshold counts as enough.
shape
1.2.3 - The Risks You're Avoiding Naming Are the Ones That Bite You - Name the named risk: say what might fail, who or what it would affect and what action will reduce the damage.
shape
1.3.1 - The One Outcome That Makes This Build Worth Doing in the First Place - Choose the main outcome: say what changes for the user, why that change matters and what signal will show it is real.
shape
1.3.2 - What This Will Not Do (On Purpose) Is Half the Decision - Set the scope boundary: say what stays in, what stays out and why the cut protects the core path.
shape
1.3.3 - Describe One Main Path First, Then Ignore Everything Else - Describe the main path: describe the user, what starts the flow and the exact steps that lead to the outcome.
Build framework ideas
Build is where the change touches running code. The goal isn't to finish; it's to prove the change is real, safe and reversible.
build
2.1.1 - The Only Path Your Prototype Actually Needs to Walk - Define the prototype path: say what the prototype is meant to teach, which path will test it and what signal counts as proof.
build
2.1.2 - Where the User First Feels Value Is Where to Start Building - Find the first value moment: point to the moment the user first feels relief or progress and the step immediately before it.
build
2.1.3 - What This Build Is Meant to Teach You, Not Just to Ship - Name the learning goal: say what you believe, what the build needs to answer and what signal will prove or weaken that belief.
build
2.2.1 - The Routine Work Checklist Nobody Talks About - Define the routine work checklist: say what repeats, who owns it and what done looks like each time.
build
2.2.2 - Buy vs Build Is a Strategy Choice, Not an Engineering One - Make the buy versus build decision: say what the decision is about, why one side wins and which constraint makes the call.
build
2.2.3 - Understanding the Shape of the System Before You Change It - Map the system shape: say which part owns what, what each part depends on and where the important handoff happens.
build
2.3.1 - Where the Real Differentiation Actually Lives in Your Build - Name the real differentiation: point to the advantage, show where the user feels it and say what should remain standard.
build
2.3.2 - Why Cutting Features Is a Design Skill Most Builders Skip - Choose the feature cut: say what stays central, what gets removed and why the product becomes stronger because of that cut.
build
2.3.3 - The One Metric That Proves This Works for Real Users - Define the proof metric: say what the metric is, what user behavior creates it and what threshold counts as enough.
Launch framework ideas
Launch is when the change stops being yours and starts being theirs. Done well, it lasts.
launch
3.1.1 - Why Sharing Early Creates the Learning Your Build Needs - Plan the early sharing plan: say who will see it, what they will see and what question their reaction needs to answer.
launch
3.1.2 - Ask for Signals, Not Opinions, From the People You Trust - Choose the decision signal: point to the behavior or result you need to see and explain what decision it will change.
launch
3.1.3 - Decide in Advance What Would Change Your Mind - Set the decision threshold: say what evidence will trigger change, where it will come from and what action follows.
launch
3.2.1 - The Difference Between Learning and Being Stuck - Name the learning signal: say what question is being answered, what signal will answer it and what decision comes next.
launch
3.2.2 - Explain Your Decisions Before Asking for Review - Explain the review context: say what was decided, what trade-off it created and what question you want reviewers to answer.
launch
3.2.3 - Iteration Should Increase Value, Not Just Add Surface Area - Check the iteration value test: say what changed, what user outcome it is meant to improve and what signal will show that it did.
launch
3.3.1 - What "Ready" Actually Means Once Real Users Are Looking - Define the readiness rule: say what has to be true, how it will be checked and who owns any remaining risk.
launch
3.3.2 - Name the Risks Yourself Before Users Find Them in Production - Name the launch risk: say what might break, what would trigger it and what response reduces the damage.
launch
3.3.3 - Are You Comfortable Putting Your Name on This Build? - Set the ownership threshold: say what is still imperfect, what would happen if it failed and why shipping is still acceptable under those conditions.
Run framework ideas
Run is where people rely on it and you are not watching. The work is making a live system tell you the truth about itself and deciding where to stop.
run
4.1.1 - You Haven't Finished a Deploy Until You've Practised Undoing It - Decide what triggers a deploy to each environment, how you confirm it landed and the exact route back to the previous version.
run
4.1.2 - If the Secret Only Exists on Your Machine, You Are the Single Point of Failure - Decide where secrets live and how they are set per environment, with every name the code reads written down and no real value anywhere near it.
run
4.2.1 - The Failure Whose Only Symptom Is That the Answer Looks Wrong - Decide where each kind of failure appears and what a person is handed when it does, including the ones that never go red.
run
4.2.2 - Decide What Reaches You Before Everything Does - Decide which work runs unattended, what hands itself back to a person and what that person actually receives when it does.
run
4.3.2 - How Would You Know If Any of This Worked? - Decide what evidence would tell you the knowledge base is doing its job, then take the reading before you start so you have something to compare against.
Close framework ideas
Close is the stage you arrive at rather than live in. Every other stage keeps a thing alive. This one asks whether it should be: would you start this today?
close
5.1.1 - Would You Start This Today? - Run the continue test: say whether it still earns its place, what it costs you in a normal week and which of the three answers comes next.
close
5.1.2 - Where Do You Stop, For Now? - Decide what this project asks of you in a normal week, and write down what would make you open it again.
close
5.1.3 - How It Ends Is the Part People Remember - Plan the ending: say who is still using it, what they get and what is left behind at the address afterwards.