# vibe2value > Build with AI and trust what you make. Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts. Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`). ## Pages ### About URL: https://vibe2value.com/about/ Last updated: 2026-08-31T23:34:18.000Z This started from a simple observation. AI builds the easy part now. The hard part is deciding what to make and trusting what you get back. vibe2value is where I show that work in the open. Real work, explained step by step, built with AI on the Cloudflare Workers stack. The thinking can work on yours too. AI is learnable in an afternoon. The judgment of what to build and the craft of getting it right are not. At the centre of it is a small framework called shape+build+launch+run+close: 35 ideas for making changes that hold. Built from real work, deliberately practical. Less performance. More clarity. Less noise. More evidence that something actually helps. Five stages. Decide what to make, build it, put it in front of people, then keep a live system honest once people rely on it. [shape+build+launch+run+close →](https://vibe2value.com/) There are notes from building with AI. [Read the blog →](https://vibe2value.com/blog/) All 35 framework ideas are free to read, each with the AI prompt for it. [Start here →](https://vibe2value.com/start-here/) ### myVibe URL: https://vibe2value.com/myvibe/ Last updated: 2026-04-09T12:37:36.000Z _No content available._ ### Contact URL: https://vibe2value.com/contact/ Last updated: 2026-07-16T22:19:59.000Z Get in touch for questions about workshops, guest speaking or anything on the site. **Matt Cameron** [matt@vibe2value.com](mailto:matt@vibe2value.com) +61 449 191 584 [linkedin.com/in/mattcameronme](https://www.linkedin.com/in/mattcameronme/?ref=vibe2value.com) ### The shape+build+launch+run framework URL: https://vibe2value.com/framework-intro/ Last updated: 2026-08-28T12:07:09.000Z Getting something built is easy now. Making the second version real is the hard part. Start with the stage that names where you are stuck. Four stages, 33 decisions, and a worked example on every one. [shape+build+launch+run →](https://vibe2value.com/framework/) ### Policies URL: https://vibe2value.com/policies/ Last updated: 2026-07-20T05:17:14.000Z A short summary of how vibe2value works: what gets collected, what membership covers and the line on conduct. ## Privacy Privacy should be simple enough that you do not need legal fog to understand the basics. Your information is used to run this site, manage membership and send the emails you have chosen to receive. It is not sold and it is not shared for advertising. This site does not use tracking cookies for advertising and your activity is never sold or shared. The only essential cookies are the ones needed for member login. Basic site analytics are used in aggregate to understand what people read and where the work is useful. By default this does not profile you as an individual. If you join the workshop or contact the site directly, your details are used only to respond and manage that interaction. ### Personalisation You can choose to let the site learn what interests you. If you opt in, we note which pages you read and use that to make your visit more relevant. For members who have opted into emails, it can also shape what those emails focus on. It is off until you accept it. You can decline with no loss of access and you can change your mind at any time using the button below. Your choice is stored and we keep a record of it. This is separate from marketing emails. Those have their own double opt-in that you confirm by email before anything is sent. We only look at pages viewed on this site. We do not follow you across other sites and nothing is sold or shared. Your current choice is remembered in this browser. To change it, use the button below. Change your data preferences ## Terms The content on vibe2value is for reflection, learning and practical decision-making. It should not be treated as legal, financial or other professional advice. Membership gives access to additional content and updates, but it does not create any obligation to participate or keep up. One-to-one support, advisory work or other direct help is only provided by separate agreement and is scoped separately from membership. Payments are handled securely through the payment systems used on this site. Paid support can be cancelled at any time unless something different has been agreed in writing. ## Code of conduct This community works best when people can think clearly, disagree respectfully and still feel safe participating. What follows is a short summary of what is welcome here and what is not. ### What is encouraged - Respectful disagreement that stays focused on ideas rather than people. - Curiosity, good-faith questions and practical feedback. - Making room for other people to speak, think and participate. - Owning mistakes, adjusting quickly and helping the space stay constructive. ### What is not okay - Harassment, intimidation, discrimination or repeated personal attacks. - Trolling, bad-faith engagement or behaviour designed to derail the conversation. - Unwanted sexual attention, abusive language or targeting people on the basis of identity. - Sharing private information without permission or making the space feel unsafe for others. ### If the line is crossed If behaviour crosses the line in workshops, comments or direct communication, access may be limited or removed. The aim is to protect the community, not to prolong conflict. ## Attribution The Code of Conduct is adapted from the [Contributor Covenant, version 2.0](https://www.contributor-covenant.org/version/2/0/code%5Fof%5Fconduct.html?ref=vibe2value.com). Community Impact Guidelines were inspired by Mozilla's code of conduct. For answers to common questions, see the [FAQ](https://www.contributor-covenant.org/faq?ref=vibe2value.com). [Translations](https://www.contributor-covenant.org/translations?ref=vibe2value.com) are also available. Questions? Email [hello@vibe2value.com](mailto:hello@vibe2value.com). ### Pricing URL: https://vibe2value.com/pricing/ Last updated: 2026-08-31T23:28:52.000Z What you get is a document that is yours, one that both you and the AI can read and work with. The focus is on building with the Cloudflare Workers stack. This is how I work. **Read it. Free.** All 35 ideas, the framework, the prompts and the worked examples. Nothing is locked. **Ask me anything. Free when you join.** Every video as it lands. Ask anything about any of the 35 ideas and I answer it in the open, on the idea itself. **Your first hour. Free.** One hour, two ways to use it. Either send me something you have already built and I give it an hour the way a customer would, with nobody walking me through it, then you get a written review back. Or tell me what you are building and we talk it through and that one becomes the video on whichever idea it fits. **An hour a month.** $149.50 a month. Private and about your own thing. Bring a problem that needs solving. We work through it in an hour and you come out with something that works, plus a way to do it again without me. **An hour a week.** $498.50 a month. A standing hour, the same slot every week. Ask between sessions so you are not stuck for six days. A small number of these at a time. **More than that.** Some work does not fit in an hour a week. That starts as a conversation and the price follows the work. ## The work itself **What the work usually is.** Two things, mostly. Getting your project written down so AI stops guessing. Your rules, your context, the way you do things, so every session after that starts further along. And getting it running properly once real people depend on it, which is the part AI made no cheaper. **What an hour actually is.** We work out a plan in that first hour, so the paid time goes where it does the most good and there is a strategy behind it rather than a list of jobs. And the hour is the time we spend together. The preparation that makes it worth having comes with it. ## Who you are working with Matt Cameron. Decades building software and keeping it running once people rely on it. Years designing systems for banks, retailers and other large organisations and for the big marketing platforms they run on. Solid experience with marketing automation for small business, where the platform is the easy half and the strategy is what makes it work. That same experience now goes into founders building their own product, built fast with AI, for paying clients today. The judgment to know what is worth building and the hands to build it. [More about me →](https://vibe2value.com/about/) ## The method Vibe it, then make it real, then iterate on that. 35 ideas across five stages. [shape+build+launch+run+close →](https://vibe2value.com/framework/) ## For something more, let's talk Tell me what you are trying to make. Every piece of work I have done started as a conversation about a real problem. The answer was different every time. [matt@vibe2value.com](mailto:matt@vibe2value.com) ### Ways to get to a sharp answer URL: https://vibe2value.com/ways-to-get-to-a-sharp-answer/ Last updated: 2026-07-17T05:49:35.000Z [For developers](https://vibe2value.com/for-developers/) › Ways to get to a sharp answer Every framework idea finishes the same way. You take your draft and run it through a **Sharpen** prompt until two people would make the same decision from it. Sharpen needs a draft to work on though. If you cannot write one yet, or it feels vague, these are ways to get to a draft worth sharpening. Whichever you use, you finish the same way, by running it through Sharpen. Interview meBlank page, not sure what you wantShow by exampleHave the gist, the words will not landGive me optionsA few directions, want to chooseThen Sharpenuntil two people would makethe same decision from it No draft yet? Pick an on-ramp by what you already have. Interview me for a blank page, show by example when the words will not land, give me options when you have a few directions. Each one gets you a draft. Then they all finish the same way, by running it through Sharpen. ## When to use these - You are staring at a blank page and cannot write the first draft. - You have a draft but it feels vague and you cannot see why. - You have too many ideas and cannot choose between them. ## Interview me Let AI ask you the questions. [Interview me →](https://vibe2value.com/interview-me/) ## Show by example Give AI an example or two and let it infer the shape for yours. [Show by example →](https://vibe2value.com/show-by-example/) ## Give me options Ask for several distinct candidates and choose. [Give me options →](https://vibe2value.com/give-me-options/) ## Then sharpen Whichever on-ramp you used, you now have a draft. [Then sharpen →](https://vibe2value.com/then-sharpen/) Part of [Working with AI](https://vibe2value.com/working-with-ai/). These on-ramps run across the [Shape ideas](https://vibe2value.com/tag/shape/). The soft skills behind them: [The soft skills of working with AI](https://vibe2value.com/the-soft-skills-of-working-with-ai/). **Why Claude.** We use Claude Code in the notes above because it is one of the most widely used AI tools for building software. It is also what we build with day to day. The on-ramps themselves are general and carry across to other capable AI tools. ### Ways to build it with AI URL: https://vibe2value.com/ways-to-build-it-with-ai/ Last updated: 2026-07-28T03:59:39.000Z [For developers](https://vibe2value.com/for-developers/) › Ways to build it with AI When you have a sharp decision and need working code, there are a few ways to build it with AI. They are not on-ramps to one tool like Sharpen. They are approaches you pick between, by the size and risk of the change. Whichever you pick, the decision you sharpened is the spec. yesyesyesnononoSmall, clear and low-risk?Main challenge isthe approach?Main challenge isthe behaviour?vibeCodePlan firstTest firstBuild carefully Work down the questions. Small, clear and low-risk, vibeCode. If not, the main challenge decides. If it is choosing the approach, plan first. If it is getting the behaviour right and you can specify it, test first. Otherwise it is risk, so build carefully. You can mix them: plan first to find the shape, then vibeCode the easy parts and build the risky parts carefully. ## vibeCode Fast and loose. [vibeCode →](https://vibe2value.com/vibecode/) ## Plan first Explore and design before you write code. [Plan first →](https://vibe2value.com/plan-first/) ## Test first Write the tests, or have AI write them, then let AI iterate until they pass. [Test first →](https://vibe2value.com/test-first/) ## Build carefully Smaller steps, review each one. [Build carefully →](https://vibe2value.com/build-carefully/) ## More ways Claude helps you build The four approaches are how you build. A few more pieces make building with AI work well. We will add a short note on each here over time. - **Refine it iteratively.** Keep looping with Claude, tightening the result each pass rather than expecting it right first time. - **Work in a large codebase.** Have Claude explore and map unfamiliar code first, so a change fits what is already there. - **Set Claude up to your conventions.** Project memory and rules, so Claude builds the way your codebase already does. ## Pick by the task There is no single right way to build with AI. You pick the approach by the task in front of you and mix them within one piece of work. The decision you sharpened is the spec, whichever way you build it. In plain words This page is about the different ways to build something with AI, where AI means a tool that writes and changes code for you when you describe what you want (Claude and Claude Code are the specific tools used in the examples). It covers four approaches, from quickly describing what you want and letting the AI run, to planning or testing first when the work is bigger or riskier. The aim is to match the approach to how big and risky the change is, rather than doing everything the same way. ## Finding your way around a codebase Glob, grep and read are a ladder in increasing order of cost. [Finding your way around a codebase →](https://vibe2value.com/finding-your-way-around-a-codebase/) Part of [Working with AI](https://vibe2value.com/working-with-ai/). These approaches run across the [Build ideas](https://vibe2value.com/tag/build/). The soft skills behind them: [The soft skills of working with AI](https://vibe2value.com/the-soft-skills-of-working-with-ai/). **Why Claude.** We use Claude Code in the notes above because it is one of the most widely used AI tools for building software. It is also what we build with day to day. The approaches themselves are general and carry across to other capable AI coding tools. ### Ways to run it for real URL: https://vibe2value.com/ways-to-run-it-for-real/ Last updated: 2026-08-25T23:02:00.000Z [For developers](https://vibe2value.com/for-developers/) › Ways to run it for real Once it is live, running it for real is its own kind of AI work. These are the moves that keep a live system honest. Unlike the on-ramps to Sharpen, you combine these rather than pick one. Hold the contextKnow when to step inFail wellReview with fresh eyesA live systemyou can putyour name on These four are a set, not a sequence, and you combine them. A live system that holds its context, knows when to step in, fails well and gets reviewed with fresh eyes is one you can put your name on. ## Hold the context Anything important that lives only in the chat is at risk, because a long conversation gets compacted as it grows and a summary blurs the precise things, the amounts, the dates and the decisions. [Hold the context →](https://vibe2value.com/hold-the-context/) ## Know when to step in Decide in advance what AI handles and what comes to you. [Know when to step in →](https://vibe2value.com/know-when-to-step-in/) ## Fail well Make failures surface clearly, with enough context to recover, instead of being swallowed or guessed around. [Fail well →](https://vibe2value.com/fail-well/) ## Review with fresh eyes Have a second, independent AI pass look at the work without the context that built it. [Review with fresh eyes →](https://vibe2value.com/review-with-fresh-eyes/) ## When a step goes wrong In a system built from separate parts, failure is normal rather than rare. Both hiding it and crashing are the wrong answer. [When a step goes wrong →](https://vibe2value.com/when-a-step-goes-wrong/) ## Where a person should look Checking everything wastes the review time you have and checking nothing is how the expensive mistakes get through. [Where a person should look →](https://vibe2value.com/where-a-person-should-look/) ## Putting it together These are not a sequence, they are a set. A live system that holds its context, knows when to step in, fails well and gets reviewed with fresh eyes is one you can put your name on. ## When nothing is waiting on the answer Half the cost if you can wait. One question decides which lane. [When nothing is waiting on the answer →](https://vibe2value.com/when-nothing-is-waiting-on-the-answer/) ## Running Claude in a pipeline A pipeline has nobody at the keyboard, so anything that pauses hangs the build. [Running Claude in a pipeline →](https://vibe2value.com/running-claude-in-a-pipeline/) Part of [Working with AI](https://vibe2value.com/working-with-ai/). These moves run across the [Run ideas](https://vibe2value.com/tag/run/). The soft skills behind them: [The soft skills of working with AI](https://vibe2value.com/the-soft-skills-of-working-with-ai/). **Why Claude.** We use Claude Code in the notes above because it is one of the most widely used AI tools for building software. It is also what we build with day to day. The moves themselves are general and carry across to other capable AI tools. ### Working with Claude URL: https://vibe2value.com/working-with-claude/ Last updated: 2026-07-27T03:09:40.000Z [For developers](https://vibe2value.com/for-developers/) › Working with Claude This page gathers the Claude Code notes from across the six ways of working, grouped by what you are doing with Claude rather than by which page each one sits on. Every link drops you back into the page where that note lives in full. It is a second way into the same material, so if you know the stage of work you are in rather than the move you want, the six ways are the better door. Ways to get to a sharp answerWays to build it with AIWays to run it for realWorking withClaudethe Claude notes from all three,grouped by what you are doing Every "Doing this with Claude Code" note across the three pages, gathered here and grouped by what you are doing with Claude. Each link drops you back into the page where that note lives in full. ## Get it clear first Before Claude builds anything, get the ask sharp. | [Make it ask questions](https://vibe2value.com/ways-to-get-to-a-sharp-answer/#interview-me)Have Claude interview you before it builds, so the gaps close first. | clarifying questions sharp answer | | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | | [Ask for options](https://vibe2value.com/ways-to-get-to-a-sharp-answer/#give-me-options)Get several genuinely different drafts side by side, then pick. | option generation sharp answer | | [Show by example](https://vibe2value.com/ways-to-get-to-a-sharp-answer/#show-by-example)Show the result you expect instead of describing it in words. | worked examples sharp answer | ## Plan and explore When the change is big enough that the approach is the hard part. Say it another way Plan mode is a setting where the AI works out an approach and shows it to you before writing any code, so you agree the plan first. It is like asking a builder for the drawings before they start knocking down walls. | [Plan mode](https://vibe2value.com/ways-to-build-it-with-ai/#plan-first)Settle the approach with nothing committed, then build it. | plan mode build with AI | | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | | [Explore subagent](https://vibe2value.com/ways-to-build-it-with-ai/#plan-first)Push noisy discovery into its own pass so the main thread stays lean. | subagents build with AI | ## Make the ask checkable Pin the result to something you can test, not a feeling. | [Testable criteria](https://vibe2value.com/ways-to-get-to-a-sharp-answer/#then-sharpen)Pin the ask to something you could actually test. | specific prompts sharp answer | | ---------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | | [Test first](https://vibe2value.com/ways-to-build-it-with-ai/#test-first)Write the test first, then let Claude work until it passes. | test-driven build with AI | ## Make the output trustworthy Get structured, honest output you can rely on without re-checking it by hand. Say it another way A schema is just a fixed shape you ask the AI to fill in, like a form with set boxes, rather than letting it write whatever it likes. Handing it the form means nothing gets missed and nothing made up creeps in. | [Ask for a shape](https://vibe2value.com/ways-to-make-the-output-trustworthy/#ask-for-a-shape-not-prose)Hand Claude a schema to fill, so the shape is guaranteed and nothing creeps in. | schemas and tool\_use trustworthy | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | | [Keep extraction honest](https://vibe2value.com/ways-to-make-the-output-trustworthy/#examples-keep-extraction-honest)Worked examples stop it inventing values when pulling data from a messy source. | worked examples trustworthy | | [Validate and retry](https://vibe2value.com/ways-to-make-the-output-trustworthy/#validate-and-retry)Validate the output and hand back the specific error so it self-corrects, not a blind rerun. | validation loops trustworthy | | [Review with fresh eyes](https://vibe2value.com/ways-to-make-the-output-trustworthy/#review-with-fresh-eyes)A separate instance with none of the generation context catches what the maker glossed over. | independent review trustworthy | | [Guard against false positives](https://vibe2value.com/ways-to-make-the-output-trustworthy/#guard-against-false-positives)Stop a check crying wolf, because one noisy category poisons trust in all of it. | noise control trustworthy | ## Stay the driver Keep your hands on the wheel while Claude does the work. | [Group your fixes](https://vibe2value.com/ways-to-get-to-a-sharp-answer/#then-sharpen)Decide if fixes are related or independent before you send them. | batching feedback sharp answer | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- | | [Small steps and diffs](https://vibe2value.com/ways-to-build-it-with-ai/#build-carefully)Short leash, small steps, check each diff before the next. | incremental review build with AI | | [Permissions and review gates](https://vibe2value.com/ways-to-run-it-for-real/#know-when-to-step-in)Decide up front what Claude does alone and what pauses for you. | permissions run for real | ## Hold the context Keep the decisions where you and Claude can both find them. Say it another way Project memory, a file called CLAUDE.md, is a note the AI reads every time it starts, holding your project's decisions and rules. It is like leaving a briefing on the desk so each new shift picks up where the last one left off instead of guessing. | [CLAUDE.md, memory and sessions](https://vibe2value.com/ways-to-run-it-for-real/#hold-the-context)Keep decisions and state where the next session can find them. | project memory run for real | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | | [Project memory and rules](https://vibe2value.com/ways-to-set-ai-up-to-help/#project-memory-and-rules)Layer CLAUDE.md by scope, keep it modular, and scope rules to where they apply. | CLAUDE.md and rules set up | ## Keep it honest Make a live system surface trouble instead of hiding it. | [Fail well](https://vibe2value.com/ways-to-run-it-for-real/#fail-well)Make failures surface clearly instead of being guessed around. | fail loudly run for real | | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- | | [Fresh-eyes review](https://vibe2value.com/ways-to-run-it-for-real/#review-with-fresh-eyes)Have a clean instance review what the one that built it cannot see. | fresh session run for real | ## Engineer the work, not just the prompt Working with Claude is not only the wording of a prompt; it is how a request runs, the safeguards when a step fails and the human checks on the risky parts. [Prompt engineering with Claude](https://vibe2value.com/prompt-engineering-with-claude/). ## Pick a build approach When the change is small and clear, just build it. | [vibeCode](https://vibe2value.com/ways-to-build-it-with-ai/#vibecode)For small, clear and low-risk work, just describe it and build. | direct prompting build with AI | | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------ | ### Ways to make the output trustworthy URL: https://vibe2value.com/ways-to-make-the-output-trustworthy/ Last updated: 2026-07-27T03:04:11.000Z [For developers](https://vibe2value.com/for-developers/) › Ways to make the output trustworthy When AI produces something you are going to put live, trustworthy means you can rely on it without re-checking every line by hand. That trust is not automatic. You build it by being explicit about what good looks like, bringing in fresh eyes, and verifying the parts that carry real risk. This page is about the moves that turn a plausible-looking output into one you can put your name on. AI outputCheck itclear criteria + fresh-eyes reviewYou can put yourname on it Trust is not automatic. AI output earns it by being checked against clear criteria and looked over with fresh eyes, until it is something you can stand behind. ## Ask for a shape, not prose When you need data back from AI in a fixed form, the reliable move is to hand it a schema, the defined shape of the thing you want, and have it fill that in, rather than describing the JSON you want in a prompt and hoping. [Ask for a shape, not prose →](https://vibe2value.com/ask-for-a-shape-not-prose/) ## Examples keep extraction honest The other way to a trustworthy result is by example. [Examples keep extraction honest →](https://vibe2value.com/examples-keep-extraction-honest/) ## Validate and retry Structured output gives you the shape; validating is checking the values are actually right, and when they are not, feeding back the specific failure so the AI corrects it rather than starting cold. [Validate and retry →](https://vibe2value.com/validate-and-retry/) ## Review with fresh eyes The maker is the worst reviewer of its own work. [Review with fresh eyes →](https://vibe2value.com/review-with-fresh-eyes/) ## Guard against false positives A check is only trustworthy if you act on what it says. [Guard against false positives →](https://vibe2value.com/guard-against-false-positives/) ## Keeping the source on every claim When an answer is gathered from many places, the source behind each claim tends to fall away as findings are tidied into one confident summary. [Keeping the source on every claim →](https://vibe2value.com/keeping-the-source-on-every-claim/) Two more trustworthy moves already live on the [getting a sharp answer](https://vibe2value.com/ways-to-get-to-a-sharp-answer/#then-sharpen) page: setting checkable criteria so quality is not a matter of opinion, and the Sharpen loop for tightening a draft until two people would decide the same way. Part of [Working with AI](https://vibe2value.com/working-with-ai/). The soft skills behind it: [The soft skills of working with AI](https://vibe2value.com/the-soft-skills-of-working-with-ai/). **Why Claude.** When this page carries tool-specific notes they use Claude Code, because it is one of the most widely used AI tools for building software. It is also what we build with day to day. The moves themselves are general and carry across to other capable AI tools. ### Ways to build an AI agent URL: https://vibe2value.com/ways-to-build-an-ai-agent/ Last updated: 2026-07-28T03:00:57.000Z [For developers](https://vibe2value.com/for-developers/) › Ways to build an AI agent Some work is better handed to an agent than done one prompt at a time. An agent is AI that pursues a goal by taking steps on its own, choosing and running tools, reading the result, and deciding what to do next, all within the bounds you set. This page is about designing that well: what the agent can reach, how it decides, and where it has to stop and hand back to a person. Say it another way What is an agent, in plain words? Usually you tell the AI one thing and it does that one thing. An agent is AI you hand a goal to instead, and it works out the steps itself, does them, checks how they went, and decides what to do next, until the goal is met. It is the difference between talking someone through a recipe step by step and simply asking them to make dinner. The real skill is deciding what it may do on its own, and where it has to stop and check with you. out of boundsGoal + boundsAgentpick a tool, run it, read the result,decide againDoneHand to you An agent pursues a goal by taking steps on its own, choosing a tool, running it, reading the result and deciding what to do next, all inside the bounds you set. When it hits one of those bounds it stops and hands back to you. ## The pages in this group - [**The agent loop**](https://vibe2value.com/the-agent-loop/). The loop is your code, not the model’s. What each pass does and how it stops. - [**Write tool descriptions the model can choose from**](https://vibe2value.com/tool-descriptions-the-model-can-choose-from/). The description is not documentation, it is how the model chooses. - [**Which tools each agent gets**](https://vibe2value.com/which-tools-each-agent-gets/). More tools means worse selection. The cost is in the choosing. - [**Work out the steps before you split the work**](https://vibe2value.com/work-out-the-steps-before-you-split-the-work/). Whether you hold the pattern already or have to go and find it. - [**Let one agent hold the whole picture**](https://vibe2value.com/let-one-agent-hold-the-whole-picture/). The coordinator is the only thing holding the whole job. - [**Pass everything the helper needs**](https://vibe2value.com/pass-everything-the-helper-needs/). If a fact is not passed, it does not exist for that helper. - [**Send independent work out together**](https://vibe2value.com/send-independent-work-out-together/). Parallel is not a setting, it is where the calls sit. - [**Hooks that always run**](https://vibe2value.com/hooks-that-always-run/). A prompt gives a tendency and a hook gives a guarantee. - [**How much to let AI decide**](https://vibe2value.com/how-much-to-let-ai-decide/). You do not choose a shape, you choose what to decide. - [**Guaranteeing the steps that matter**](https://vibe2value.com/guaranteeing-the-steps-that-matter/). A prompt asks, code guarantees. - [**What kind of failure is it**](https://vibe2value.com/what-kind-of-failure-is-it/). Saying which kind it was is what makes the next move obvious. ### Ways to set AI up to help URL: https://vibe2value.com/ways-to-set-ai-up-to-help/ Last updated: 2026-07-28T07:59:03.000Z [For developers](https://vibe2value.com/for-developers/) › Ways to set AI up to help Before AI can help well, you set it up. Left cold it guesses at your conventions every time; given the right context once, it builds the way your project already does. This page is about that groundwork: the memory, rules and context you put in place so the AI starts each task already knowing how your work is meant to go. Memory and rulesProject contextConventionsAIBuilds the way yourproject already does Set up once and the AI starts each task already knowing how your work is meant to go. The memory, rules and context you put in place are what stop it guessing your conventions every time. ## Project memory and rules The first piece of setting AI up is giving it your project's memory and rules, the conventions, context and standards it should already know before it starts. [Project memory and rules →](https://vibe2value.com/project-memory-and-rules/) ## Custom slash commands and skills Once your project memory is set, the next way to set AI up is to package the jobs you do often, so you are not explaining them from scratch every time. [Custom slash commands and skills →](https://vibe2value.com/custom-slash-commands-and-skills/) ## Path-scoped rules After the always-on project memory above, there is a lighter-touch way to give Claude rules: ones that switch on only when they are relevant. [Path-scoped rules →](https://vibe2value.com/path-scoped-rules/) ## The tools and information Claude can reach The last piece is what Claude can actually reach: your files, your systems, the other apps you already run. [The tools and information Claude can reach →](https://vibe2value.com/the-tools-and-information-claude-can-reach/) Say it another way That last term, in plain words: - **MCP servers** are like the sockets on a wall. They are a standard way to plug the AI into your other things, your files or another app, so it can actually use them instead of working blind. Part of [Working with AI](https://vibe2value.com/working-with-ai/). The soft skills behind it: [The soft skills of working with AI](https://vibe2value.com/the-soft-skills-of-working-with-ai/). **Why Claude.** When this page carries tool-specific notes they use Claude Code, because it is one of the most widely used AI tools for building software. It is also what we build with day to day. The moves themselves are general and carry across to other capable AI tools. ### Working with AI URL: https://vibe2value.com/working-with-ai/ Last updated: 2026-08-31T23:33:47.000Z [For developers](https://vibe2value.com/for-developers/) › Working with AI Working with AI well is a craft, not a single trick. This is the map of it: the ways of working with AI across the life of a piece of work, how those same moves land in the tool, and the soft skills underneath. Some pages are fuller than others for now, with more still to come. Say it another way In plain words: getting good results from AI is a set of skills, not one magic trick. This page is the map of those skills, set out roughly in the order you use them, from working out what you actually want, to building it, to keeping it running once people rely on it. Each skill has its own page. Start wherever matches what you are doing right now. shape+build+launch+run+closeorganise the workWorking with AIThe six waysthe craft, by whatyou are doingWorking with Claudethe same moves,in the toolSoft skillsthe human habitsunderneath shape+build+launch+run+close is the practical framework that organises the work. Working with AI is how you do that work with AI, across three layers: the six ways, the same moves gathered as Working with Claude in the tool, and the soft skills underneath. ## The ways of working with AI Six ways of working with AI, each explained in plain terms, roughly in the order a piece of work moves through it. Each is its own page. | [Get to a sharp answer](https://vibe2value.com/ways-to-get-to-a-sharp-answer/)Turn a vague request into a clear brief you can act on. | Live | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | | [Build it with AI](https://vibe2value.com/ways-to-build-it-with-ai/)Choose how to build, based on how big or risky the change is. | Live | | [Make the output trustworthy](https://vibe2value.com/ways-to-make-the-output-trustworthy/)Check what AI gives you until it is something you can stand behind. | Growing | | [Build an AI agent](https://vibe2value.com/ways-to-build-an-ai-agent/)Set up AI to run tools and take steps on its own, inside limits you set. | Growing | | [Run it for real](https://vibe2value.com/ways-to-run-it-for-real/)Keep a live system reliable once real people depend on it. | Live | | [Set AI up to help](https://vibe2value.com/ways-to-set-ai-up-to-help/)Give AI your project's rules and context so it works the way you do. | Growing | ## Doing it in the tool The same moves, gathered by what you are doing with the tool: [Working with Claude](https://vibe2value.com/working-with-claude/). ## Designing the system The structure underneath the craft: how the work runs, what it can reach, and where it is hosted. [Designing the system](https://vibe2value.com/designing-the-system/). ## The soft skills underneath The human habits that make all of it work: [The soft skills of working with AI](https://vibe2value.com/the-soft-skills-of-working-with-ai/). ## Getting the work organised These two fit together as a route and how you drive it. The shape+build+launch+run+close framework is the route: a practical way to move a piece of work through five phases, Shape then Build then Launch then Run then Close, across 35 ideas, walked front to back once per project. The ways above are how you drive. They are not a sequence. You use the same one many times over. Getting an ask sharp happens all through Shape. Checking output you can stand behind happens in Build and again after launch. Every one of the 35 ideas ends in a move you make with AI. Each now names the single way that move needs, so you can go straight from the decision in front of you to the practice that carries it out. One deliberate exception. Building an agent is not one of the 35\. Handing AI a goal to run on its own is a technique you might reach for inside almost any idea rather than a decision the framework asks you to make, so it sits outside the route on purpose. [Ways to build an AI agent](https://vibe2value.com/ways-to-build-an-ai-agent/) covers it in its own right. ### Start here URL: https://vibe2value.com/start-here/ Last updated: 2026-08-31T23:32:35.000Z New to all this? You are in exactly the right place. This is the plain-English way in, with no jargon and no assumptions. ## What vibe2value is It is for people who want to build things with AI, small useful tools and apps, and actually trust what they make. You do not have to be a programmer to begin. You do need to want to make something. You do not need to know how to code. If you can describe what you want in plain words, the way you would explain a job to a helper, you can make a start. The clever part is the thinking and the judgement, and that part stays with you. The AI does the typing. ## What "building with AI" means Making software used to mean writing code by hand. Now you can describe what you want in plain words and an AI helps build it. That is powerful, and a little risky, because it is easy to end up with something that looks right but is not. The whole point of this site is that second half: building with AI and being able to trust the result. You describe itin plain wordsAI builds itClaude does the workYou check itand decide to trust it You stay in charge at both ends. The AI does the middle bit. Think of AI as a fast, eager helper who has read almost everything but has never met you or your project. It will happily make whatever you ask. The skill, and what this site teaches, is knowing what to ask for and how to check that what comes back is any good. ## How the site is laid out Everything on this site hangs on one simple idea. ShapeDecide what to makeBuildMake it with AILaunchPut it in front of peopleRunKeep it honestCloseDecide if it goes on Every piece of work moves through five stages. - **Shape**, decide what you are actually making. - **Build**, make it with AI. - **Launch**, put it in front of real people. - **Run**, keep it honest once people rely on it. Think of it like cooking for friends. Shape is working out what dish to make and who it is for. Build is actually cooking it. Launch is putting it on the table and seeing how they like it. Run is making sure it is just as good the next time. Same four steps, whatever you are making. There are 35 short ideas spread across those five stages, and each one ends in a practical move you make with AI. Open any of those 35 ideas and you will find the same six steps, so once you can read one you can read them all. The shape of every ideathe same six steps on all 35 pages. Learn to read one and you can read them all.1The callthe one decision to make2Sharpen it with AIa ready prompt, or Guide me3See it plainlya recipe card and an example4Check ita clear pass or fail5Write it downa small file your AI reads6Need a hand?the full write-up, or a 1:1each file adds to your context, ready for the next idea The call is the one decision the idea asks you to make. Sharpen it with AI using the ready prompt on the page, or let Guide me build it for you. See it plainly on the recipe card and a worked example. Check it against a clear pass or fail. Write it down as a small file your AI reads, which becomes part of your context for the next idea. Need a hand is the full write-up, or a 1:1. Although the examples here are framed around building an application, the same framework and process work in plenty of other settings. You could use them to create content for a website or organise an email campaign. The steps stay the same wherever you want a clear result you can trust. ## A promise about the words Some pages use the proper names for things, because those are the names you will meet in the real tools. Wherever that happens, look for a "Say it another way" box. Open it and you get the same thing in plain words, usually with an everyday comparison. Nothing here is meant to go over your head. ## What each page covers In plain words, here is where the rest of the site takes you: **Working with AI.** A map, not a lesson. It points you to the separate skills of working with AI, laid out roughly in the order you use them, so you can pick the one that matches what you are doing right now and start there. **Working with Claude.** The practical moves for working with Claude, the AI coding tool, sorted by what you are doing at the keyboard rather than by stage. Know the moment you are in (getting the ask clear, planning a big change, checking the result or keeping a live system honest) and you can jump straight to the help for it. **Ways to get to a sharp answer.** Getting from a vague idea to a clear first draft, for when you are stuck at a blank page. Let the AI interview you, show it an example to copy or ask it for a few options to choose from, then run the draft through Sharpen to tighten it. **Ways to make the output trustworthy.** Trusting what AI gives you, so you can rely on it without re-checking every line by hand. Ask for a fixed shape rather than free text, give worked examples, check the values and feed back anything wrong, get a fresh set of eyes to review and make sure your checks do not cry wolf. **Ways to run it for real.** Life after launch, once real people are using what you built. The job shifts from making it to keeping it trustworthy: hold on to the important decisions, decide in advance what the AI handles alone and what it must hand back, make failures show up clearly and have a fresh set of eyes review the work. **Ways to set AI up to help.** Setting AI up before you ask it to build, so it already knows how your project works. You give it your project's memory and rules in a file it reads each time it starts, so it builds the way your project already does instead of guessing every time. ## Where to go next Take your time. When you are ready, this is the order the rest of the site is meant to be used in. 1. **The framework.** Decide what to make, build it, put it in front of people, then keep it honest. [shape+build+launch+run+close →](https://vibe2value.com/framework/) 2. **Your next build.** Turn the thing you are building into the prompts that walk you through each decision. [Guide me with my next AI build →](https://vibe2value.com/guide-me/) 3. **What the model forgets.** It forgets every time, so this is how you hold on to what you have already decided. [Manage your context →](https://vibe2value.com/your-context/) 4. **Go deeper.** The practical detail underneath all of it. [For developers →](https://vibe2value.com/for-developers/) **Or take the whole method in one piece.** A free coffee-length read that goes from a rough idea to something you can trust. Download it, no signup. [The guide →](https://vibe2value.com/guide/) ## Not understanding it all is fine You will not follow every word on this site, and that is completely fine. Nobody starts out knowing this. The point is not to understand everything before you begin. It is to make a start and pick the rest up as you go. If you would like a hand, just say where you are up to and we will work it out together, at your pace. No question is too basic or too simple to ask. [matt@vibe2value.com](mailto:matt@vibe2value.com) Feeling unsurethat is normalAsk mewe talk it throughBuildingwith confidence You do not have to work it out alone. ### For developers URL: https://vibe2value.com/for-developers/ Last updated: 2026-08-31T23:32:37.000Z You already write code. This is for the part that does not come from the compiler: deciding what to build, getting the ask sharp enough that AI builds the right thing, then trusting the output enough to put it in front of people. This is how I work, not the way. Disagree with it usefully. ## Everything in this section ### How a change moves What counts as one change and how it gets from an idea to live. #### Set AI up to help [Set AI up to help](https://vibe2value.com/ways-to-set-ai-up-to-help/). Give AI your rules and context so it works the way you do. - [**Project memory and rules**](https://vibe2value.com/project-memory-and-rules/). The conventions it should already know before it starts. - [**Custom slash commands and skills**](https://vibe2value.com/custom-slash-commands-and-skills/). Package the jobs you do often. - [**Path-scoped rules**](https://vibe2value.com/path-scoped-rules/). Guidance that switches on only when it is relevant. - [**The tools and information Claude can reach**](https://vibe2value.com/the-tools-and-information-claude-can-reach/). MCP servers, and why switching one on costs nothing but is not free. #### Get to a sharp answer [Get to a sharp answer](https://vibe2value.com/ways-to-get-to-a-sharp-answer/). Turn a vague request into a brief you can act on. - [**Interview me**](https://vibe2value.com/interview-me/). Let AI ask you the questions and build the draft from your answers. - [**Show by example**](https://vibe2value.com/show-by-example/). Give it an example or two and let it infer the shape for yours. - [**Give me options**](https://vibe2value.com/give-me-options/). Ask for several distinct candidates and choose. - [**Then sharpen**](https://vibe2value.com/then-sharpen/). Tighten a draft until two people would decide the same way. #### Build it with AI [Build it with AI](https://vibe2value.com/ways-to-build-it-with-ai/). Choose how to build, by how big or risky the change is. - [**vibeCode**](https://vibe2value.com/vibecode/). Fast and loose, for small clear work you can eyeball. - [**Plan first**](https://vibe2value.com/plan-first/). Explore and design before you write any code. - [**Test first**](https://vibe2value.com/test-first/). Write the tests, then let AI iterate until they pass. - [**Build carefully**](https://vibe2value.com/build-carefully/). Smaller steps, review each one. - [**Finding your way around a codebase**](https://vibe2value.com/finding-your-way-around-a-codebase/). Glob, grep and read are a ladder in increasing order of cost. ### What it is made of What the parts are, where each one runs and what choosing them committed you to. #### Designing the system [Designing the system](https://vibe2value.com/designing-the-system/). The structure underneath the craft: how the work runs, what it can reach and where it is hosted. - [**How the AI works**](https://vibe2value.com/how-the-ai-works/). Claude is the intelligence, and how you structure its work is its own set of decisions. - [**Where the code runs**](https://vibe2value.com/where-the-code-runs/). Hand the code over and it runs on machines all over the world, with no server to manage. - [**Where the content lives**](https://vibe2value.com/where-the-content-lives/). A ready-made place to write, store and publish, with the editing and reading already built. - [**Headless and wired with APIs**](https://vibe2value.com/headless-and-wired-with-apis/). Splitting the writing end from the reading end, joined by an API. - [**When to use AI and when not to**](https://vibe2value.com/when-to-use-ai-and-when-not-to/). A deterministic step gives the same answer every time. Some work needs that and some needs judgement. - [**The two kinds of answer**](https://vibe2value.com/the-two-kinds-of-answer/). One has a right answer, the other needs weighing up. They want different machinery. - [**Which to reach for**](https://vibe2value.com/which-to-reach-for/). Choosing between them case by case, rather than as one decision about the whole system. - [**What each one costs**](https://vibe2value.com/what-each-one-costs/). One is paid for in tokens and time on every run, the other is written once and then costs nothing. - [**Which model, once you have decided it is AI**](https://vibe2value.com/which-model-once-you-have-decided-it-is-ai/). Three tiers, and the same trade wherever you look. #### Build an AI agent [Build an AI agent](https://vibe2value.com/ways-to-build-an-ai-agent/). Set AI up to run tools and take steps on its own, inside limits you set. - [**The agent loop**](https://vibe2value.com/the-agent-loop/). The loop is your code, not the model's. What each pass does and how it stops. - [**Write tool descriptions the model can choose from**](https://vibe2value.com/tool-descriptions-the-model-can-choose-from/). The description is not documentation, it is how the model chooses. - [**Which tools each agent gets**](https://vibe2value.com/which-tools-each-agent-gets/). More tools means worse selection. The cost is in the choosing. - [**Work out the steps before you split the work**](https://vibe2value.com/work-out-the-steps-before-you-split-the-work/). Whether you hold the pattern already or have to go and find it. - [**Let one agent hold the whole picture**](https://vibe2value.com/let-one-agent-hold-the-whole-picture/). The coordinator is the only thing holding the whole job. - [**Pass everything the helper needs**](https://vibe2value.com/pass-everything-the-helper-needs/). If a fact is not passed, it does not exist for that helper. - [**Send independent work out together**](https://vibe2value.com/send-independent-work-out-together/). Parallel is not a setting, it is where the calls sit. - [**Hooks that always run**](https://vibe2value.com/hooks-that-always-run/). A prompt gives a tendency and a hook gives a guarantee. - [**How much to let AI decide**](https://vibe2value.com/how-much-to-let-ai-decide/). You do not choose a shape, you choose what to decide. - [**Guaranteeing the steps that matter**](https://vibe2value.com/guaranteeing-the-steps-that-matter/). A prompt asks, code guarantees. - [**What kind of failure is it**](https://vibe2value.com/what-kind-of-failure-is-it/). Saying which kind it was is what makes the next move obvious. - [**A prompt template is a unit of measurement**](https://vibe2value.com/a-prompt-template-is-a-unit-of-measurement/). What goes into one, and why the name on it is what lets cost, latency, model and quality land on the same row. #### Prompt engineering with Claude [Prompt engineering with Claude](https://vibe2value.com/prompt-engineering-with-claude/). The details worth keeping at hand, the footnotes that shape the design. - [**A worked example: what the tools hand back**](https://vibe2value.com/a-worked-example-what-the-tools-hand-back/). One example carried the whole way through, showing what each step actually returns. ### Why it is this way Which calls are costly to reverse and where the reasoning is written down. [Decide what the agent may do](https://vibe2value.com/ways-to-decide-what-an-agent-may-do/). Where the rules live once there are no screens holding them. - [**The forms were the policy**](https://vibe2value.com/forms-were-the-policy/). What the screens were quietly enforcing, and why nobody has the list written down. - [**Three places a rule can live**](https://vibe2value.com/three-places-a-rule-can-live/). In the form, once when it is set up, or at the moment of the call. What each one costs you. - [**What permissions were never built for**](https://vibe2value.com/what-permissions-were-never-built-for/). Composition and context: the two questions roles and privileges cannot answer. - [**Inherit the policy, do not rebuild it**](https://vibe2value.com/inherit-the-policy/). Enforce it where it is already enforced, and the agent cannot exceed the person. ### What proves it works What is tested, at what level and what is deliberately not tested. #### Make the output trustworthy [Make the output trustworthy](https://vibe2value.com/ways-to-make-the-output-trustworthy/). Check what AI gives you until it is something you can stand behind. - [**Ask for a shape, not prose**](https://vibe2value.com/ask-for-a-shape-not-prose/). Hand it a schema and have it fill that in. - [**Examples keep extraction honest**](https://vibe2value.com/examples-keep-extraction-honest/). Worked examples stop it inventing values that were never there. - [**Validate and retry**](https://vibe2value.com/validate-and-retry/). Feed back the specific failure so it corrects that exact thing. - [**Review with fresh eyes**](https://vibe2value.com/review-with-fresh-eyes/). The maker is the worst reviewer of its own work. - [**Guard against false positives**](https://vibe2value.com/guard-against-false-positives/). One category that cries wolf costs you trust in all of them. - [**Keeping the source on every claim**](https://vibe2value.com/keeping-the-source-on-every-claim/). Without the source, a checked figure and a guess read the same. #### Iterating on the decisions [Iterating on the decisions](https://vibe2value.com/iterating-on-the-decisions/). Holding the decisions apart from the document, what a refining loop can improve and what it cannot. - [**The artifact is the only thing that knows what is missing**](https://vibe2value.com/the-artifact-knows-what-is-missing/). Precision is not coverage and coverage is what decides how much gets invented. - [**Take the countable part off the model**](https://vibe2value.com/take-the-countable-part-off-the-model/). Eleven times the answer was the same and it was never about asking more carefully. - [**Checks that report green**](https://vibe2value.com/checks-that-report-green/). The worst result a test can give you is a clean one it was never able to fail. - [**Rules that pull against each other**](https://vibe2value.com/rules-that-pull-against-each-other/). Close every honest exit and a model will take a dishonest one. - [**Everything you hand a model becomes material**](https://vibe2value.com/everything-you-hand-a-model-becomes-material/). Including your worked examples, your warnings and the diagnosis you wrote for yourself. ### Where it runs and how it gets there Which environments exist, where secrets live and what a deploy actually does. - [**Running Claude in a pipeline**](https://vibe2value.com/running-claude-in-a-pipeline/). Nobody at the keyboard, so anything that pauses hangs the build. ### What happens when it breaks How a failure surfaces, what is handled without you and what comes to you. [Run it for real](https://vibe2value.com/ways-to-run-it-for-real/). Keep a live system honest once people depend on it. - [**Hold the context**](https://vibe2value.com/hold-the-context/). Keep the real findings somewhere the conversation cannot round off. - [**Know when to step in**](https://vibe2value.com/know-when-to-step-in/). Decide in advance what AI handles and what comes to you. - [**Fail well**](https://vibe2value.com/fail-well/). Make failures surface clearly, with enough context to recover. - [**When a step goes wrong**](https://vibe2value.com/when-a-step-goes-wrong/). Never hide it and never stop everything. - [**Where a person should look**](https://vibe2value.com/where-a-person-should-look/). Spend limited review time where it changes the outcome. - [**When nothing is waiting on the answer**](https://vibe2value.com/when-nothing-is-waiting-on-the-answer/). Half the cost if you can wait. One question decides which lane. - [**The cost is measured, the quality is not**](https://vibe2value.com/the-cost-is-measured-the-quality-is-not/). Cost and tests report themselves. The thing that decides whether it was worth doing does not. ### Also in this section - [**Working with AI**](https://vibe2value.com/working-with-ai/). The map of the craft, and how the six fit together. - [**Working with Claude**](https://vibe2value.com/working-with-claude/). The same material indexed by what you are doing in the tool. - [**The soft skills of working with AI**](https://vibe2value.com/the-soft-skills-of-working-with-ai/). The human habits underneath all of it. - [**recipeCard**](https://vibe2value.com/project/recipecard/). The worked example, built in the open. ## Start with the framework The heart of the site is the [shape+build+launch+run+close framework](https://vibe2value.com/framework/): 35 short ideas across five stages. Shape is deciding what to make and who for. Build is making it with AI. Launch is putting it in front of people and learning from what happens. Run is keeping it honest once people rely on it. Close is deciding whether it should still exist. Close is deciding whether it should still exist. Read them in order the first time, then come back by stage when you hit the matching moment in a real project. make each decision sharp before you write codeShapedecide what to makeBuildbuild itLaunchput it in front of peopleRunkeep it honestClosedecide if it goes onHow the skill helps at every stepthe right prompt for each decision, taking your answer from vague to sharpit returns a clear verdict and tells you when it is good enough to stop The vibe2value framework moves a project through five stages and the skill helps you make each decision sharp before any code is written. ## Use it in your editor The framework runs as a skill your AI can follow while you build. In Claude Code, add the marketplace and install it: ``` /plugin marketplace add vibe2value/claude-plugins /plugin install shape-build-launch-run-close@vibe2value /reload-plugins ``` 1. After installing, run `/reload-plugins` to apply it. 2. Then use it, depending on your tool: - **Claude Code:** it surfaces on its own when you are working through a build decision, or call it with `/shape-build-launch-run-close:guide`. Either way it runs the loop with the exact Sharpen prompt for each of the 35 ideas built in. - **ChatGPT, Claude or Cursor:** paste [vibe2value.com/skill.txt](https://vibe2value.com/skill.txt) for the method, or [vibe2value.com/skill-full.txt](https://vibe2value.com/skill-full.txt) for every prompt inline. - **Any other tool:** point it at [vibe2value.com/llms.txt](https://vibe2value.com/llms.txt) for the full index. ## Common questions 1. **Where did this come from?** Much of what is here was put together while I was studying for the [Claude Certified Architect Foundations certification](https://anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification?ref=vibe2value.com). The study was the occasion rather than the point: it made me go back over how I think about this work now, and how that changes the way I actually do it. 2. **What is the difference between the two sets of pages?** Working with AI is the map: six ways of working, laid out in roughly the order a piece of work moves through them. Every page of detail hangs off one of those six. 3. **When would I use Working with Claude instead?** Working with Claude is the same material indexed a second way, by what you are doing in the tool rather than the stage you are at. It is the faster door once you already know the move you want. 4. **I already know how to build. Why is this worth my time?** Writing the code was never the hard part and with AI it matters even less. What is left is a way of working: what you set up before you start, how you cut the job up, and what you check before you believe it. 5. **Is a way of working a knack you either have or you do not?** No. The things on these pages are practices rather than instincts, which means you can pick them up this week rather than wait years to acquire the feel for them. ## Want a hand? If you would rather talk it through, tell me what you are building and I'll help you find the right starting point. No question is too basic or too simple to ask. [matt@vibe2value.com](mailto:matt@vibe2value.com) ### Designing the system URL: https://vibe2value.com/designing-the-system/ Last updated: 2026-08-28T12:07:08.000Z [For developers](https://vibe2value.com/for-developers/) › Designing the system Designing the system comes down to one habit: matching the system to the need. At each decision you fit the choice to what the work actually requires, rather than reaching for a default. It is the system side of working with AI, the structure the work runs inside. Here is the shape of a system like this one: a handful of separate parts, each with one job, wired together. This is only a suggested high-level blueprint, not the one right answer. Notice that Claude shows up twice, in two different jobs: it builds the static front end before launch, and the running system asks it for answers once it is live. visits \[HTTPS\]reads content \[Content API\]calls \[JSON / HTTPS\]asks \[API\]builds the front end\[build time\]Visitor\[Person\]uses the siteFront end\[Container: static site\]what people seeContent\[Container: CMS\]headless: content via an APICode\[Container: serverless platform\]your logic, behind an APIClaude\[Claude\]builds it and runs inside itClaude shows up in two different jobs here. At build time it builds the static front end(the dashed arrow). At run time the code asks it for an answer (the solid arrow), the sameway the front end asks the CMS for content. Using AI to build the system and using AI insidethe running system are different decisions; the prompting craft is similar across both. A container view in the C4 style: separate containers wired together by APIs. The visitor uses the front end, which reads content from a CMS over its headless content API and calls your code, which asks Claude at run time. Separately, at build time, Claude builds the static front end. Same model, two different jobs. Each part has one job, and you match it to what the work needs: - **How the AI works** — Claude, the intelligence: how to structure the work it does, from a single call to agents, tools and safeguards. These are prompt-engineering decisions, covered on their own page. - **Where the code runs** — for example Cloudflare Workers. - **Where the content lives** — a CMS, for example Ghost. ## Headless and wired with APIs These pieces are not one block of code. [Headless and wired with APIs →](https://vibe2value.com/headless-and-wired-with-apis/) ## Where the code runs Where your code runs is a design decision, not an afterthought. [Where the code runs →](https://vibe2value.com/where-the-code-runs/) ## Where the content lives Where your content lives is a separate decision from where the app runs. [Where the content lives →](https://vibe2value.com/where-the-content-lives/) ## How the AI works Claude is the intelligence in the system. [How the AI works →](https://vibe2value.com/how-the-ai-works/) ## When to use AI and when not to Some of the work needs judgement and the rest has a right answer. Those two want different machinery and they cost very different amounts. [When to use AI and when not to →](https://vibe2value.com/when-to-use-ai-and-when-not-to/) Part of [Working with AI](https://vibe2value.com/working-with-ai/). These are Shape decisions, made before and around the build, organised by the [shape+build+launch framework](https://vibe2value.com/framework/). The craft side of working with Claude is [Working with Claude](https://vibe2value.com/working-with-claude/). ### Prompt engineering with Claude URL: https://vibe2value.com/prompt-engineering-with-claude/ Last updated: 2026-07-28T03:59:40.000Z [For developers](https://vibe2value.com/for-developers/) › Prompt engineering with Claude Prompt engineering with Claude is more than the wording of a single prompt. It is how you structure the work it does and what happens around it. Each decision below is the same move, match it to what the work needs, taken roughly from the request inward. Some are written up; others are still to come. The broader craft of working with Claude is [Working with Claude](https://vibe2value.com/working-with-claude/); the system it all runs inside is [Designing the system](https://vibe2value.com/designing-the-system/). Say it another way Knowing how to prompt Claude is one thing; deciding how its work is structured is another. Should an answer come back now, or can it wait? Is this one call, a chain of steps, or an agent left to run? What can it reach, and what catches it when it goes wrong? Each is the same question, does this fit what the job needs, asked of a different part. ## Match the run to the need The first decision is how a request runs. The synchronous lane is the normal call: you send a request, wait, and get the answer back in seconds at full price. Batch processing is the opposite: you hand over many requests at once, walk away, and collect the results later, for about half the cost, but with no promise of when inside an up-to-a-day window. The deciding question is simply: is anything waiting on this? If yes, take the synchronous call and pay for speed. If no, batch it and take the saving. If you batch, these are the details worth keeping at hand, the footnotes that shape the design: - **Meeting your own deadline.** A batch can take up to its full window, and queued requests also wait for the next submission, so the worst case is the wait for the next batch plus the processing window. If you promise users a turnaround, submit often enough that wait-plus-window still beats your promise. - **Matching answers to questions.** Batch results come back in any order, so you attach an id you choose to each request and it is returned on each result. You match by that id, never by position, or you will pair the wrong answer with the wrong question. - **Handling failures.** Not every request in a batch succeeds. You resubmit only the failed ones, found by their id, and after fixing the cause rather than blindly resending, for example splitting a request that was too big. You do not redo the whole batch. - **One shot, no back-and-forth.** A batch request is a single turn and cannot hand control back to you mid-request and resume, so it cannot run a tool, take your result, and continue. Anything needing that loop has to happen outside the batch. Each request must be self-contained. - **You check on it; it does not call you.** You poll the batch to see when it is done and then fetch the results; it does not notify you when it finishes. - **Prove it small first.** Test the prompt on a small but representative sample before running the whole batch. A flaw you only find at full scale means paying for and redoing the entire run. The shape of this decision is durable; the exact figures, the discount, the maximum window and the size limits, are provider specifics that move, so check the current Anthropic Message Batches documentation for today’s numbers rather than trusting one baked into a page. ## Match the shape to the need One call, a workflow where you set out the steps yourself, or an agent left to find its own way. The usual advice is to pick the one that fits, but the shape is not really the choice. Every job is a run of forks. Each one is settled either by you in advance or by the system at runtime. Keep them all and you have written a single call; keep only the tools and the boundary around them and you have written an agent. Nobody picks agent, they just hand over enough forks that agent is what it becomes. Which forks to keep is [How much to let AI decide](https://vibe2value.com/how-much-to-let-ai-decide/). ## Match the orchestration to the need One Claude agent, or a coordinator handing parts to subagents that work in parallel, and how context passes between them without losing the thread. To come. ## Match the connections to the need The tools Claude can reach, and MCP as the standard way to plug it into your files and other systems, so it is acting on real information rather than working blind. To come. ## Match the inputs to the need Every tool you connect answers in its own dialect: a date as a number here, the same date as text there, success as a code from one and as the word ok from its neighbour. Handed that raw, Claude spends its reasoning converting rather than thinking, on every result, forever. Converting a date format is not a judgement call, so it belongs in code. That is the clearest worked example of a bigger decision, and it lives on [When to use AI and when not to](https://vibe2value.com/when-to-use-ai-and-when-not-to/). ## Match the guarantees to the need Telling Claude to do something is a request, not a guarantee. It will usually follow a clear instruction, but usually is not always, and for the steps that move money or go out to a customer that gap is the whole problem. The way to close it is not a firmer sentence, it is a check in the code around Claude. Which steps earn one, and how to gate on what actually happened rather than what the model says happened, is [Guaranteeing the steps that matter](https://vibe2value.com/guaranteeing-the-steps-that-matter/). ## Match the safeguards to the need Failures are not rare events in a system built from separate parts; they are a normal part of how it runs. Hiding one lets a wrong answer through, and crashing on one throws away everything the other parts got right. The path between them, and why an empty result is not the same fact as a failed lookup, is [When a step goes wrong](https://vibe2value.com/when-a-step-goes-wrong/). ## Match the response to the failure Saying a step failed tells you nothing about what to do next. A passing blip, a malformed request, a firm no and something off-limits want four opposite responses, and a system that treats them alike will hammer a wall it can never get through. Naming the kind is what picks the move, and that is [What kind of failure is it](https://vibe2value.com/what-kind-of-failure-is-it/). ## Match the human checks to the need Some work can run on its own and some needs a person before it counts. Checking everything wastes the little review time you have; checking nothing is how the expensive mistakes get out. Where to spend the attention, and why one overall accuracy score hides the slice that is quietly failing, is [Where a person should look](https://vibe2value.com/where-a-person-should-look/). ## Match the sources to the need When an answer is gathered from many places, the source behind each claim tends to fall away as findings are tidied into one confident summary. After that a checked figure and an offhand guess read exactly alike. Keeping the source attached, and what to do when two credible ones disagree, is [Keeping the source on every claim](https://vibe2value.com/keeping-the-source-on-every-claim/). ## A worked example: what the tools hand back One example carried the whole way through, showing what each step returns. [A worked example: what the tools hand back →](https://vibe2value.com/a-worked-example-what-the-tools-hand-back/) Part of [Working with Claude](https://vibe2value.com/working-with-claude/). The system side is [Designing the system](https://vibe2value.com/designing-the-system/). ### recipeCard URL: https://vibe2value.com/recipecard/ Last updated: 2026-08-31T11:13:44.000Z `recipeCard` is a small app I am building in the open, using the shape+build+launch+run+close framework. The recipe card used as an example across the guides is deliberately simple, built on everyday cooking ideas everyone understands, so each concept is easy to grasp. Every decision behind it is documented the same way the subscription would do it for you: a named user, the problem it solves, the one main path, the shape of the system drawn as a C4 diagram, all kept in the knowledge base the AI builds from. More soon as it takes shape. This is the worked example that grows alongside the writing. ### Guide me URL: https://vibe2value.com/guide-me/ Last updated: 2026-08-31T11:12:10.000Z What are you building, or what has you stuck? Plain words are fine. One sentence or ten. The messier the better, that is what the guide is for. Add your project context optional Paste a summary of what you are building: your llms.txt, a repo summary or a doc. New to this? See [Your context](https://vibe2value.com/your-context/). Build my prompt Clear Paste-ready prompt · drop the whole thing into ChatGPT or Claude Copied Copy prompt Rebuild **This is the work.** Nothing is sent anywhere and nothing is stored. Keeping your own context is part of the work, that is why we do not hold it for you. See [Your context](https://vibe2value.com/your-context/) for how to manage it. ## Posts ### 5.1.3 - How It Ends Is the Part People Remember URL: https://vibe2value.com/how-it-ends-is-the-part-people-remember/ Last updated: 2026-09-07T06:31:03.000Z ## The ending Turning it off is the easy part. The people using it are the part that takes notice. ## The call Stopping is not switching it off. It is telling the people who use it, giving them their data and keeping the promise you made when they signed up. ## Sharpen the ending with AI This is a Close idea, so the AI move is **Run it for real**. You can sharpen the decision here, but it only means anything against something that is actually running. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real project and keep the instruction exactly as visible here. It helps you put your `stopping.md` together by refining your three lines until somebody who did not build this could act on them. ``` You are checking whether this has an ending, or only an off switch. Constraint: Everyone still using it must appear in the answer, along with what they are handed and what is left at the address afterwards. "Nobody is really using it" is not a count. Example of the standard: Vague: "I will just turn it off, nobody is really using it." Sharp: "Four people use it. They get four weeks' notice, an export of their whole log in a format they can open, the skill itself and an email from me rather than from the app. The policy was always theirs." The sharp version has a number, a notice period, a format and an address. The vague one has an assumption. Working draft: Who is still using it: [how many, and who] What they get: [notice, their data, in what form] What is left behind: [the domain, the repo, the page that explains] Task: Decide whether somebody else could carry out this ending from these three lines alone. If not, rewrite them to meet the standard above. If you have not actually counted the users, say so plainly rather than estimating. Check: - Have you counted the people, or assumed the number? - Can they open the export without you? - If someone follows an old link in a year, what do they find? Return: - Verdict: has an ending, or only an off switch - The corrected three lines - The thing you were about to skip ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. An ending is a launch in reverse, so it has the same two halves. That is [Where do you stop, for now?](https://vibe2value.com/where-do-you-stop-for-now/) plus [Name the risks yourself before users find them](https://vibe2value.com/name-the-risks-before-users-find-them/). ## The same idea on a recipe card A restaurant that closes puts a notice on the door weeks out, honours the bookings it already took and tells the regulars itself. One that simply does not open leaves people standing outside holding a reservation. Same closure, two completely different things to be remembered for. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means Stopping gets treated as a technical act. Turn off the service, cancel the domain, archive the repo. All of that takes an afternoon and none of it is the part that matters. The people still using a small thing are the ones who trusted you earliest, when there was least reason to. They are usually few enough to name. Turning it off quietly is the cheapest possible way to spend that trust, and it is spent permanently. So the ending has the same two halves as the launch did. Who is affected, and what they are handed. The difference is that nobody is going to chase you for it, which is exactly why it gets skipped. ## Make the ending concrete Compare the version that sounds responsible with the version somebody could act on. - **Too vague:** I will just turn it off, nobody is really using it. - **Concrete enough to test:** Four people use it. They get four weeks' notice, an export of their whole log in a format they can open, the skill itself and an email from me rather than from the app. The policy was always theirs. The second version could be carried out by somebody else. The first is a decision you have already made about people you have not counted. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). Who is still using itcounted, not assumedWhat they getnotice, and their own dataWhat is left behindan address that explainsThey remember how it endedwhich is the only part that outlives the thing Turning it off is one afternoon and none of this. The people still using a small thing trusted you earliest, when there was least reason to, and an ending is the last time you get to spend that well. ## Check the ending - **Pass:** Everyone still using it has been told, has their own data in a format they can open and knows where it went. - **Fail:** It goes off and somebody finds out because it stopped working. Nobody is going to chase you for this one. That is the whole reason to write it down. ## What you'll walk away with This post is about the closing decision: what you owe the people who trusted the thing. You'll come out with your own stopping.md naming who is still using it, what they are handed and what is left at the address afterwards. ## Write it down Your `stopping.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/product/stopping.md` is just a suggested name and place for this information. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. ## Risk and mitigation - **Risk:** The people using a small thing are the ones who trusted you earliest, and turning it off quietly is the cheapest possible way to spend that. - **Mitigation:** Notice, an export they can open without you, and a person's name on the email rather than the app's. ## Key takeaway Nobody remembers what your side project did. They remember how it ended. ## How to document your ending Write it up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # The ending ## Answer Who is still using it: [how many, and who] What they get: [notice, their data, in what form] What is left behind: [the domain, the repo, the page that explains] ## Evidence How many people are actually using it, taken from the logs rather than from memory. ## Decision What you are giving them and how long they get. What you are deliberately not doing. ## Risk What breaks if this is wrong. ## Standing instruction What the AI should do every time it touches this. For example: if I talk about shutting this down, ask who is still using it before helping with any technical step. ``` ### 5.1.1 - Would You Start This Today? URL: https://vibe2value.com/would-you-start-this-today/ Last updated: 2026-09-07T06:31:00.000Z ## Continue test Nothing is wrong with it. That is not the same as it earning its place. ## The call Run the continue test on a date, while things are fine. Whether something should still exist is a question you answer badly under pressure and well on a quiet Tuesday. ## Sharpen the continue test with AI This is a Close idea, so the AI move is **Run it for real**. You can sharpen the decision here, but it only means anything against something that is actually running. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real project and keep the instruction exactly as visible here. It helps you put your `continue.md` together by refining your three lines until somebody who did not build this could act on them. ``` You are checking whether this should still exist, or whether it is only still running. Constraint: The answer must be one of three: start again, pause with a named condition that unpauses it, or stop. Still going is not one of them. Example of the standard: Vague: "It is ticking along fine, I will keep an eye on it." Sharp: "It costs me the mailbox, the storage and the model calls, and four people use it. I would still start it today, so it stays until a month goes by with nobody sending." The sharp version has the running cost, who is actually using it and a door it walks through. The vague one has none of them. Working draft: Still earns its place: [why, in one line] What it costs you: [the real weekly cost] What happens next: [start again, pause with a trigger, or stop] Task: Decide whether these three lines pick one of the three answers. If they leave it running by default, say so and rewrite them to meet the standard above. Check: - If it were not already running, would you build it today? - Is the weekly cost a number, or a feeling? - Does the answer name a door, or leave it open? Return: - Verdict: start again, pause, stop, or not decided - The corrected three lines - The part of the cost that is not being counted ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. The test needs something to read before it can be answered. That is [Where do you stop, for now?](https://vibe2value.com/where-do-you-stop-for-now/) plus [How would you know if any of this worked?](https://vibe2value.com/how-would-you-know-if-any-of-this-worked/). ## The same idea on a recipe card A kitchen does not wait until it is failing to look at the menu. Every so often you take a dish and ask whether it earns its place. Would you put it on if it were not already there. Three answers come back. It comes off. It waits for the season. Or it goes back on, cooked differently. The one thing that is not an answer is leaving it there because it is already there. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means Every stage before this one asks whether the thing is good. This one asks whether it should exist. Those are different questions, and the second one almost never gets asked because nothing ever arrives to ask it. A project that is running does not send you a prompt. It takes twenty minutes here and an evening there, and the cost stays invisible because it is spread so thin. Inertia is not a decision, but it produces the same result as one. So the test goes on a date. Would you start this today, knowing what you now know? If the answer is no, you are not maintaining it. You are only not stopping it. ## Make the continue test concrete Compare the version that sounds responsible with the version somebody could act on. - **Too vague:** It is ticking along fine, I will keep an eye on it. - **Concrete enough to test:** It costs me the mailbox, the storage and the model calls, and four people use it. I would still start it today, so it stays until a month goes by with nobody sending. The second version has a cost, a user count and a door in it. The first has none of the three, which is how a thing stays on the list for years. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). It is still runningWould youstart it today?yes, but differentnot nownoStart againback to ShapePausewith what unpauses itStopand tell the people using it Three answers, and all three are real. There is a fourth path that is not drawn here, because it is not a door: carrying on unchanged because it is already running. That is what happens when nobody asks the question, and it is the only outcome you never actually chose. ## Check the continue test - **Pass:** You can say whether you would start it today, what it costs you in a normal week and which of the three answers comes next: start again, pause with a trigger, or stop. - **Fail:** It keeps running because it is already running. Inertia is the only answer that is not an answer. ## What you'll walk away with This post is about the closing decision: whether the thing should still exist at all. You'll come out with your own continue.md carrying an honest weekly cost, a straight answer to whether you would start it today and which of the three doors you are walking through. ## Write it down Your `continue.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/product/continue.md` is just a suggested name and place for this information. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. ## Risk and mitigation - **Risk:** Projects survive on inertia rather than on merit, and the cost stays invisible because it is spread thin across every week. - **Mitigation:** Put the test on a date and run it while nothing is wrong. The answer is only honest when nothing is forcing it. ## Key takeaway If you would not start it today, you are not maintaining it. You are just not stopping it. ## How to document your continue test Write it up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Continue test ## Answer Still earns its place: [why, in one line] What it costs you: [the real weekly cost] What happens next: [start again, pause with a trigger, or stop] ## Evidence What it has actually cost you in the last month, not what you meant it to. ## Decision Which of the three answers you picked, and the date you will ask again. ## Risk What breaks if this is wrong. ## Standing instruction What the AI should do every time it touches this. For example: if I ask for something new on a project marked pause or stop, say so before building it. ``` ### 4.3.2 - How Would You Know If Any of This Worked? URL: https://vibe2value.com/how-would-you-know-if-any-of-this-worked/ Last updated: 2026-09-07T06:30:58.000Z ## Evidence it worked You have written it all down. What actually tells you it made any difference? ## The call Take three numbers before you write anything and again as you go. Decide now which one you would act on, because two of them are interesting and only one of them matters. ## Sharpen evidence it worked with AI This is a Run idea, so the AI move is **Run it for real**. This one is different from the rest: the prompt does not sharpen a sentence, it takes the reading and hands you the numbers. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). There is nothing to replace in this one. Point an AI at your project, paste it as it is and read what comes back. Run it once before you write anything, then again whenever you want to know if it is still working. ``` You are taking a reading, not sharpening a sentence. Do the work first, then report. Task: Work through knowledge-base/ and fill it in, so the next person or the next AI could pick this project up from what is written there. Do not ask me anything. Make the best call you can and keep going. Then report three numbers and nothing else. Invented: Every statement you made about this project that you could not source from something already in the repo. List them one per line, each naming the file you put it in. This is the number that matters, so do not soften it. Named gaps: Every place you wrote that something is not decided yet rather than filling the space. List them one per line. Size: The word count of knowledge-base after you finished. Return: - The three counts - Both lists in full - One sentence on which file was hardest to fill and why Then stop. Do not offer to fix anything. The person reading this is the only one who can tell which of your statements are actually false. Your list is where they start rather than the verdict. ``` Copy this into AI chat. This one runs as it is. What comes back is a starting list, not a verdict, so read it yourself. Reading your own work honestly is the hard part, which is why [Review with fresh eyes](https://vibe2value.com/review-with-fresh-eyes/) exists, along with [Guard against false positives](https://vibe2value.com/guard-against-false-positives/). ## The same idea on a recipe card You think the oven is at 180 because the dial says 180\. Until you put a thermometer in, you are cooking on the dial's opinion of itself. Cooks who never take the reading do not find out the oven is wrong. They find out that everything comes out slightly off, blame the recipe and adjust the wrong thing for years. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means Writing things down feels productive. That is the problem, because it goes on feeling productive long after it has stopped changing anything. There is no point at which it announces itself as busywork. Every idea in this framework has its own pass and fail, so you can tell whether one answer is good. None of them tells you whether the whole thing is working. That gap sits exactly where a person is deciding whether the effort was worth repeating. Three numbers close it. How much an AI invented about your project, how many gaps it named instead of filling, plus how big the base has got. Invented is the one that matters. The other two are context for it. One honest limit. An AI reporting on what it invented is a starting list rather than a verdict, because it does not know which of its confident statements are false. You do. That is the whole reason this measure works and it is also why you cannot skip reading it yourself. ## Make evidence it worked concrete Compare the version that sounds encouraging with the version somebody could argue with. - **Too vague:** It definitely helps. The AI seems to pick things up much faster now. - **Concrete enough to act on:** Before I wrote anything down, the AI invented a dashboard and a draft-writing step that consideredContent does not have, and it named no gaps. After the Shape and Build files it invented nothing, and it named four gaps, including that Run and Close were not written yet. The second version can be wrong, which is what makes it worth having. The first cannot be wrong about anything. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). Baselineinvented 7, gaps 05,100 wordsbefore you write anythingyou fill it inSecond readinginvented 1, gaps 48,400 wordsany time you like7 → 1inventedSkip the baseline and the second reading is just a number. Two readings and the fall between them is the evidence. The second one you can take whenever you like. The first can only be taken before you write anything, which is why it is the one people skip and the one that makes the rest mean something. ## Check evidence it worked - **Pass:** You have a baseline taken before you wrote anything, a later reading to compare it against, with invented falling. - **Fail:** You have never taken the number, so "it feels better" is the only evidence you have. A number you have never taken cannot go down. ## What you'll walk away with This post is about the running decision: what has to be true once the thing is already live. You'll come out with your own `knowledge-base/README.md` carrying a baseline row with a date on it, at least one later reading beside it and a decision about which of the three numbers you would actually act on. ## Write it down The readings go in a table in your `README.md`, because a scoreboard belongs on the front of the thing it is scoring. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. `knowledge-base/README.md` is just a suggested place for this. Put it wherever suits your project. What matters is that the numbers have dates on them and that the first one was taken before you started. ## Risk and mitigation - **Risk:** You keep writing things down because it feels productive, long after it stopped changing what the AI does. - **Mitigation:** Take the baseline before you write a word. It costs one run. It is the only reading you can never go back for. ## Key takeaway Take the baseline before you write anything. It is the only reading you cannot get later. ## How to document your evidence it worked Keep the readings together with a date on each one, so the trend is visible rather than remembered. Keep it in a file with your project like this. ``` # Evidence it worked ## Answer | Date | Invented | Named gaps | Size | Note | |---|---|---|---|---| | | | | | baseline, before anything was filled in | ## Evidence What you actually saw change in how the AI behaves, not what you hoped for. ## Decision Which number you act on and what you do when it stops falling. ## Risk What breaks if this is wrong. ## Standing instruction What the AI should do every time it touches this. For example: when you state something about this project that is not written down anywhere in the repo, mark it rather than asserting it. ``` ### 5.1.2 - Where Do You Stop, For Now? URL: https://vibe2value.com/where-do-you-stop-for-now/ Last updated: 2026-09-07T06:31:01.000Z ## Stopping point It is running, nothing is wrong, so why are you still in there? ## The call Stop by writing down what is left rather than by deciding you are finished. Everything still open is either out of scope on purpose or a deferred decision with the condition that unpauses it. ## Sharpen stopping point with AI This is a Run idea, so the AI move is **Run it for real**. You can sharpen the decision here, but it only proves out against a system that is actually live. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real project and keep the instruction exactly as visible here. It helps you put your `deferred-decisions.md` together by refining your three lines until somebody who did not build this could act on them. ``` You are checking whether you have decided to stop, or only run out of energy. Constraint: Everything you are still carrying must be written down as either out of scope on purpose or a deferred decision with a named condition that unpauses it. Nothing important is left in your head. Example of the standard: Vague: "It is basically done, I just want to tidy a few things up." Sharp: "It runs on about twenty minutes a week: read the failures nobody reported and clear the review queue. Two things are paused. A second skill is deferred until somebody asks for it. Writing the post, scheduling and analytics are out of scope on purpose. I open it again if two digests in a row fail, or if someone asks for a second skill." The sharp version names the running cost, the paused things and the trigger for each. The vague one names none of them, which is why it never ends. Working draft: What it asks of you in a normal week: [the real ongoing cost] Paused, plus what unpauses each one: [the deferred decisions] Out of scope on purpose: [and why] Task: Decide whether this is a stopping point or a pause in the tinkering. Anything you are still carrying that does not appear in one of those three lines is the thing to write down before you stop. Check: - Is there anything you mean to get back to that is not written down? - For each paused thing, could someone else tell when it should restart? - Is what you are still doing making the thing better, or making you feel better? Return: - Verdict: stopped, or still going - The corrected three lines - Anything you are carrying in your head that is not on the page yet ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Putting it down and keeping it running are the same skill from two ends. That is [Yours to keep running](https://vibe2value.com/build-ownership/) plus [Better from real signal](https://vibe2value.com/build-iterate/). ## The same idea on a recipe card A kitchen closes. It does not finish. The plates are done, the pass is wiped and tomorrow's order goes up on the board. What is not done tonight is written on the board rather than remembered, which is exactly why the chef can go home. A kitchen where the outstanding jobs live in somebody's head never really closes. It just gets quiet for a while. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means Every other part of this framework has a gate. Shape ends when the decision is sharp. Build ends when there is a working thing. Launch ends when real people are looking at it. Running has no natural end at all. Nothing arrives to tell you it is over, so the work continues at whatever rate your attention allows. It is the stage that quietly takes the most hours because it is the only one with no edge on it. The gate is not whether you are finished, because you will not be. It is whether everything still open has been written down. Something written as a deferred decision with a trigger can be put down and picked up deliberately. Something carried in your head cannot be put down at all, which is why you keep opening the project to check on it. ## Make stopping point concrete Compare the version that sounds responsible with the version somebody could act on. - **Too vague:** It is basically done, I just want to tidy a few things up. - **Concrete enough to act on:** Each week it asks me to read the failures nobody reported. A second skill is paused until somebody asks for it. Writing the post, scheduling and analytics are out of scope on purpose. The second version has an end in it. The first has no way of ever being finished, which is why it never is. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). What is still openWrittendown?yesnoYou can stopand pick it up laterIt never closesso you keep opening it Stopping is not deciding you are finished. It is getting everything still open onto the page, either as out of scope on purpose or as a deferred decision with the condition that unpauses it. What is written down can be put down. What is in your head is why you keep opening the project. ## Check stopping point - **Pass:** Everything you are not doing is written down, either as out of scope on purpose or as a deferred decision with a named condition that unpauses it. Nothing is being carried in your head. - **Fail:** What is left lives in your head, or the answer is "I will know when I am done". Stopping is something you write down. It is not something you feel. ## What you'll walk away with This post is about the running decision: what has to be true once the thing is already live. You'll come out with your own `knowledge-base/product/deferred-decisions.md` written and sharpened: the real weekly cost of keeping it alive, every paused thing with the condition that restarts it, what is out of scope on purpose and why, plus a clear answer to whether you have stopped. ## Write it down Your `deferred-decisions.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/product/deferred-decisions.md` is just a suggested name and place for this information. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. ## Risk and mitigation - **Risk:** The project never ends, it only gets quieter. It keeps taking hours you never decided to give it. - **Mitigation:** Write the deferred decisions down with their triggers. What is written down can be put down. ## Key takeaway You have not stopped until what is left is on the page instead of in your head. ## How to document your stopping point Write it up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Stopping point ## Answer What it asks of you in a normal week: [the real ongoing cost] Paused, plus what unpauses each one: [the deferred decisions] Out of scope on purpose: [and why] ## Evidence What you have actually spent on it in the last month, not what you meant to. ## Decision What you are optimising for now that it runs. What you are deliberately leaving alone. ## Risk What breaks if this is wrong. ## Standing instruction What the AI should do every time it touches this. For example: if I ask for something that is not in the answer above, ask whether it is a deferred decision being unpaused or a new one, before building it. ``` ### 4.2.1 - The Failure Whose Only Symptom Is That the Answer Looks Wrong URL: https://vibe2value.com/when-the-only-symptom-is-a-wrong-answer/ Last updated: 2026-09-07T06:30:56.000Z ## Failure surfacing When this breaks, where does it show up and what does a person get to work from? ## The call Decide where each kind of failure appears and what is handed over when it does. Include the ones that never go red, because in an AI build those are most of them. ## Sharpen failure surfacing with AI This is a Run idea, so the AI move is **Run it for real**. You can sharpen the decision here, but it only proves out against a system that is actually live. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real failures and keep the instruction exactly as visible here. It helps you put your `running/failure.md` together by refining your three lines until someone who did not build the system could act on them. ``` You are checking whether this failure surfacing plan is clear enough before you move forward. Constraint: Every kind of failure must have a named place it appears and a named thing a person is handed when it does. A failure that surfaces nowhere is a gap. Saying so counts as an answer. Example of the standard: Vague: "Errors are logged and we get alerts." Sharp: "A lost capture and a missed digest both write to the log. Bad advice writes nothing at all: the sender gets a suggestion that is wrong and I hear about it only if they say so. So every capture is acknowledged by return email, which at least makes silence visible." The sharp version names where each kind lands and what you get to work from. It also names the one that lands nowhere instead of leaving it off the list. Working draft: Kinds of failure: [list them, including the ones that do not crash] Where each one appears: [log, channel, dashboard, nowhere] What a person is handed: [what they can actually work from] Task: Decide whether every kind of failure has a named place and a named handoff. If one has neither, say so plainly and mark it as a gap rather than inventing a route for it. Check: - Is there a kind of failure whose only symptom is that the answer looks wrong? - Could a person who did not build this act on what they are handed? - Have you named the failures that surface nowhere, rather than leaving them off the list? Return: - Verdict: clear, or needs work - The corrected three lines - Any failure that surfaces nowhere, named as a gap ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Deciding where a failure lands is the decision. Making it land well is the craft. That is [Fail well](https://vibe2value.com/fail-well/), [What kind of failure is it](https://vibe2value.com/what-kind-of-failure-is-it/) and [the other ways to run it for real](https://vibe2value.com/ways-to-run-it-for-real/). ## The same idea on a recipe card A burnt dish announces itself. You smell it from the next room, the smoke alarm goes and nobody has to be told. An under-seasoned dish announces nothing. It looks right, it is plated the same and the only person who finds out is the one eating it, who may not say anything. Kitchens plan for both. There is a bin for the burnt one and a tasting spoon for the other. The tasting spoon exists because some failures will never set off an alarm, so somebody has to go and check on purpose. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means Most systems fail loudly. Something throws, a status code goes red and you find out. That is the failure everyone plans for, because it is the one that makes a noise. A build with a model in it fails differently. The call succeeds, the response is well formed, the page renders and the answer is wrong. Nothing has gone red, because from the system's point of view nothing has gone wrong. The only symptom is that the answer looks wrong. It only looks wrong to somebody who already knows what right looks like. So the work here is not error handling. It is deciding, ahead of time, which kinds of failure can happen, where each one becomes visible and what a person is holding when it does. Some of them will surface nowhere. Writing that down is the answer, not a gap in the answer. ## Make failure surfacing concrete Compare the version that sounds responsible with the version somebody could act on. - **Too vague:** Errors are logged and we get alerts. - **Concrete enough to act on:** A lost capture and a missed digest both write to the log. Bad advice writes nothing at all: the sender gets a suggestion that is wrong and I hear about it only if they say so. So every capture is acknowledged by return email, which at least makes silence visible. The second version tells you what you would be holding at two in the morning. It also admits the one that has no route yet, which is the part most answers leave out. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). A wrong answerThrew?noStatus?200Is it true?nothing on this path asksIt reaches whoever askedlooking exactly like a good answerEvery gate it passes is a gate on the wrong thing. It did not throw. The status was fine. Every gate on the path went green, because every gate on the path checks something other than whether the answer is true. So it arrives looking exactly like a good one, and the only person who can tell is whoever knows the subject. ## Check failure surfacing - **Pass:** You can point at where each kind of failure appears and say what a person or an AI is handed to work from when it does. - **Fail:** Any failure whose only symptom is that the answer looks wrong. A silent failure you have named beats a loud one you have not. ## What you'll walk away with This post is about the running decision: what happens the moment something goes wrong in a system that is already live. You'll come out with your own `knowledge-base/system/running/failure.md` written and sharpened: every kind of failure named, where each one surfaces, what a person is handed and an honest list of the ones that currently surface nowhere. ## Write it down Your `failure.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/system/running/failure.md` is just a suggested name and place for this information. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. ## Risk and mitigation - **Risk:** The failures that never go red are the ones you find out about from a user, months later, after they have been happening the whole time. - **Mitigation:** Name one silent failure per model call or external call then decide now whether you are giving it a route or accepting it as a known gap. ## Key takeaway Do not move on until every kind of failure has a place it appears and something a person can work from, including the ones that never go red. ## How to document your failure surfacing Write your failure surfacing up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Failure surfacing ## Answer Kinds of failure: [list them, including the ones that do not crash] Where each one appears: [log, channel, dashboard, nowhere] What a person is handed: [what they can actually work from] ## Evidence Why you believe this. Incidents you have had, things users reported before you saw them, the ones you only found by accident. ## Decision What you are optimising for and what you are accepting. Which failures you have decided to leave silent for now. ## Risk What breaks if this is wrong. ## Standing instruction What the AI should do every time it touches this. For example: when you add a call that can fail, say where the failure will appear and what it hands back. If the answer is nowhere, say so. ``` ### 4.2.2 - Decide What Reaches You Before Everything Does URL: https://vibe2value.com/decide-what-reaches-you-before-everything-does/ Last updated: 2026-09-07T06:30:57.000Z ## Escalation What is allowed to carry on without you? What has to stop and wait? ## The call Draw the line between what runs unattended and what comes to a person, then say what that person is handed when it does. Draw it while nothing is on fire. ## Sharpen escalation with AI This is a Run idea, so the AI move is **Run it for real**. You can sharpen the decision here, but it only proves out against a system that is actually live. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real line and keep the instruction exactly as visible here. It helps you put your `escalation.md` together by refining your three lines until somebody who did not build this could act on them. ``` You are checking whether this escalation line is clear enough before you move forward. Constraint: You must be able to say which work runs unattended, what hands itself back to a person and what that person receives when it does. "Someone looks at everything" is not a line. Example of the standard: Vague: "We keep an eye on it and step in when something looks off." Sharp: "Capture, storage and the digest all run unattended. A bounce, a failed run or a sender whose log has nothing new stops and comes back to me as one email naming the sender and what stalled. Nothing else interrupts me. Everything else runs unattended and we read the weekly digest." The sharp version says what carries on, what stops and what the person is holding. The vague one relies on somebody noticing. Working draft: Runs unattended: [what carries on without anyone] Hands back to a person: [what stops, plus what triggers it] What the person receives: [what they can act on immediately] Task: Decide whether the line is real. If the answer is that a person checks everything, that is not a line, it is the absence of one. The honest move is to name what should run unattended and start there. Check: - Is the line written down anywhere, or does it live in one person's head? - When something hands back, does the person get enough to act, or do they have to reconstruct it? - Is anything running unattended that you would not have chosen? Return: - Verdict: clear, or needs work - The corrected three lines - Anything running unattended by accident rather than by decision ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Where the line sits is the decision. Working either side of it is the craft. That is [Know when to step in](https://vibe2value.com/know-when-to-step-in/), [Where a person should look](https://vibe2value.com/where-a-person-should-look/) plus [How much to let AI decide](https://vibe2value.com/how-much-to-let-ai-decide/). ## The same idea on a recipe card The pass is the line in a kitchen. Most plates go straight out. Some stop, because the chef decided in advance which ones do: anything for the big table, anything already sent back once. The rule exists before service starts. That is the whole point of it. Nobody is making that call while six plates go cold, because it was made on a quiet Tuesday by somebody who had time to think. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means AI has made running things unattended almost free. Free things spread. So the number of jobs running with nobody watching goes up quietly, one convenience at a time, until it is most of the system. The default is not no line. The default is a line that got drawn by accident, out of whatever was easiest to automate first. That is different from the line you would have chosen. You only find out which one you have when something goes through it. The other half is what arrives. Something that stops and hands back is only useful if the person receives enough to act. A notification saying a job failed, with no context, has moved the work rather than escalated it. ## Make escalation concrete Compare the version that sounds responsible with the version somebody could act on. - **Too vague:** We keep an eye on it and step in when something looks off. - **Concrete enough to act on:** Capture, storage and the digest all run unattended. A bounce, a failed run or a sender whose log has nothing new stops and comes back to me as one email naming the sender and what stalled. Nothing else interrupts me. The second version tells a person what will reach them and what they will be holding. The first relies on somebody noticing. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). Work arrivingThe linewritten down, before servicestopscarries onTo a personwith what they needRuns unattendedNo lineeverything runs, or you check everything Work meets a line you drew while nothing was on fire. What stops goes to a person with enough to act on. What does not, carries on. Without a written line you get one of the two failures instead: everything runs unattended, or you end up checking all of it. ## Check escalation - **Pass:** You can say which work runs unattended, what hands it back and what a person receives when it does. - **Fail:** The line exists only in someone’s head, or it is "a person looks at everything". A line nobody has written down is not a line. It is a habit. ## What you'll walk away with This post is about the running decision: what has to be true once the thing is already live. You'll come out with your own `knowledge-base/system/running/escalation.md` written and sharpened: what runs unattended, what stops and why, what the person is handed when it does and an honest list of anything running without you that you did not actually choose. ## Write it down Your `escalation.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/system/running/escalation.md` is just a suggested name and place for this information. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. ## Risk and mitigation - **Risk:** Work runs unattended because nobody drew the line rather than because you chose it. You find out from a customer. - **Mitigation:** Name one thing that must always stop and wait, plus one thing you are happy running without you. The rest of the line follows from those two. ## Key takeaway Decide what reaches you before everything does, then say what it hands you when it arrives. ## How to document your escalation Write it up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Escalation ## Answer Runs unattended: [what carries on without anyone] Hands back to a person: [what stops, plus what triggers it] What the person receives: [what they can act on immediately] ## Evidence What has reached you in the last month and what you wish had. ## Decision What you are optimising for and what you are accepting runs without you. ## Risk What breaks if this is wrong. ## Standing instruction What the AI should do every time it touches this. For example: when you add a job that can run without a person, say which side of the line it sits on and what it hands back if it stops. ``` ### 4.1.1 - You Haven't Finished a Deploy Until You've Practised Undoing It URL: https://vibe2value.com/you-havent-finished-a-deploy-until-youve-undone-it/ Last updated: 2026-09-07T06:30:53.000Z ## Deploy and rollback When this goes wrong at five to five, how do you get back to the version that worked? ## The call Write down what triggers a deploy to each environment, what runs during it, how you confirm it landed and the exact steps back. Undoing is the half people find out they never built. ## Sharpen deploy and rollback with AI This is a Run idea, so the AI move is **Run it for real**. You can sharpen the decision here, but it only proves out against a system that is actually live. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real deploy and keep the instruction exactly as visible here. It helps you put your `deploy.md` together by refining your three lines until somebody who did not build this could act on them. ``` You are checking whether this deploy and rollback plan is clear enough before you move forward. Constraint: Someone who has never deployed this project must be able to deploy it, confirm it landed and get back to the previous version using only what is written down. Example of the standard: Vague: "It deploys automatically when we merge and we can roll back if we need to." Sharp: "A change to the skill or the digest job triggers the deploy. You know it worked by sending a test capture and getting the digest back, rather than by trusting a green tick. To get back, republish the previous version, which takes about five minutes and has been practised once before anyone else had it. That has to be handled separately." The sharp version can be followed by a stranger under pressure. The vague one cannot. Working draft: What triggers a deploy to each environment: [merge, tag, manual run, schedule] How you know it worked: [the check you make against the running thing] The route back: [exact steps and roughly how long] Task: Decide whether a person who has never done this could deploy, confirm and roll back from these three lines alone. If not, rewrite them to meet the standard above. If the route back does not exist yet, say so plainly rather than describing one nobody has ever run. Check: - Does "how you know it worked" check the running thing, or does it trust the report of whatever ran the deploy? - Have you actually performed the rollback, or only assumed it? - Do data changes ride along with the code? Does undoing one undo the other? Return: - Verdict: clear, or needs work - The corrected three lines - Anything that has never actually been tested, named as such ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Deciding the route back is the decision. Knowing where the thing actually runs is the craft. That is [Where the code runs](https://vibe2value.com/where-the-code-runs/) plus [Guaranteeing the steps that matter](https://vibe2value.com/guaranteeing-the-steps-that-matter/). ## The same idea on a recipe card A cook who has never taken a plate back off the pass does not really know how. The wrong plate is not the problem. The problem is the twenty minutes of standing there working out what to do about it, because nobody had thought it through while things were calm. Kitchens that run well have a stock answer ready before service. Remake it. The spare is here. The answer exists before it is needed, which is the only time it is cheap to work out. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A deploy has two halves. Everyone builds the outward half, because nothing works until they do. Almost nobody builds the return half, because everything works without it right up until the moment it does not. There is a second trap in how you know it worked. A runner can report success for a step that did nothing. If your confirmation is a green tick rather than something you checked against the running system, you have confirmed the report rather than the deploy. And data usually comes apart from code. A rollback of the code is not a rollback of a migration. Finding that out during an incident is the expensive way to learn it. ## Make deploy and rollback concrete Compare the version that sounds responsible with the version somebody could act on. - **Too vague:** It deploys automatically when we merge and we can roll back if we need to. - **Concrete enough to act on:** A change to the skill or the digest job triggers the deploy. You know it worked by sending a test capture and getting the digest back, rather than by trusting a green tick. To get back, republish the previous version, which takes about five minutes and has been practised once before anyone else had it. The second version can be followed by somebody who has never done it, at the worst possible time, which is when it will actually be read. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). Something is wrongon live, right nowIs the routeback written?yesnoTwo minutesyou have done itAn hourworking it out nowdecided months ago, while nothing was wrong A route back you have written and taken once costs two minutes. One you have only assumed costs an hour, and you pay it while the thing is broken and somebody is waiting. The difference between those two was settled months earlier, on a quiet afternoon when nothing was wrong. ## Check deploy and rollback - **Pass:** Someone who has not done it before can deploy to each environment from this file, confirm it landed and get back to the previous version. - **Fail:** The route back is not written down, or "how you know it worked" is that nobody complained. The route back is not real until somebody has taken it. ## What you'll walk away with This post is about the running decision: what has to be true once the thing is already live. You'll come out with your own `knowledge-base/system/environments/deploy.md` written and sharpened: every environment named, what triggers a deploy to each, the check that confirms it landed against the running thing and the exact route back with a rough time on it. ## Write it down Your `deploy.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/system/environments/deploy.md` is just a suggested name and place for this information. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. ## Risk and mitigation - **Risk:** Something goes out that should not have, at the worst time. The first person to look has to work the way back out from scratch. - **Mitigation:** Write the route back before you need it, then take it once on purpose while nothing is wrong. ## Key takeaway Do not call a deploy finished until someone who has not done it before could take it back. ## How to document your deploy and rollback Write it up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Deploy ## Answer What triggers a deploy to each environment: [merge, tag, manual run, schedule] How you know it worked: [the check you make against the running thing] The route back: [exact steps and roughly how long] ## Evidence When you last rolled back, how long it took and what surprised you. ## Decision What you are optimising for. What you are accepting, for example forward-only migrations. ## Risk What breaks if this is wrong. ## Standing instruction What the AI should do every time it touches this. For example: if a change alters the deploy or the data shape, say what it does to the route back before writing the code. ``` ### 4.1.2 - If the Secret Only Exists on Your Machine, You Are the Single Point of Failure URL: https://vibe2value.com/if-the-secret-only-exists-on-your-machine/ Last updated: 2026-09-07T06:30:54.000Z ## Secrets If you lost your laptop tonight, could anyone else bring this up tomorrow? ## The call List every name the code reads and say where the value for each one lives in each environment. Never the value itself. ## Sharpen secrets with AI This is a Run idea, so the AI move is **Run it for real**. You can sharpen the decision here, but it only proves out against a system that is actually live. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real keys and keep the instruction exactly as visible here. It helps you put your `secrets.md` together by refining your three lines until somebody who did not build this could act on them. ``` You are checking whether this secrets plan is clear enough before you move forward. Constraint: A new person must be able to get the project running from what is written, without anyone handing them a value privately. Every name the code reads appears in the list. No real value appears anywhere in it. Example of the standard: Vague: "Secrets are in the environment and in the deploy settings." Sharp: "The code reads three names: the mail key, the store key and the model key. Locally they come from .env, which is gitignored and mirrored by .env.example with empty values. On develop and main they are set in the platform's own secret store and two people can read them. Rotating one means changing it there and redeploying, because nothing picks it up at runtime." The sharp version names every key and where its value lives per environment. The vague one names neither. Working draft: Names the code reads: [every one] Where the value lives per environment: [local, plus each deployed environment] How a new person gets set up: [the actual steps] Task: Decide whether a new person could get running from these three lines without being handed a value privately. Check that every name the code actually reads appears. If a real value has been written down anywhere, say so, because that is the thing to fix first. Check: - Does the code read a name that is not on the list? - Is there a real value written into any file that is tracked? - Can you say who is able to read each value? Can you say how one gets rotated? Return: - Verdict: clear, or needs work - The corrected three lines - Any name the code reads that is missing. Any real value that should not be there ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Where the values live follows from where the thing runs, which is [Where the code runs](https://vibe2value.com/where-the-code-runs/). The wider set is [ways to run it for real](https://vibe2value.com/ways-to-run-it-for-real/). ## The same idea on a recipe card Every kitchen has the supplier list on the wall. It says what to order and who from. It never says the card number. When the head chef is away the kitchen still opens, because the part everybody needs is written down and the part nobody should have is not. Those are two different decisions and most people only make one of them. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means Two failure modes pull in opposite directions here, which is why this one is easy to get wrong in both directions at once. Write a value down and you have leaked it, permanently, into a history that is hard to clean. Write nothing down and the project can only be run by whoever already has the values, which is usually one person, usually you. The way out is that the two halves separate. The names the code reads are documentation and belong in the file. The values are secrets and belong in the platform. A file that names every key and where its value lives is safe to read and enough to work from. ## Make secrets concrete Compare the version that sounds responsible with the version somebody could act on. - **Too vague:** Secrets are in the environment and in the deploy settings. - **Concrete enough to act on:** The code reads three names: the mail key, the store key and the model key. Each one lives in the platform's own secret store, set per environment and never on my machine. A new person registers, confirms the address they will send from and sends one line. The second version is something a new person can act on. There is still no secret in it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). What goes in the file?the secrets one, in the repoNames and valuesthe values are now in the history foreverNames, and where each value livesanyone can run it, nothing has leakedNothing at allonly the person holding the values can run it There are three answers and only the middle one works. Put the values in and they are in the history forever. Put nothing in and only the person holding them can run it. Put the names in, with where each value lives, and a new person gets running without anything leaking. ## Check secrets - **Pass:** A new person can get the project running from this file without being handed a value privately. Every name the code reads appears here. - **Fail:** A real value has been written into this file, or the code reads a name that nobody has listed. A secret only you can reach is not security. It is a bus factor of one. ## What you'll walk away with This post is about the running decision: what has to be true once the thing is already live. You'll come out with your own `knowledge-base/system/environments/secrets.md` written and sharpened: every name the code reads, where the value for each lives per environment, who can read it, how it gets rotated and the steps a new person follows to get running. ## Write it down Your `secrets.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/system/environments/secrets.md` is just a suggested name and place for this information. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. ## Risk and mitigation - **Risk:** You are unavailable and nobody can bring the project up, or a real value reaches the repository and has to be rotated in a hurry. - **Mitigation:** Keep the names and locations in the file and the values in the platform. Add an example file with empty values so nothing has to be guessed. ## Key takeaway Write down every name the code reads and where its value lives. Never the value. ## How to document your secrets Write it up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Secrets ## Answer Names the code reads: [every one] Where the value lives per environment: [local, plus each deployed environment] How a new person gets set up: [the actual steps] ## Evidence What the code actually reads, checked against the code rather than remembered. ## Decision Who can read each value and how one gets rotated. ## Risk What breaks if this is wrong. ## Standing instruction What the AI should do every time it touches this. For example: if you add code that reads a new name, add it to this list in the same change. Never write a real value into any tracked file. ``` ### Where is the low hanging fruit with AI? URL: https://vibe2value.com/start-with-the-boring-work/ Last updated: 2026-08-20T00:38:35.000Z Start with the boring work. People ask me where to start with agents. They want a list. The honest answer is that it depends on what your business does and what you are trying to get out of it, which is a useless thing to say to someone who just wants to begin. So here is the part that does not depend on any of that. ## The work that is done the same way every time A team that runs the same kind of job over and over. Work that moves along a line, where the next step is always the next step. Not the clever work. Not the work you are proud of. ## It is low hanging for a boring reason When the work is the same shape every time you can tell whether the thing did it right. You have something to compare it to. Most of these projects do not fall over because the model was not good enough. They fall over because nobody could say whether the output was any good. That is the part people skip. The repeatable work is not easier for the machine. It is easier for you, because you already know what a good one looks like. ## Then your business model decides how far you take it If that repeatable work is what you sell, an agent changes what you can charge. If it is overhead, it just buys back hours. Same work, two different answers. That is why nobody can hand you the list. From the outside the job looks identical and the reason for doing it is not. ## Two questions before you build anything Does the rule have to hold every time, or is the odd miss survivable. And can the rule actually be written down. Must hold, and can be written down, is code rather than an agent. Certain, instant and free to run. Matters, but cannot be written down, is a person. What is left in the middle is where an agent earns its keep. The long version is [when to use AI and when not to](https://vibe2value.com/when-to-use-ai-and-when-not-to/), and the two questions are [here](https://vibe2value.com/which-to-reach-for/). ## The shape comes out of that, you do not pick it One call, a workflow, an agent. You do not choose one off a menu. You go through the forks in the job and decide which ones you are writing down, and what is left over is what the system decides for itself. [How much to let AI decide](https://vibe2value.com/how-much-to-let-ai-decide/). Repeatable work has fewer forks worth handing over. That is one more reason it is the safe place to begin. --- ## So Where is the repeatable work in your business? ### An AI agent charges you per answer and never says whether the answer was any good URL: https://vibe2value.com/charges-per-answer-never-says-if-it-was-good/ Last updated: 2026-08-20T00:30:47.000Z On one of the projects I work on we capture telemetry on every agent request. It records the cost. It also records which prompt template was used, which model answered and how long it took. That is more than a bill gives you. A bill tells you what the month came to. This tells you which design decision caused it. We did not put it in at the start. It went in once we know the thing is going to scale and somebody is going to ask what it costs and whether it earned its keep. Before that there is nothing worth counting. Even then it only measures the half that reports itself. Cost arrives on its own. Latency arrives on its own. Whether the answer was any good does not arrive in the telemetry report at all. That half has to be built and the way we do it is not clever. The prompt templates carry the real policy constraints, the ones the business actually has, and we test against those properly. The test asks whether the output respected the constraint. There is no rubric to invent, because the policy was already written down by somebody whose job it was. The useful part is that both land on the same unit. Cost per template from the telemetry. Quality per template from the policy tests. Same template, so you can read them next to each other. That matters because the two move independently. Cost can go down while quality goes down with it and nothing red will appear anywhere. There is a shape+build+launch idea that comes at this from the other end: [the one metric that proves this works for real users](https://vibe2value.com/the-one-metric-that-proves-this-works/). Telemetry will hand you every metric except that one. Two longer write ups if this is where you are. [The cost is measured, the quality is not](https://vibe2value.com/the-cost-is-measured-the-quality-is-not/) covers why quality has no meter and a couple of ways to build one. [A prompt template is a unit of measurement](https://vibe2value.com/a-prompt-template-is-a-unit-of-measurement/) covers what goes into a template and why the name on it is what makes any of this possible. --- What are you using to tell whether your output is any good? ### The cheapest way to build an AI agent is the most expensive way to run one URL: https://vibe2value.com/cheapest-to-build-most-expensive-to-run/ Last updated: 2026-08-17T08:01:26.000Z This has come up in a few conversations now, from different directions, which is usually the sign that something is worth sharing. Once an agent is in front of a system, people agree quickly that the rules have to be written down. The screens used to hold them and the screens are gone. What gets skipped is where the rule actually gets applied. There are always other options, but three of them come up again and again. This is easier with an example, so take a meal planner. **In the form.** You tick vegetarian, drag a slider to twenty minutes, pick a budget. Your ticks become a query and the database answers it. Instant and free. You can only ask what the screen offered you. **Once, when it is set up.** You type "something quick for a weeknight" and the nearest recipes come back. AI read every recipe weeks ago and turned each one into numbers, so the matching itself is just arithmetic. Getting that set up is real work, once. Running it costs almost nothing and takes no time. **At the moment of the call.** You describe your week in a paragraph. A model reads it, reads the recipes and decides. It copes with "my mother in law is coming and she hates fish", which neither of the others can. It also does all of that again for the next person. None of them is free. The form is instant and rigid. Setting it up once is the most work to build and the least to live with. Deciding at the call is barely any work up front, then charges you on every request, forever. The interesting one is the form. It is the cheapest of the three to run. Nobody left forms behind because they were expensive. They left because forms were rigid, which is a different problem with a different answer. It is easy to see why the last one won by default. You write the rule in a sentence, with nothing to build. What it does not feel like is a subscription, which is what it is. Every request from then on pays the same toll, whether the question was genuinely hard or completely routine. That last word is the opening, because the middle option is the hybrid. Setting it up once does not remove the judgement. It just happens before anybody asks. What comes out of it is data rather than an answer, so every request after that is a lookup. Which is what makes it worth real effort for anything common. You pay for the thinking once, then serve it for nothing. For the handful of shapes asked again and again it is the difference between a one-off cost and a toll you never stop paying. Put a number on it. Say the rule gets applied a thousand times. **In the form.** Nothing. It is a database query you already paid for. **Once, when it is set up.** Less than a cent. A thousand vector searches comes to about eight tenths of one cent. Most plans include tens of thousands of free ones a month, so at that volume it never reaches a bill. **At the moment of the call.** Perhaps about a dollar, on a small fast model with the rule itself cached. Several times that if you reach for a bigger one, though a bigger one is an odd choice for a routine check. Whichever number you land on, it stays somewhere between a hundred and a thousand times the lookup. That gap is structural. A shorter prompt does not close it. --- So here is the question, which is the one you would ask about any subscription. You are choosing what this costs to run, every thousand times, for as long as it runs. Free, under a cent, or a dollar? None of which is an argument for never asking a model. Some requests genuinely need judgement. That is what the money is buying. It is an argument for knowing which ones do. The three of them, with what each one costs: [three places a rule can live](https://vibe2value.com/three-places-a-rule-can-live/). If you have put an agent in front of something that matters, I would be interested to know where you ended up putting the rules. Prices as at August 2026, correct at the time of writing. Cloudflare bills Vectorize at $0.01 per million queried vector dimensions, so a thousand searches over a 768-dimension index is 768,000 dimensions, or about eight tenths of a cent. A paid Workers plan includes the first 50 million dimensions each month. The model figures assume a small judgement of roughly 800 tokens in and 80 out at Anthropic list rates, with three quarters of the input cached because the rule barely changes. That comes to about 66 cents per thousand calls on Haiku 4.5 and roughly $2 on Sonnet 5\. Without caching, closer to $1.20 and $3.60\. Your own numbers will move with prompt size and model. Current prices: [Cloudflare Vectorize pricing](https://developers.cloudflare.com/vectorize/platform/pricing/?ref=vibe2value.com) and [Anthropic pricing](https://claude.com/pricing?ref=vibe2value.com). ### Interesting to me. Not to you. URL: https://vibe2value.com/interesting-to-me-not-to-you/ Last updated: 2026-08-14T02:13:49.000Z Shape it before you build it. Work out what you are making and who it is for. Then make it. That is the first step in shape+build+launch. What the last fortnight taught me is that it is not one step. It is the thing you keep iterating on right up until you press the button. I have started a lot of posts over the last couple of weeks. Most of them are still sitting there unfinished. The same thing stopped me every time. I would get halfway down and think, is this actually any use to the people I am writing it for. Often the answer was not yet. It was interesting to me. That is not the same thing. So not much has gone out. A few bigger ideas are in the same state, not just posts. Nothing scrapped. They just need more work before they are worth anyone’s time. The useful bit was not any of the posts. It was realising that asking whether something is of value to my audience is really a question about who they are. I could not answer the first one until I had answered the second. What stops you pressing the button? Gut feel, a friend, a chat AI, market research. I am interested in the moment you stop and go, yep that was interesting to me but not to my audience. Not yet anyway. ### Your next vibeCode starts where the last one finished URL: https://vibe2value.com/next-vibecode-starts-where-the-last-finished/ Last updated: 2026-08-28T12:07:10.000Z *But first, a disclaimer. Claude helped me write this. The thoughts are mine. Putting them in order is the part I handed over and it still took me a couple of hours. Two hours only because the base was already there.* Your first vibeCode is rough. Mine are. Everyone’s are. But the next one does not have to start where that one did. That is the whole argument. It is also the part missing from every post telling you vibeCoding is bad. There are a lot of those about, so this is a real question for the people writing them. First, the thing you were going to say. You are right. Do not put vibeCode in production without safeguards. Review it. Test it. Look at the data it touches. Have someone own it when it breaks. I am not arguing with any of that. Now my question. > Have you built something from scratch with AI assisted coding? Or are you describing something you watched someone else do badly? I ask because the answer usually explains the post. That is not a dig. It is just how I read things now. Whatever you are reading, work out where the writer is standing. The bias is the part that never gets said out loud. So when someone tells you vibeCoding is bad, the useful question is what it would cost them if it were good. Same goes for me. I make a living helping people build with AI. That is a bias and you should hold it while you read this. I would rather you did. So here is where I stand. > A vibeCoded artifact is possibly one of the most important things you can make. ## It proves something A slide describes what the thing might do. So does a document. A [vibeCode](https://vibe2value.com/vibecode/) is the thing. Running. In front of someone who can tell you if it is any good. So you stop arguing about the idea. You go and find out. Most of what I learn about an idea, I learn in the twenty minutes after someone else touches it. ## The code is reusable This is the part people miss. The vibeCode is not throwaway. It is a working source. It maps to the proper version. Whoever builds that is not starting from a blank page. They are starting from something that runs, with the hard question already answered. Rewriting something that works is a known job. Working out what to make is not. The vibeCode does the hard one. ## The first vibeCode is rough You are right about that too. Mine are rough. Nobody should be defending the first output. But that is the worst it will ever be. And that is where most of these posts stop looking. What matters is what you rebase onto. Start from a blank page every time and nothing improves. Rough on Monday, rough on Friday. Start from a base that is better than last time and the vibeCode gets better on its own. Same prompt. Better base. Better result. The base is three things. The scaffolding you no longer write by hand. The frameworks and conventions you settled on, so there is one obvious way to do something instead of five. And the knowledge base you keep adding to, where you write down what you want, how you want it and what went wrong last time. That last one compounds. Every correction is either a note you write once, or a correction you make again next week. This is devops thinking, pointed at prototypes. Nobody accepts a build pipeline that starts from nothing every time. Same rule here. Most people have not noticed yet. ![Why the second vibeCode is better than the first. A loop of four steps: vibeCode it, prove it, encode it into the base, rebase onto it. Each pass round, the base is better than it was last time. Five badges underneath: quality goes up, effort goes down, devops and version control, frameworks and conventions, a platform that scales. Credited in the footer with the vibe2value mark, vibe2value.com and the line build with AI and trust what you make. The prompt does not improve. The base does. Encode what you learn into your version control, into your conventions and into the platform underneath. Then the next pass starts from there.](https://vibe2value.com/content/images/2026/08/vibecode-rebase-loop-v6.png) This post is a carbon copy of that process. The first draft was rough. It went round again and again with the AI (in this case Claude). Each pass started from notes and conventions I already had rather than from nothing. That is why it took hours instead of days. For me that is the win. Same loop. Different artifact. ## Pick your base So where does the base come from. Two answers. You build it. Your scaffolding, your conventions, your notes, built up over the work you have already done. This is the one that compounds, because it fits how you work. Or you take someone else’s. A framework, a starter, a template, conventions that plenty of people have already argued about. Both are fine. Doing neither is the mistake. Choosing a base deserves more thought than the prompt does. The prompt is a one-off. The base is every prompt after it. ## You are in a team now On your own you could get away with a folder. You are not on your own any more. The moment you build with AI you are working in a team. Your new teammate is fast and never tires. It also turns up with none of the context that is in your head. And it forgets most of what happened yesterday. You would not hand a new person a folder of files and expect good work back. You would tell them how things are done here. The AI needs exactly that. The only way to hand it over is to write it down. Which is another word for process. So you need version control. You need the habits that come with it too. The code part is obvious. The bigger part is that those habits hold your ways of working in a form somebody else can read, including the one that does not remember yesterday. Branches, so two of you can work without standing on each other. That matters more with AI, not less. A lot more gets written per hour. Releases, so you can point at one and say that one worked. Which also gives you something to go back to. Issues, so the queue is visible and the argument about what to build next happens next to the thing itself. Docs, in the repo, beside the code. That is not admin. That is the context getting out of your head and into the one place your team and your AI both already look. All of it is ways of working, written down. GitHub fits that naturally, which is why I use it, but the practice is the point rather than the tool. Same move as before, one level up. You encode what you learn so the next attempt is better. The only difference now is that the next attempt is not only yours. ## The stack The other half of a good base is what you build on. Build on a platform that scales. Almost none of it needs building. Compute near your users. A database. Object storage. A queue. Static hosting. A way to lock it down. Deployed in seconds, from the repo. It is all sitting there. Most of it costs nothing until you are properly using it. So do not reinvent any of it. Every hour spent standing up infrastructure is an hour not spent on the thing only you can make. And whatever you build yourself, you own forever. Pick a platform that hides the complexity and scales the moment it needs to. Deploying should not be a project. You should not be sizing servers for traffic you do not have. You should be able to afford five of everything. That last one is why this belongs here. An expensive stack makes people precious. Nobody spins up a throwaway when every environment costs real money. So the prototype quietly becomes production, because it was the one that got provisioned. A cheap base means you can bin one. Which is what you should be doing. ## So what In most cases, **do not deploy the vibeCode**. Learn from it. Use it to move fast. And improve the base. That is the only thing that makes the next one better. If you want to do this on purpose rather than by accident, that is what [shape, build, launch](https://vibe2value.com/framework/) is for. Decide what to make. Build it. Put it in front of someone. The prototype’s job in that is to be [the thinnest thing that proves it](https://vibe2value.com/build-thin-prototype/). ## The words A few of these get used loosely, so here is what I mean by them. | Word | What I mean by it | | -------------------------- | --------------------------------------------------------------------------------------------------------------------- | | Branch | A copy of the code you work on without disturbing anyone else. | | devops | Treating how you build and deploy as something you keep improving, rather than something you redo by hand every time. | | Frameworks and conventions | The agreed way to do a thing, so there is one obvious way instead of five. | | Issue | One piece of work, written down where everyone can see it. | | Knowledge base | What you have written down for the AI to read. What you want, how you want it, what went wrong last time. | | Rebase | Starting the next attempt from your improved base rather than from a blank page. | | Release | A version you can point at and go back to. | | Scaffolding | The setup you no longer write by hand. Project structure, config, the boring parts. | | The base | Everything that is already there before you prompt. Scaffolding, conventions, notes. | | vibeCode | Describing what you want in plain words and letting the AI build it, without planning it out first. Quick and loose. | ## Sharing is how we learn That is what I have learned so far. Sharing it is how I learn the rest. What is in your base? What have you written down that your AI reads? One line is enough. Mine got built out of my own mistakes and I would rather see what other people keep. I will go first. Claude Code, because it reads the repo and the notes I have already written. Git and GitHub, so I can try something rough without risking the thing that works. And a plain notes file the AI reads before it starts. That last one is the smallest and it changed the most. Not a recommendation. Just what settled. Then tell me where I am wrong. The rebasing, the base, the version control argument. And if you have built something from scratch with AI assisted coding and still think the artifact is worthless, I want to know why. If you have not built one, build one this weekend. One I keep turning over. AI assisted coding has changed a lot in a year. Can you still see it the way you did? It is going to change a lot more. Can you see that view holding? If you would rather talk than type, tell me what you are trying to make. [matt@vibe2value.com](mailto:matt@vibe2value.com) ### I wrote down everything I know about building with AI URL: https://vibe2value.com/everything-i-know-about-building-with-ai/ Last updated: 2026-08-21T04:14:34.000Z Adam Ridgway posted his [one-year milestone for Forgeworks Labs](https://www.linkedin.com/posts/ridgwayadam%5Fone-year-ago-today-i-founded-forgeworks-share-7487348987533078528-jA1p/?ref=vibe2value.com) this week and thanked me in it. I had not asked. What I wrote back is what I keep coming round to: > The year taught me that the interesting part is rarely the AI itself, it is working out the ways of working with it. I have spent the last stretch studying for the [Claude Architect Foundations Certification](https://anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification?ref=vibe2value.com). The study turned out to be the occasion rather than the point. What it actually did was make me go back over how I think about this work now, and more usefully, how that has changed the way I do it. So I did it the slow way. Rather than reading notes and hoping they stuck, I worked through every point one at a time and wrote each one out in my own words. If I could not say it plainly, I did not know it yet. That took a while and it caught a lot of things I thought I understood. ## The review is finished, and it is all public It is at [vibe2value.com/for-developers](https://vibe2value.com/for-developers/), organised by what you are actually doing rather than by any syllabus. The agent loop, and why the loop is your code and not the model’s. Why more tools make an agent worse rather than better. What a gate should actually check, which is what happened rather than what the model says happened. Why a search that comes back short is more dangerous than one that fails outright. None of it is theory I collected. It is the year with Adam, and the work before that, written down in a form I can hand to someone. The part that surprised me is how much of it turned out to be about ways of working rather than about the technology. What you set up before you start. How you cut the job up. What you check before you believe it. What you write down so tomorrow is not a fresh start. None of that comes out of the compiler, and none of it is a knack you either have or you do not. They are practices, which means you can pick them up this week. ## What is next There are six worked scenarios to go through, taking all of this off the page and into something running. That is the real test, because knowing a thing and using it under pressure are different skills. More about that soon. Adam is into year two now and I am looking forward to seeing where it goes. The tools keep moving and the ways of working with them keep moving too, so what I have written down is where I have got to rather than a settled answer. I have been doing this a long time and I am still learning, which is rather the point. If any of it is useful to you, take it. If you would rather talk than read, email me at matt@vibe2value.com and say what you are stuck on. ### A Wednesday check-in to make your vibe have more value URL: https://vibe2value.com/ten-minutes-on-a-wednesday/ Last updated: 2026-07-24T02:12:07.000Z vibeCoding or AI-assisted coding gets you something that works, fast. Whether it was worth building at all is a different question, and the AI will never raise it. Ask it for a booking system, a CRM or a blog site and you get one. It will not stop to tell you that the platform you already pay for does this or that three good ones already exist and two are free, or are open source options that you can build on. So here is the check worth doing first. Is this the best return on the effort? Build the part that is yours and acquire the rest, which is [2.2.2 - Buy vs Build Is a Strategy Choice, Not an Engineering One](https://vibe2value.com/buy-vs-build-is-a-strategy-choice/). And remember cost is not one number: money, time, accuracy and what it costs you to change your mind later all move separately, which is [laid out here](https://vibe2value.com/what-each-one-costs/). The check is hard to run on your own, because it needs you to know what already exists. That is exposure, not intelligence. So bring it to a Wednesday. Say what you are about to build and we will work out whether you need to build it at all, or only one small piece of it. Ten minutes of that can save you the whole build. [Wednesdays at 5:30pm](https://vibe2value.com/wednesday/), one hour, online. Like catching up for a coffee. Prefer to run the check yourself? The framework is a [Claude Code plugin](https://github.com/vibe2value/claude-plugins/tree/main/plugins/shape-build-launch?ref=vibe2value.com). ### The AI answered like an engineer. That was the problem. URL: https://vibe2value.com/the-ai-answered-like-an-engineer/ Last updated: 2026-07-22T12:50:06.000Z Recently I was talking with someone who had used [guide me](https://vibe2value.com/guide-me/) to get started. They had done the hard part well. They had named their user and they knew what they were trying to make. Then they asked the obvious next question. How do I actually build this? They put it to the AI and the AI did what AI does. Did they want Python or Node? How did they want to handle sockets? What about REST and APIs? All fair questions if you are an engineer. They are not an engineer. Within a few minutes a good idea had turned into a wall of jargon and they felt stuck. None of that was the next question. When you ask an AI how to build something, it answers like an engineer, because that is the shape of the question. But "how do I build it" quietly skips the question that comes first. Does this need building at all? And that is the buy versus build idea in the framework. Buy versus build is a strategy choice, not an engineering one. Think about it this way. If what you need is a place to publish your writing, you do not build a blogging application. There are already brilliant blogging platforms and most are cheap or free. Building your own would be like milling your own flour to bake a pie. The flour is not where the pie gets good. The filling is. Your effort belongs in the content and the strategy, not in rebuilding something that already exists and works. So we did not talk about Python or Node. We talked about what they actually understood. Their users. Their content. The one thing that would make what they make theirs. Everything else, the parts they did not understand and did not enjoy, is a candidate to buy or reuse. Then came the real test. Could they put their name on it? Would you stand behind this build in front of real users and mean it? This is where trust comes in and trust turned out to be simple. You can only trust the part you know you can do well. If you build the thing you do not understand, you cannot stand behind it, because you cannot tell whether it is right. Build the one part that is truly yours and you can put your name on it. Buy the rest and trust the people who already do it well. We did not set out to, but that conversation walked the three corners of the framework which were: 1. [If You Can't Name the User, You're Guessing What They Want](https://vibe2value.com/if-you-cant-name-the-user-youre-guessing/) 2. [Buy vs Build Is a Strategy Choice, Not an Engineering One](https://vibe2value.com/buy-vs-build-is-a-strategy-choice/) 3. [Are You Comfortable Putting Your Name on This Build?](https://vibe2value.com/are-you-comfortable-putting-your-name-on-this/) The confusion at the start was never a sign they were not technical enough. It was a sign they were answering the wrong question. Move the question from which technology to where the value lives and what you can stand behind. Then it gets simple again. That is the whole point of building with AI. Not to build everything, but to build the part that is yours and trust what you make. --- Thoughts? ### The guide has moved URL: https://vibe2value.com/build-with-ai-guide/ Last updated: 2026-08-09T20:58:35.000Z **The guide has moved.** It is now free and ungated, with no signup. [The guide →](https://vibe2value.com/guide/) ### AI can build anything. So why are you still stuck? URL: https://vibe2value.com/ai-can-code-decide-remember/ Last updated: 2026-08-27T23:55:49.000Z When you build with AI, the code is the easy part now. The hard parts are the two things nobody warns you about. And they go hand in hand. **The first: knowing where to start.** You have the idea. "A website to help busy families cook cheap healthy dinners." Then you just sit there. That is what [Guide me](https://vibe2value.com/guide-me/) is for. Type what you're building in plain words, as messy as you like. It hands you a prompt to paste into ChatGPT or Claude. Instead of lecturing you or dumping a feature list, it walks you through one decision at a time, starting with who it's really for. That first question is where shaping starts. **The second: the AI forgets.** Every new chat starts cold. It forgets everything the moment you close the tab. You could hand all of that to a tool that remembers it for you. But the moment a tool holds your context, it starts thinking for you and the judgment quietly leaves your hands. So keep your own. A text file, a Google doc, a repo, whatever you own. Structure it with a short summary then the detail, so any AI can pick it up. And every decision you sharpen with Guide me is that context, writing itself one decision at a time. That is why they go hand in hand. Get started, [keep what you decide](https://vibe2value.com/your-context/), then feed it back into [Guide me](https://vibe2value.com/guide-me/). With this there is no login and nothing to buy. This is just the shape+build+launch framework made easy, so the work stays yours. There is no single right way to keep your context, it has to fit how you actually work. If you want help finding a sustainable one of your own, tell me how you work now and we will talk it through. [matt@vibe2value.com](mailto:matt@vibe2value.com) **Build with AI and trust what you make.** Start at [Guide me](https://vibe2value.com/guide-me/) and learn how to keep your own context at [Your context](https://vibe2value.com/your-context/). --- Interested in your thoughts. How do you manage context when doing AI work? ### What's your one tip for building with AI you can trust? URL: https://vibe2value.com/ai-tips/ Last updated: 2026-07-13T20:53:43.000Z Writing the code is the easy part now. Point AI at a problem and it comes back in minutes. The hard part is everything around it: knowing what to build, saying it clearly and trusting what you get back. That is where the building with AI tips help. ## Here is the deal - **Vote up the ones you love.** Hit the heart, then sort by best to watch the good stuff rise. - **Share your single best building with AI tip in the comments.** One line is perfect, the thing you would tell a friend. - **Steal shamelessly.** Come back for the list whenever you are stuck. That is the whole point. I will add a couple of mine to get us going. After that it is over to you. **So, what is your one tip?** ### Thank you and a clearer vibe2value URL: https://vibe2value.com/thank-you-and-a-clearer-vibe2value/ Last updated: 2026-07-20T07:59:23.000Z People arrived and could not tell what it was about. So the home page now says it plainly. **vibe2value is a way of thinking about building with AI.** You work through the decisions that matter, write each one down and those notes become the documentation you and your AI build from. That is what makes what you build survive change instead of breaking on the first one. What else changed: - The home page now leads with the framework: shape it, build it, launch it, then the three decisions inside each stage. - Each stage has its own page that explains it and guides you, rather than just listing ideas. - Prefer to let your AI do the reading? You can point ChatGPT or Claude at the site and ask which idea fits what you are building. It is the first thing under "how to use this site" now. - The explainer video on the first idea is easier to find, with a clear note about what free members get. One last thing. vibe2value is really just a reflection of what I am thinking while doing the work for clients every day. Sometimes I have a thought and drop it straight onto the site, forgetting that everything has to make sense in context. Your feedback was a good reminder that nothing is ever really finished. What you build has to survive its first launch and stay changeable. That is the whole thing vibe2value exists to help you with. This week, the site had to take its own advice. Thank you for being here. ### The ideas are easier to read now and the first videos URL: https://vibe2value.com/the-ideas-are-easier-to-read-now-and-the-first-videos/ Last updated: 2026-07-01T01:52:01.000Z Last time I wrote about helping people who are new to AI. A new start here page. A skill that gives you a clear order to work in. This update carries on with that. I am running a workshop this week. It is for people new to building with AI. Getting ready for it, I read back through all 27 ideas. I read them the way a beginner would. Some had grown messy over time. The thinking was right. But they were harder to read than they needed to be. ### The ideas are easier to read So I cleaned them up. Every idea from 1.1.1 to 3.3.3 now uses plainer words. The ideas have not changed. They are just easier to read. If you have read them before, they should feel clearer. If you are new, they should be easier to follow. ### The first videos I have also started making short videos. One idea at a time. They are for people who would rather watch than read. [The first one is ready now](https://vibe2value.com/if-you-cant-name-the-user-youre-guessing/). It covers idea 1.1.1, naming the user. That is the first decision in the framework. Two more come this week. One is buy versus build (2.2.2). The other is would you put your name on this (3.3.3). --- I kept the videos short and simple on purpose. [Have a watch of the first one](https://vibe2value.com/if-you-cant-name-the-user-youre-guessing/). I would like to know what you think. Tell me in the comments. ### Over my head and I don't know where to start URL: https://vibe2value.com/over-my-head-where-do-i-start/ Last updated: 2026-06-22T07:36:33.000Z Recently I heard from two people and they could not have sounded more different. The first told me, kindly and honestly, that the whole thing was over their head. New technology, a lot of unknowns, and a fair question sitting underneath it all: who is this really for and is it for me? They had decided it was not and they said so plainly. The second told me something that sounds like the opposite. They liked the content. They just did not know where to start. Sit those two next to each other and you have the whole challenge of building with AI in two sentences. One person needs the door made plainer. The other is already inside the room and needs a path across it. What is interesting is that "where do I start" is the same question both times. One asks it from the doorway. The other asks it from the middle of the floor. So I worked on both. ## For the doorway: clarity For the first, the answer was clarity. I went back over the way I introduce the site and rebuilt the [start here](https://vibe2value.com/start-here/) page for someone meeting AI for the very first time. Plain language, no assumed knowledge, a simple map of what is here and what each part is for. The person who said it was over their head came back, had a look and told me it now read as a friendly, simple introduction. That meant a lot, because they were the reason it exists. ## For the middle of the floor: a path For the second, the answer was a path. "I don't know where to start" is not really a content problem. It is a decision problem. When everything is possible, the hard part is choosing the first move, then the next one. More content does not fix that. A clear sequence does. So I built a skill. Think of it like a recipe card. A recipe card does not cook for you and it does not assume you are a chef. It just tells you what to gather and what order to do things in, so you are not standing in the kitchen staring at the ingredients. The skill walks you through the first real decisions: decide what to make, build it, then put it in front of people. Shape, build, launch. You can see how the skill works and how to use it [here](https://vibe2value.com/for-developers/). This is the whole idea behind vibe2value. The site organises the thinking. You bring the thinking. A skill is that idea made practical, a small guide that holds the structure so you can spend your attention on the actual decision in front of you. ## Using it on myself, in the open I am also using it on myself, in plain sight. On the [vibe2value project page](https://vibe2value.com/project/vibe2value/) I am building vibe2value the same way I am asking anyone else to build, writing down the shape, build and launch decisions as I make them (the messy ones included). If I am going to hand people a way of working, the least I can do is work that way out in the open. And honestly, I am excited about where this goes. The skill is the first of what I hope will be many. I have setup a [vibe2value Claude marketplace](https://github.com/vibe2value/claude-plugins?ref=vibe2value.com) for them, so as new ones take shape they have a home and you can pick up the one you need. Each one aims at the same thing: less staring at a blank screen, a clearer next move. ## Wherever you are If you are at the doorway, start [start here](https://vibe2value.com/start-here/). If you are already inside and stuck on where to begin, visit [already building](https://vibe2value.com/for-developers/). And if you are somewhere in between, that is okay too. --- If this makes sense, tell me in the comments. If you think I have it wrong, I want to hear that even more. ### Build with AI and trust what you make: the prompts and notes to get you there URL: https://vibe2value.com/a-milestone-worth-marking-sharper-prompts-new-diagrams-and-deeper-working-notes/ Last updated: 2026-08-28T12:07:10.000Z It has been a big stretch of work behind the scenes, and it feels right to stop and mark it. vibe2value just had its biggest update yet, and nearly all of it points at one thing: making the thinking sharper and the help easier to use. The site organises the thinking. You still bring it. These changes are about doing that job better. Here is what is new and where to find it. ### Every idea has a sharper prompt All 27 shape, build and launch ideas now carry a revised prompt. Each one walks from a vague starting point to a sharp one using a worked example from that idea, returns a clear verdict and tells you when your answer is already good enough to stop. They are made to copy straight into whatever AI you work with. You can find them across the [shape+build+launch ideas](https://vibe2value.com/framework/). ### And its own diagram Every idea now has its own hand-made diagram. No two are alike, and each one gives the idea a single picture you can hold in your head. They sit in the free preview, so you can see them before you join. They live on the same [shape+build+launch ideas](https://vibe2value.com/framework/). ### Deeper notes on working with AI The [Working with AI](https://vibe2value.com/working-with-ai/) notes have grown a lot. This is the judgment and craft part, the bit the tools do not hand you: how to set AI up, keep its output trustworthy and run it for real. ### And working with Claude There is now a companion set for [Working with Claude](https://vibe2value.com/working-with-claude/) and Claude Code, the practical patterns for getting good work out of it day to day. There is more to come. For now, thank you for being here while it takes shape. Have a look around. Have a question, or want to work through your own build? The first [1:1 working session](https://cal.com/vibe2value/consult?ref=vibe2value.com) is free. If any of this is useful, tell me in the comments. If you think I have it wrong, tell me that too. --- *A fresh look too. The home page, the logo and the social card all got a refresh while this was going on. Same vibe2value, a little sharper.* ### The soft skills of working with AI URL: https://vibe2value.com/the-soft-skills-of-working-with-ai/ Last updated: 2026-06-16T01:45:03.000Z Most of the writing on this site is about shipping the right thing, the judgment that kicks in after the first version works. This post is narrower. It is about the actual working relationship with the AI, the back and forth at the keyboard. Build closely with AI for a while and the lessons start to surface. You expect them to be about the tool, which command, which mode, which clever prompt. Most are not. Almost every real lesson turns out to be an old professional skill, surfaced and pointed at a new tool. Here is what that means. These are the things that move the needle when you work directly with AI, and not one of them is a feature you can look up. ### Knowing when to slow down Some work you just do. Some work you think through first, before a line of code exists. Telling the two apart is judgment, not a setting. ### Showing instead of telling A loose description gets read differently every time. A concrete example, this input gives this result, removes the room to guess. Being specific is a skill. ### Saying what good looks like up front Decide how you will know it is right before you ask for the work. That is the same discipline as writing the acceptance criteria before the build. ### Letting yourself be questioned The best move before building something is to let the AI interview you. The questions surface the things you had not thought of. You have to be willing to not have all the answers yet. ### Giving feedback that lands When a few things are wrong, the skill is knowing which to raise together and which to hand over one at a time. That is just clear communication. ### Staying the driver When the AI answers, do not just hit return. Stop, read what it did and think. If it has gone somewhere you did not expect, ask a question or reframe until it is clear. What it did might be right, but you are the one driving, so check before you move on. ### And not only the soft skills The moment you need AI to hand data back in a fixed form, an old hard skill surfaces too: data modelling. Define the shape, constrain the values, decide what is allowed to be absent. The AI fills the row, you design the table. Anyone who has built a database already has the instinct. None of that is new. It is briefing a contractor, defining a spec, asking good questions, giving clear feedback. AI does not hand you a new skill. It surfaces an old one and makes it matter more. This is why the gap is widening between people with the same access to the same tools. The features are learnable in an afternoon. The craft underneath is not. Shipping the first version is easy now. The hard part, the second version, the right version, is still human craft. ### Where this shows up If you want the hands-on version of these, the framework has a hub for every kind of AI work: [Working with AI](https://vibe2value.com/working-with-ai/). This is a working list, not a finished one, and it grows as more surface. So, a question for you: if you are building with AI, what soft skill has surfaced for you? What old habit turned out to matter more than any prompt? Leave a comment below, or reply if this reached you by email. This post is being built in the open, with you. ### I have stopped trying to help people build apps URL: https://vibe2value.com/i-have-stopped-trying-to-help-people-build-apps/ Last updated: 2026-05-11T09:39:57.000Z Earlier today I said to myself: I hate AI-assisted coding. Then I said I love it. It felt like a love-hate relationship. It’s not. The first pass gave me a plan with 20 steps. After refining, it became 3 steps. That’s where AI helps. At the extremes. Expanding the space, then collapsing it. But the value isn’t the steps. It’s how it forces you to shape what you’re asking for. To work out what you actually want. In my case, I wanted a plan. AI is great at that. It surfaces edge cases I wouldn’t have thought about. That part is useful. What’s harder is deciding what to cut. Which edge cases don’t matter. What’s actually real. Building isn’t the problem anymore. Getting something live is easy now. The problem shows up after. You need to change something and you’re not sure what it will break. With AI doing so much, it’s not always clear what changed to make it work or what the downstream effects are. That’s the shift. To be honest, when I started supporting people to use AI assisted coding for their apps, it felt like I was helping people build apps. Now it feels like helping people think about how they build them. So now it’s this: **Change your app after launch without breaking it.** Not ideas. Not options. Now it is more about a system for making safe changes. **Key takeaway:** Building isn’t the hard part anymore. Changing what you built without breaking it is. ### AI did the easy part URL: https://vibe2value.com/ai-did-the-easy-part/ Last updated: 2026-05-14T04:25:19.000Z You can build the wrong thing every day for a month and call it momentum. It is not. It is rework with a pretty commit history. Building fast with AI hides the risks you have not named. Faster is not closer. Every hour you save in code costs you ten hours later if the first time anyone hits the failure is in production. Pick one real person who would use this. Walk them through your build, step by step. Where they get stuck is your risk. Fix it before they find it. Here is what AI is good for. Writing the code. Sketching the flows. Drafting the copy. Here is what it is not good for. Telling you which step will break first for one real user. It cannot picture them, so it cannot name what breaks. Skip this and the bill comes later. In week six the risk you did not name gets found by paying customer number three. You pull apart features that took two days to glue together. Over a couple of months, that is the difference between a working business and a folder of half-built ideas. Movement is not progress. Naming the risk before launch is the cheapest fix you will ever make. --- ## Key takeaway AI did the easy part. It cannot pick the user or name the first risk. Skip that and the rework comes due in week six. ### The moment before your name goes on it URL: https://vibe2value.com/the-moment-before-your-name-goes-on-it/ Last updated: 2026-05-08T00:48:27.000Z There is a pause right before you launch. The prototype works. The demo went fine. The tests pass. The feedback is good. And still, something in you will not move your finger over the deploy button. The trigger does not matter. It could be an app build about to go out. It could be a product announcement going to your list. It could be an email campaign you have rewritten five times. The specifics change. The feeling does not. That feeling has a name. It is the moment your name goes on it. Up until now the work has been yours in private. What happens next is different. Someone is going to spend their time on this. Someone is going to build part of their day around it. Someone is going to choose this over the thing they already use, because of what you said it would do for them. That is the quiet contract. They may not have signed anything. But they have paid in attention, in trust and in the small emotional commitment of hoping this one works out. Your nervous feeling is about that contract. ## What the feeling is actually asking Not "is it perfect." Not "is it polished." One of three things, usually: 1. I am nervous about this one and I do not know if that is signal or noise. 2. I am not sure if this is ready or if I am just impatient. 3. If this breaks for someone who trusted me, what does that cost them. The first is self-trust. The second is the bar. The third is the contract. None of them are about the code. And none of them get answered by writing another test or doing another review. They get answered when you say them out loud, to someone who has not been inside the problem with you. ## Why the feeling matters on both sides Your gut says hold on, is everything okay. That is good. That is signal. If you ignore it and launch and it breaks, your user is going to feel the same thing on the other side of the screen. Except sharper. They set aside time for this and told themselves this one would be different. When it fails they are not going to debug it. They are going to decide they were right to be cautious the last four times they tried something new. The last thing you want is for them to leave. Not because they were wrong about you but because you broke the quiet contract before you even got to have the conversation. Your nervousness is the small version of theirs. Listen to yours first. ## At AI speed AI amplifies all of this. The faster you move, the less your gut has to go on. The easier it gets to mistake momentum for readiness. Just because you can launch does not mean you should. A grounded workflow is what earns you the right to be in this pause at all, instead of blowing past it. --- ## Key takeaway The pause before launch is not about polish. It is about the quiet contract with someone who decided to trust you. Listen to your nervousness. It is a small version of theirs. ### All the research, nothing to show for it - what if you could deliver this week? URL: https://vibe2value.com/all-the-research-nothing-to-show-for-it-what-if-you-could-deliver-this-week/ Last updated: 2026-05-08T00:48:26.000Z And yet you are still thinking, where do I start. Not because you lack ability. Because everything can feel like progress without actually getting you anywhere. This is not a you problem. This is a system problem. And it has a system answer. ## The work has not changed AI-assisted coding feels new. The tooling is new. But the work is the same. You still have to know what is worth building, ignore what is not and tell the difference. No AI model changes that. What has changed is the speed. Speed without judgement is how you end up with a prototype on Tuesday and a mess by Friday. Moving fast and delivering with confidence are two different things. One produces demos. The other produces systems that hold. ## The gap is not code. It is decisions. Where does this run? What happens under load? What do you do when the AI-generated auth flow has a security hole you did not notice? What does version two look like? These are the same questions every developer has always faced. AI did not remove them. It just made it easier to skip them. ## System thinking is the difference Shape the problem before you touch the keyboard. Build inside guardrails so the architecture does not rot the moment you look away. Ship based on evidence not hope. It worked before AI. It works better with AI. Shape on Monday. Build by Wednesday. Live by Friday. That is what happens when the thinking is done before the coding starts. --- ## Key takeaway The gap is not code. It is decisions. Shape on Monday. Build by Wednesday. Live by Friday. ### A different set of eyes makes all the difference URL: https://vibe2value.com/a-different-set-of-eyes-makes-all-the-difference/ Last updated: 2026-05-08T00:48:25.000Z Sometimes someone shares where they are stuck, another person offers a suggestion and everything shifts. That suggestion lands differently because it comes from someone who is not buried in the same problem. A fresh perspective cuts through the noise in a way that more time on your own simply cannot. Not because the original idea was wrong. But because another set of eyes helped them see what was already there. That's the thing about building. You stop noticing the assumptions you're standing on. Someone else walks in and sees them immediately. Staying open to that is how the work gets better. Not just the code. The thinking. The people who ship well aren't the ones who know the most. They're the ones who keep learning from the build, from each other and from what breaks. --- ## Key takeaway You stop noticing the assumptions you are standing on. A fresh set of eyes is the cheapest way to see them again. ### Multi-Sided Systems Blur Faster URL: https://vibe2value.com/multi-sided-systems-blur-faster/ Last updated: 2026-05-08T00:48:25.000Z On the surface, it looked simple. Take a sitemap. Extract content. Turn it into signals. That part made sense. But the build exposed something else. This wasn't a single-user system. It had two sides: - The developer using the tool - The visitor experiencing what the tool enables Not competing. Not conflicting. But different vantage points into the same outcome. ### The system sits between them The developer interacts with: CLI, config, processing rules. The visitor experiences: relevance, structure, meaning. They never meet, but the system connects them. ### Where it starts to blur If you only think about one side, the other becomes implicit. - Focus on the developer: **the tool becomes flexible, but the output becomes generic** - Focus on the visitor: **the output becomes clearer, but the tool becomes rigid** If neither side is explicitly named, decisions get deferred and the system works but doesn't clearly serve either side. ### What was actually missing It wasn't just: **"Who is the user?"** It was: **"Which side of the system is this decision for?"** --- ## Key takeaway When a system is multi-sided, naming the user is not enough. Name the sides and know which one you are shaping at any moment. Otherwise the system will not break, it will just blur. ### StartWithYourContext Application URL: https://vibe2value.com/startwithyourcontext/ Last updated: 2026-04-06T11:44:59.000Z ## What is StartWithYourContext StartWithYourContext is a personal AI search tool that combines Cloudflare AI Search with your saved context to shape every answer. You log in, describe your role and what you are working on and every query gets filtered through that lens. When you ask a question, StartWithYourContext uses Cloudflare AI Search to find relevant, up-to-date information from the web, then filters and frames the results based on who you are. A product lead asking “how should I validate this?” gets a different answer than a developer asking the same question, because StartWithYourContext knows the difference and searches accordingly. ## Why this exists StartWithYourContext is a learning project and a working application. It exists to show what a real product looks like when built end-to-end on Cloudflare with AI, authenticationd a database. Every part of the stack is here for a reason. The code is written to be read, followed and adapted. It is also something you can actually use. The search works, the context shapes real results and your preferences persist between sessions. This is not a demo that stops at the happy path. It is a small, complete product that does one thing well. Generic search gives generic results. AI chat without search gives stale answers. StartWithYourContext combines both: real-time web search through Cloudflare AI Search, shaped by your saved context. You set your role and priorities once, refine them over time and every query benefits from both live search results and your personal lens. This is also a working example of what a real application looks like when built on a modern Cloudflare stack with authentication, a database, AI search, and edge compute, deployed as a single project. ## How it works - **Sign in** using Clerk. Your account is yours, your preferences stay private. - **Set your context** by describing your role, what you are building and what kind of answers are most useful to you. - **Ask a question.** The Worker sends your query to Cloudflare AI Search, which searches the web and returns relevant results. Your saved context is then used to filter, rank and summarise those results into an answer that fits your situation. - **Review your history.** Past queries, search results and answers are stored so you can revisit what worked and refine your context over time. ## The stack StartWithYourContext is built entirely on Cloudflare, with Clerk handling authentication. - **Cloudflare Pages** serves the frontend as a static single-page application. - **Cloudflare Workers** handle the API layer, orchestrating authentication checks, database reads, AI Search calls and response formatting. - **Cloudflare AI Search** powers the search. Each query hits AI Search to retrieve relevant, real-time results from the web. The Worker then combines these results with the user’s saved context to produce a tailored answer. - **Clerk** manages sign-up, login and session tokens. The Worker verifies every request. - **D1** stores user preferences and query history in a lightweight SQLite database at the edge. ## What a query looks like You type a question. The Worker takes your query and calls Cloudflare AI Search, which returns relevant web results. The Worker then builds a prompt that combines the search results with your saved context and sends it to Cloudflare AI for summarisation. The response comes back grounded in real search results and tailored to your role. For example, a content creator sets their context to describe their role, the topics they cover and the audience they write for. When they ask "what should I write about next?", AI Search pulls in what already exists on the site and surfaces gaps, patterns and angles that have not been covered yet. The answer is shaped by what they actually publish, not generic content advice. ## What gets stored StartWithYourContext stores the minimum needed to be useful. - **Preferences:** your role, a short description of what you are working on and how you prefer answers to be framed. - **Query history:** your past questions, the search results returned and the AI-generated answers. No data is shared between users. No data is used to train models. Your context is yours. ## Try it StartWithYourContext is in development as part of the vibe2value project. The source code will be open and documented so you can follow the build, learn from the decisions and adapt it for your own work. If you want early access or want to follow along, join vibe2value. --- StartWithYourContext is nuilt to learn from and also built to use. Share a comment if you found this application useful. ### If AI Is Your Guardrail, You’ve Already Lost URL: https://vibe2value.com/if-ai-is-your-guardrail-youve-already-lost/ Last updated: 2026-05-08T00:48:24.000Z **AI is not the guardrail. You are.** AI chat, vibeCoding, AI-assisted coding. They don't correct direction. They amplify it. If the direction is clear: good → better → best If the direction is unclear: guess → build → regret Faster either way. That's the part that's easy to miss. AI chat helps you explore possibilities. vibeCoding helps you move through them. AI-assisted coding helps you assemble what's left. But none of them decide what should exist, what to exclude or what "done" actually means. That's still upstream, with you. AI scales your decisions. It doesn't replace them. So the real question isn't: **"can AI build this?"** It's: **"am I clear enough that it should?"** --- ## Key takeaway AI amplifies direction. It does not correct it. The guardrail is your clarity, not the model. ### Where the Thinking Is URL: https://vibe2value.com/where-the-thinking-is/ Last updated: 2026-08-31T11:15:16.000Z vibe2value started as a question: what actually gets something from idea to shipped? Not in theory. In practice. It's become a site and a way of thinking about the work that sits between having an idea and delivering something real. shape+build+launch+run+close isn't a fixed model. It's a reflection of what's held up, what's been cut and what only became obvious once I tried to ship. That's the thing. The site itself is the process. Some parts have held up. Some haven't. Some only made sense after they broke. That's how it should work, because the real work is to observe, learn and adapt. That doesn't stop. --- ## Key takeaway The framework is not a fixed model. It is a record of what held up under real builds and what did not. The site is the process. ### Reviewing AI-Assisted Code Changes URL: https://vibe2value.com/reviewing-ai-assisted-code-changes/ Last updated: 2026-05-08T00:48:22.000Z **I'm not reviewing code. I'm reviewing a change in system behaviour.** The bigger the AI-generated change, the more effort goes into reviewing intent and edges, not lines of code. Keep changes small and incremental whenever possible. That's the single best thing you can do for review quality. ### Small change (minimal risk) \~1 to 5 files, \~10 to 100 lines. Renames, formatting, tidy-ups. No behaviour change intended. 1. What is the one thing this change is meant to do? 2. Does the diff match that intent? 3. Were any new branches, defaults or fallbacks added? 4. Did auth, env vars, network calls or data writes change? 5. Was any error handling added or loosened? If it looks mechanical and behaves the same, suggest approve. ### Medium change (some risk) \~5 to 20 files, \~100 to 400 lines. Helpers added, logic reshaped. Behaviour should mostly stay the same. 1. What is supposed to change and what must not? 2. Are permissions or validation wider than before? 3. Are errors still visible and logged? 4. Do defaults still make sense? 5. What happens with empty, invalid or missing input? 6. What happens if a dependency fails? 7. If this breaks, how would I notice? Always run negative tests here. ### Large change (high risk) \~20+ files, \~400+ lines. Bulk AI edits or new flows. Direct production impact. 1. Which parts are high-risk (auth, data, config, infra)? 2. What must never change as a result of this PR? 3. Did AI "helpfully" widen behaviour or hide failure? 4. Are any errors being swallowed or turned into defaults? 5. Are retries, timeouts or fallbacks hiding problems? 6. Do I still trust the logs and alerts? 7. What would a 2am failure look like? 8. Is rollback or staged rollout in place? If you don't trust it, slow down. --- ## Key takeaway You are not reviewing code. You are reviewing a change in production behaviour. Match the depth of review to the size of the change. ### Pressure moving upstream URL: https://vibe2value.com/pressure-moving-upstream/ Last updated: 2026-05-08T00:48:22.000Z It's not speed that stands out. It's where the pressure has moved. It's no longer in syntax, debugging or getting something to compile. It's in decisions. What should this do? Where does it belong? What pattern are we reinforcing and will we notice before it's load-bearing? AI makes building fast. It doesn't remove responsibility. It exposes it. Because when building is easy, unclear structure compounds faster. You can build the wrong thing very quickly. The bottleneck isn't typing. It's clarity. --- ## Key takeaway AI moved the pressure upstream. Building is fast. Clarity is the new bottleneck. ### Don’t Reinvent the Wheel, Question the Price Tag Instead URL: https://vibe2value.com/dont-reinvent-the-wheel-question-the-price-tag-instead/ Last updated: 2026-07-19T21:07:51.000Z Not cynically. Just worth asking out loud. This isn't about rejecting tools. It's about choosing them with intention and knowing when building it yourself might actually be the better fit. Instead of: *"What tool should I buy?"* Try: *"What problem am I solving, and what's the simplest way to support it?"* Because a lot of what we pay for isn't that special. It's just packaged well. So the real question becomes: **Are you paying for capability… or for comfort?** Building it yourself isn't always the answer. But it gives you options you didn't know you had. The point isn't buy vs build. It's choosing on purpose. --- ## Key takeaway Add up your monthly subscriptions and ask honestly: capability or comfort? The answer changes what you build next. ### When effort and systems stop being the same thing URL: https://vibe2value.com/when-effort-and-systems-stop-being-the-same-thing/ Last updated: 2026-05-08T00:48:20.000Z Two people start the same week. Both ship a feature on Friday. One spent forty hours typing. The other spent six hours on a checklist that the next four features will reuse. Week one, indistinguishable. Week six, not close. ## The inflection is not scale. It is the second time. The first time you do something, effort and a system look the same. Both get it done and the system costs more up front. The second time, a system would already have paid for itself. By the fourth time, effort is losing badly and does not know it yet. The test is not "is this big enough to systematise?" It is: have I done this before, or will I do it again? ## A plan is not a document A real plan is the three decisions you make once so you do not remake them every Monday: - Who is the user. - What does done look like. - What is the rollback. Make those three once per piece of work and you have a system. Skip them and every Monday is week one again. --- ## Key takeaway Effort adds. Systems multiply. The moment you do something a second time is the moment the system would already have paid for itself. ### 3.3.3 - Are You Comfortable Putting Your Name on This Build? URL: https://vibe2value.com/are-you-comfortable-putting-your-name-on-this/ Last updated: 2026-09-07T08:59:07.000Z ## Ownership threshold Would you still ship this with your name on it to real users now? ## The call Ask yourself whether you would put your name on this. If the answer is not a clear yes, something still needs to be addressed. ## Sharpen the ownership threshold with AI This is a Launch idea, so there are two AI moves: first **Sharpen** the ownership threshold using the prompt below, then **Build it with AI**, building carefully to carry the decision into the live system. This idea also calls for **Run it for real**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real ownership threshold and keep the instruction exactly as visible here. It helps you put your launch/ownership-check.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this ownership threshold is clear enough before you move forward. Constraint: The ownership threshold must be specific enough that two people would make the same release call from it. Example of the standard: Vague: "It is good enough to ship." Sharp: "It is probabilistic, so it can be bounded and never proved. If it fails, private thinking reaches the wrong inbox. Shipping is acceptable because each sender has their own log and replies only ever go back." The sharp version is specific enough that two people would make the same release call. The vague one is not. Working draft: Unresolved gap: [what is still imperfect] User impact if it fails: [what would happen if it failed] Why shipping is acceptable now: [why shipping is still acceptable under those conditions] Task: Decide whether this ownership threshold is specific enough that two people would make the same release call. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what is still imperfect, what would happen if it failed and why shipping is still acceptable under those conditions? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Putting your name on it is the human version of asking whether you can rely on the output without checking it all again by hand. That is [Ways to make the output trustworthy](https://vibe2value.com/ways-to-make-the-output-trustworthy/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card The last check before a dish leaves the kitchen is simple: would you happily tell everyone you made this? If you would rather they thought it came from a takeaway, some part of you already knows it is not good enough to send out under your name. The ownership threshold is that last honest taste. Name what is still not perfect, what would happen if it went wrong and why you are willing to serve it anyway. If the answer is a clear "yes, I made that" it is ready, the way a cook stands proudly behind a plate rather than quietly hoping nobody asks. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means An ownership threshold is not perfectionism. It is the honest answer to whether you would stand behind this if something went wrong. Until you can name what is still imperfect, what would happen if it failed and why shipping is still acceptable, you are deferring accountability. AI can help list gaps, but it cannot decide what you are willing to own. ## Make the ownership threshold concrete Compare the broad version with a version you can actually test. - **Too vague:** It is good enough to ship. - **Concrete enough to test:** It is probabilistic, so it can be bounded and never proved. If it fails, private thinking reaches the wrong inbox. Shipping is acceptable because each sender has their own log and replies only ever go back. The second version lets two people make the same decision from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). your nameYes, sign itNot yet, fix it first The ownership threshold is the moment you decide whether you would put your name on this. If you would sign it and stand behind it, it is ready; if you hesitate, that hesitation is the to-do list, and you fix it before it ships. ## Check the ownership threshold - **Pass:** You can say what is still imperfect, what would happen if it failed and why shipping is still acceptable under those conditions. - **Fail:** If comfortable still means nobody has raised a blocker, the threshold is not honest enough yet. Do not ship until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/launch/ownership-check.md` written and sharpened: the ownership threshold pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `ownership-check.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/launch/ownership-check.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Shipping with unresolved doubt, which erodes confidence and creates reactive fixes that could have been addressed before launch. - **Mitigation:** Name what is still imperfect and why shipping is acceptable before every release. ## Key takeaway Do not move forward until you can say what is still imperfect, what would happen if it failed and why shipping is still acceptable under those conditions. ## How to document your ownership threshold Write your ownership threshold up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Ownership threshold ## Answer Unresolved gap: [what is still imperfect] User impact if it fails: [what would happen if it failed] Why shipping is acceptable now: [why shipping is still acceptable under those conditions] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Unresolved gap: The presentation is a little rough User impact if it fails: A guest notices it looks homemade, not plated Why shipping is acceptable now: It tastes good and you would happily say you made it ## Evidence Guests have happily eaten dishes that looked homemade when the taste was clearly there, and nobody minded. ## Decision Optimising for serving something I am proud of the taste of. Saying no to holding it back over presentation alone. ## Risk If the look is bad enough it could put people off the first bite. Tidy the plate enough that it invites eating. ## AI instruction The remaining gap is slightly rough presentation. Serve it anyway: it tastes good and I would happily say I made it, as long as the plate still looks inviting. ``` ### 3.3.2 - Name the Risks Yourself Before Users Find Them in Production URL: https://vibe2value.com/name-the-risks-before-users-find-them/ Last updated: 2026-09-07T08:59:04.000Z ## Launch risk Have you named the biggest risks before users hit them? ## The call Name the launch risks before users find them. Otherwise the first real user session becomes the risk discovery process. ## Sharpen the launch risk with AI This is a Launch idea, so there are two AI moves: first **Sharpen** the launch risk using the prompt below, then **Build it with AI**, building carefully to carry the decision into the live system. This idea also calls for **Run it for real**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real launch risk and keep the instruction exactly as visible here. It helps you put your launch/launch-risks.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this launch risk is clear enough before you move forward. Constraint: The launch risk must be specific enough that two people would prepare for the same failure from it. Example of the standard: Vague: "There are probably some edge cases we have not thought of." Sharp: "A capture lands in spam and is never logged. The trigger is a new sender or a forwarded thread. The response is that every capture is acknowledged by return email, so silence becomes visible." The sharp version is specific enough that two people would prepare for the same failure. The vague one is not. Working draft: Risk: [what might break] Likely trigger: [what would trigger it] Fallback or mitigation: [what response reduces the damage] Task: Decide whether this launch risk is specific enough that two people would prepare for the same failure. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what might break, what would trigger it and what response reduces the damage? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Naming what could break before it breaks is the same instinct as making a live system fail loudly instead of quietly. That is [Fail well](https://vibe2value.com/fail-well/), one of the ways to run it for real. ## The same idea on a recipe card As the guests arrive, a careful cook runs through what could still go wrong: "this oven runs hot so the top might catch, I will move it down a shelf and check at ten minutes." You find the danger yourself, early, with a fix already in hand. The alternative is a guest finding the burnt bit for you, at the table. Naming the launch risks is that run-through before serving. For each one say what could break, what would set it off and the response you have ready. Spot the hot oven yourself while you can still move the tray, rather than letting the first real user be the one who discovers it. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A launch risk is not a vague worry. It is a specific thing that might break, what would trigger it and what response is ready. Until you can name one failure mode, one trigger and one response, launch risks stay invisible until users hit them. AI can help enumerate scenarios, but it cannot decide which ones matter. ## Make the launch risk concrete Compare the broad version with a version you can actually test. - **Too vague:** There are probably some edge cases we have not thought of. - **Concrete enough to test:** A capture lands in spam and is never logged. The trigger is a new sender or a forwarded thread. The response is that every capture is acknowledged by return email, so silence becomes visible. The second version lets two people make the same decision from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). You name them firstbefore launchand mitigate eacha fix, not a surpriseWins trustnothing blindsides anyoneUsers find themin public, after launchLoses trust Every risk you do not name before launch becomes one a user finds for you, in public. Naming them on your side while they are cheap to fix is what wins trust: the launch surprises no one, including you. Leave them, and users find them, and that is what loses it. ## Check the launch risk - **Pass:** You can say what might break, what would trigger it and what response reduces the damage. - **Fail:** If launch risk still means there might be some issues, it is not named well enough yet. Do not launch until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/launch/launch-risks.md` written and sharpened: the launch risk pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `launch-risks.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/launch/launch-risks.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Launching without naming risks, which turns the first user session into the risk discovery process. - **Mitigation:** Name one launch risk per user-facing flow and prepare a response before shipping. ## Key takeaway Do not move forward until you can say what might break, what would trigger it and what response reduces the damage. ## How to document your launch risk Write your launch risk up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Launch risk ## Answer Risk: [what might break] Likely trigger: [what would trigger it] Fallback or mitigation: [what response reduces the damage] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Risk: The top of the dish catches and burns Likely trigger: This oven runs hot Fallback or mitigation: Move it down a shelf and check at ten minutes ## Evidence This oven has burned the tops of two dishes at the stated time, so it clearly runs hot. ## Decision Optimising for naming the burn risk before serving. Saying no to trusting the recipe time on this oven. ## Risk Moving it down could leave the top pale instead. Check at ten minutes and adjust rather than set and forget. ## AI instruction The launch risk is the top catching and burning because this oven runs hot. Move the dish down a shelf and check it at ten minutes rather than trusting the timer. ``` ### 3.3.1 - What "Ready" Actually Means Once Real Users Are Looking URL: https://vibe2value.com/what-ready-actually-means/ Last updated: 2026-09-07T08:59:01.000Z ## Readiness rule Are readiness criteria clear enough for launch with AI-assisted coding? ## The call Define ready before the pressure to ship decides for you. Otherwise AI helps you polish indefinitely or launch too early. ## Sharpen the readiness rule with AI This is a Launch idea, so there are two AI moves: first **Sharpen** the readiness rule using the prompt below, then **Build it with AI**, building carefully to carry the decision into the live system. This idea also calls for **Run it for real**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real readiness rule and keep the instruction exactly as visible here. It helps you put your launch/readiness-rule.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this readiness rule is clear enough before you move forward. Constraint: The readiness rule must be specific enough that two people would make the same ship or hold call from it. Example of the standard: Vague: "We will ship when it feels ready." Sharp: "Ready means twelve emails in, twelve logged and one digest out, checked by hand on a real mailbox with what came back written down. Anything the suggestion gets wrong is mine." The sharp version is specific enough that two people would make the same ship or hold call. The vague one is not. Working draft: Pass check: [what has to be true] How it is checked: [how it will be checked] Remaining risk owner: [who owns any remaining risk] Task: Decide whether this readiness rule is specific enough that two people would make the same ship or hold call. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what has to be true, how it will be checked and who owns any remaining risk? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Ready is a claim that you can stand behind it, which is the whole trustworthy question in three letters. That is [Ways to make the output trustworthy](https://vibe2value.com/ways-to-make-the-output-trustworthy/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card A meal is ready to serve when the checks pass, not when it feels about done: the chicken is up to temperature, the sides are hot and the plates are warm. Plate up on a vague feeling and someone gets a cold side or a pink middle, in front of the guests. Your readiness rule is that set of checks before plating. Name what has to be true before you serve, how each thing is checked and who owns anything still risky. Agree it before the pressure to get food out decides for you, so ready is a passed checklist and not just a hopeful mood. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A readiness rule is not a feeling of completeness. It is the specific set of conditions that must be true before shipping. Until you can name what has to be true, how it will be checked and who owns any remaining risk, readiness is just a mood. AI can help verify conditions, but it cannot set the bar. ## Make the readiness rule concrete Compare the broad version with a version you can actually test. - **Too vague:** We will ship when it feels ready. - **Concrete enough to test:** Ready means twelve emails in, twelve logged and one digest out, checked by hand on a real mailbox with what came back written down. Anything the suggestion gets wrong is mine. The second version lets two people make the same decision from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). A user can finish the taskNo known blocker remainsYou would put your name on itReady?the written barShip Ready is not a feeling, it is a bar you wrote down. When a user can finish the task, no known blocker remains and you would put your name on it, you are ready, and "it feels ready" never gets a vote. ## Check the readiness rule - **Pass:** You can say what has to be true, how it will be checked and who owns any remaining risk. - **Fail:** If ready still means it looks good or nobody has found a problem, the rule is not clear enough yet. Do not move into launch until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/launch/readiness-rule.md` written and sharpened: the readiness rule pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `readiness-rule.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/launch/readiness-rule.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Shipping before readiness conditions are met, which damages trust and creates urgent fixes that could have been prevented. - **Mitigation:** Define readiness conditions before the launch date and do not override them without evidence. ## Key takeaway Do not move forward until you can say what has to be true, how it will be checked and who owns any remaining risk. ## How to document your readiness rule Write your readiness rule up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Readiness rule ## Answer Pass check: [what has to be true] How it is checked: [how it will be checked] Remaining risk owner: [who owns any remaining risk] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Pass check: The chicken is up to temperature, the sides are hot and the plates are warm How it is checked: A thermometer in the chicken and a hand on the plates before serving Remaining risk owner: The head cook plates up only once every check passes ## Evidence The plates that went out before everything was hot came back with complaints, so nearly ready is not ready. ## Decision Optimising for every plate leaving only when the checks pass. Saying no to sending food out to save a few minutes. ## Risk Under pressure a check gets skipped. Make the checks quick and give one person the call to hold the plate. ## AI instruction Ready means the chicken is up to temperature and the sides and plates are hot, checked by a thermometer and a hand on the plate. The head cook plates up only once every check passes. ``` ### 3.2.3 - Iteration Should Increase Value, Not Just Add Surface Area URL: https://vibe2value.com/iteration-should-increase-value/ Last updated: 2026-09-07T08:58:59.000Z ## Iteration value test Is iteration increasing user value before launch with AI-assisted coding? ## The call Check whether each iteration increased value. Otherwise you ship changes that feel productive while the user outcome stays flat. ## Sharpen the iteration value test with AI This is a Launch idea, so there are two AI moves: first **Sharpen** the iteration value test using the prompt below, then **Build it with AI**, building carefully to carry the decision into the live system. This idea also calls for **Run it for real**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real iteration value test and keep the instruction exactly as visible here. It helps you put your launch/iteration-value-test.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this iteration value test is clear enough before you move forward. Constraint: The iteration value test must be specific enough that two people would judge the same release as worthwhile from it. Example of the standard: Vague: "We shipped an update and it feels better." Sharp: "This release quotes your own words back, so you recognise the thought before deciding. The test is whether suggestions get acted on rather than skimmed." The sharp version is specific enough that two people would judge the same release as worthwhile. The vague one is not. Working draft: Release change: [what changed in this iteration] User outcome to improve: [what user outcome it should improve] Proof signal: [what signal will show that it helped] Task: Decide whether this iteration value test is specific enough that two people would judge the same release as worthwhile. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what changed, what user outcome it is meant to improve and what signal will show that it did? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Iterating on a live thing without piling on surface area is a running-it-for-real discipline. That is [Ways to run it for real](https://vibe2value.com/ways-to-run-it-for-real/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card Every change to a dish should make it taste better, not just add another ingredient to the list. Throwing in a sixth herb because it is in the cupboard makes the recipe longer and not nicer. A good cook keeps only the change that actually improved the bite and quietly drops the rest. Your iteration value test is that taste-it-again check. Name what you changed, what it was meant to improve and the sign it actually did. Keep the change only if the dish got better, the way a cook adds a herb to improve the flavour and not just to lengthen the recipe. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means An iteration value test is not a diff. It is the check that says whether the change made the user outcome better, worse or unchanged. Until you can name what changed, what it was meant to improve and what signal shows it worked, iterations stay unmeasured. AI can help generate options, but it cannot judge whether the output improved. ## Make the iteration value test concrete Compare the broad version with a version you can actually test. - **Too vague:**��We shipped an update and it feels better. - **Concrete enough to test:** This release quotes your own words back, so you recognise the thought before deciding. The test is whether suggestions get acted on rather than skimmed. The second version lets two people make the same decision from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). v1v2v3value risingbusy but flatchanges, no added value Iteration is only progress if value goes up. The test for each round is whether it added something a user would actually feel; if the version changed but the value did not rise, that was motion, not iteration. ## Check the iteration value test - **Pass:** You can say what changed, what user outcome it is meant to improve and what signal will show that it did. - **Fail:** If the iteration still sounds like we made improvements, the value test is not clear enough yet. Do not ship the next iteration until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/launch/iteration-value-test.md` written and sharpened: the iteration value test pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `iteration-value-test.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/launch/iteration-value-test.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Shipping iterations that feel productive but do not increase user value, which accumulates complexity without benefit. - **Mitigation:** Define one value signal per iteration and roll back changes that do not move it. ## Key takeaway Do not move forward until you can say what changed, what user outcome it is meant to improve and what signal will show that it did. ## How to document your iteration value test Write your iteration value test up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Iteration value test ## Answer Release change: [what changed in this iteration] User outcome to improve: [what user outcome it should improve] Proof signal: [what signal will show that it helped] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Release change: Adding a sixth herb from the cupboard User outcome to improve: The taste of the dish Proof signal: A taste test says the bite is actually better, not just longer ## Evidence A past improvement added ingredients without a taste test and the dish got busier, not better. ## Decision Optimising for changes that improve the taste. Saying no to adding things just to have added something. ## Risk The sixth herb might muddy the dish rather than lift it. Taste against the previous version before keeping it. ## AI instruction Judge the sixth herb by whether a taste test says the dish is actually better, not just more complex. Keep the change only if it improves the taste. ``` ### 3.2.2 - Explain Your Decisions Before Asking for Review URL: https://vibe2value.com/explain-your-decisions-before-asking-for-review/ Last updated: 2026-09-07T08:58:57.000Z ## Review context Can your decisions be understood before they are reviewed? ## The call Explain what you decided before asking someone to review it. Otherwise reviewers waste time guessing your intent and feedback drifts into opinion. ## Sharpen the review context with AI This is a Launch idea, so there are two AI moves: first **Sharpen** the review context using the prompt below, then **Build it with AI**, building carefully to carry the decision into the live system. This idea also calls for **Run it for real**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real review context and keep the instruction exactly as visible here. It helps you put your launch/review-context.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this review context is clear enough before you move forward. Constraint: The review context must be specific enough that two people would ask reviewers for the same kind of feedback from it. Example of the standard: Vague: "Here is the latest version, let me know what you think." Sharp: "We decided it suggests and never drafts. The trade-off is that you still have to write the thing. The question for reviewers is whether stopping short read as respect or as a gap." The sharp version is specific enough that two people would ask reviewers for the same kind of feedback. The vague one is not. Working draft: Decision made: [what was decided] Trade-off created: [what trade-off it created] Question for reviewers: [what reviewers should answer] Task: Decide whether this review context is specific enough that two people would ask reviewers for the same kind of feedback. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what was decided, what trade-off it created and what question you want reviewers to answer? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. A reviewer who knows why you chose something catches different things from one who does not, which is the fresh-eyes move. That is [Review with fresh eyes](https://vibe2value.com/review-with-fresh-eyes/), one of the ways to make the output trustworthy. ## The same idea on a recipe card When you hand a dish to another cook to judge, you say what you were going for: "I went lighter on the chilli so the kids would eat it, but is it still interesting for the adults?" Now they know what to taste for. Just sliding the plate over with "try this" gets you a shrug and a vague "yeah, nice". Review context is that bit of explaining before the tasting. Name the decision you made, the trade-off it created and the one thing you want the reviewer to judge. Tell them what you were aiming at and you get real judgement back, not a polite guess at what you even wanted. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means Review context is not a changelog. It is the explanation of what was decided, why, and what question the reviewer should focus on. Until you can name one decision, one trade-off it created and one question for the reviewer, the review will drift. AI can help draft context, but it cannot decide what the reviewer needs to know. ## Make the review context concrete Compare the broad version with a version you can actually test. - **Too vague:** Here is the latest version, let me know what you think. - **Concrete enough to test:** We decided it suggests and never drafts. The trade-off is that you still have to write the thing. The question for reviewers is whether stopping short read as respect or as a gap. The second version lets two people make the same decision from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). The work + the whywhat you tried and chose, and whyUseful reviewaimed at your real decisionJust the workno contextguesswork review Explaining your decisions before a review hands the reviewer the why, not just the what, so their feedback lands on the real choice you made. Drop the work on them cold and they review their guess at your intent instead. ## Check the review context - **Pass:** You can say what was decided, what trade-off it created and what question you want reviewers to answer. - **Fail:** If the review request still reads as have a look and share your thoughts, the context is not defined well enough yet. Do not ask for review until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/launch/review-context.md` written and sharpened: the review context pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `review-context.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/launch/review-context.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Asking for review without context, which turns feedback into opinion and slows decisions. - **Mitigation:** Include one decision, one trade-off and one question with every review request. ## Key takeaway Do not move forward until you can say what was decided, what trade-off it created and what question you want reviewers to answer. ## How to document your review context Write your review context up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Review context ## Answer Decision made: [what was decided] Trade-off created: [what trade-off it created] Question for reviewers: [what reviewers should answer] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Decision made: I went lighter on the chilli so the kids would eat it Trade-off created: It might be less interesting for the adults Question for reviewers: Is it still interesting enough for grown-up palates ## Evidence When I have handed a plate over without saying what I chose, reviewers flagged things I had already decided on purpose. ## Decision Optimising for a review of the real open question. Saying no to letting reviewers relitigate the chilli choice. ## Risk Reviewers might still fixate on the heat. Tell them the choice and point them at the question I actually need answered. ## AI instruction Before asking for a taste, explain the decision: I went lighter on the chilli for the kids, which may make it less interesting for adults. Ask reviewers only whether it is still interesting enough for grown-up palates. ``` ### 3.2.1 - The Difference Between Learning and Being Stuck URL: https://vibe2value.com/the-difference-between-learning-and-being-stuck/ Last updated: 2026-09-07T08:58:55.000Z ## Learning signal Are we learning something new or just stuck in loops? ## The call Know whether you are learning or stuck. Otherwise AI helps you iterate without evidence and every cycle feels like progress while nothing changes. ## Sharpen the learning signal with AI This is a Launch idea, so there are two AI moves: first **Sharpen** the learning signal using the prompt below, then **Build it with AI**, building carefully to carry the decision into the live system. This idea also calls for **Run it for real**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real learning signal and keep the instruction exactly as visible here. It helps you put your launch/learning-signal.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this learning signal is clear enough before you move forward. Constraint: The learning signal must be specific enough that two people would call the same work progress from it. Example of the standard: Vague: "We are iterating and learning as we go." Sharp: "The question is whether the policy is what makes a suggestion useful. The signal is someone editing their skill rather than leaving, and it decides whether refining is a page or a conversation." The sharp version is specific enough that two people would call the same work progress. The vague one is not. Working draft: Learning question: [what question is being answered] Signal: [what signal will answer it] Next decision: [what decision comes next] Task: Decide whether this learning signal is specific enough that two people would call the same work progress. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what question is being answered, what signal will answer it and what decision comes next? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Telling learning apart from stuck is the same judgement as knowing when to step in and take the wheel back. That is [Know when to step in](https://vibe2value.com/know-when-to-step-in/), one of the ways to run it for real. ## The same idea on a recipe card There are two ways to keep remaking a dish. One is "a little more lemon this time", then tasting to see if it fixed the flatness: each cook answers a question. The other is changing five things at once every night, so you never learn what actually helped and the dish never really improves, however busy you feel. Telling learning from being stuck is the difference between the purposeful tweak and the endless fiddle. Name the one question each round is meant to answer, the taste that answers it and what you will do next. If a round answers nothing you are stuck and not iterating, however many versions you cook. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A learning signal is not a feeling of progress. It is the specific answer that tells you whether the last iteration worked. Until you can name one question being answered, one signal that answers it and one decision that follows, you are iterating blind. AI can help run experiments, but it cannot tell you when to stop. ## Make the learning signal concrete Compare the broad version with a version you can actually test. - **Too vague:** We are iterating and learning as we go. - **Concrete enough to test:** The question is whether the policy is what makes a suggestion useful. The signal is someone editing their skill rather than leaving, and it decides whether refining is a page or a conversation. The second version lets two people make the same decision from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). LEARNINGsomething new each roundSTUCKsame loop, nothing new Learning and being stuck can both feel busy. The signal that tells them apart is simple: in learning, each round brings new information and moves you forward; stuck is the same loop again, so when nothing new is arriving, stop and change the approach. ## Check the learning signal - **Pass:** You can say what question is being answered, what signal will answer it and what decision comes next. - **Fail:** If learning still means we are figuring it out as we go, the signal is not defined well enough yet. Do not move into the next iteration until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/launch/learning-signal.md` written and sharpened: the learning signal pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `learning-signal.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/launch/learning-signal.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Iterating without a learning signal, which creates output that feels like progress while the core question stays unanswered. - **Mitigation:** Define one learning question per iteration and pause when the signal is unclear. ## Key takeaway Do not move forward until you can say what question is being answered, what signal will answer it and what decision comes next. ## How to document your learning signal Write your learning signal up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Learning signal ## Answer Learning question: [what question is being answered] Signal: [what signal will answer it] Next decision: [what decision comes next] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Learning question: Does more lemon fix the flatness Signal: You taste it after that one change Next decision: Keep the lemon or try one other single change ## Evidence The times I changed three things at once I never knew which one helped, so one change at a time actually teaches me something. ## Decision Optimising for a clear lesson from each change. Saying no to adjusting several things before tasting. ## Risk Tasting too soon, before the lemon is stirred through, gives a false read. Let it settle, then taste. ## AI instruction Change one thing, more lemon, then taste to learn whether it fixes the flatness. Based on that, keep the lemon or try one other single change, never several at once. ``` ### 3.1.3 - Decide in Advance What Would Change Your Mind URL: https://vibe2value.com/decide-in-advance-what-would-change-your-mind/ Last updated: 2026-09-07T05:58:28.000Z ## Decision threshold What evidence would make you change your mind? ## The call Set the line before the evidence arrives. Otherwise every piece of feedback reopens the same debate and nothing moves forward. ## Sharpen the decision threshold with AI This is a Launch idea, so there are two AI moves: first **Sharpen** the decision threshold using the prompt below, then **Build it with AI**, building carefully to carry the decision into the live system. This idea also calls for **Run it for real**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real decision threshold and keep the instruction exactly as visible here. It helps you put your launch/decision-threshold.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this decision threshold is clear enough before you move forward. Constraint: The decision threshold must be specific enough that two people would make the same course correction from it. Example of the standard: Vague: "We will keep watching and change course if needed." Sharp: "If nobody sends twice in the first fortnight we stop, and we write up why rather than adding features to rescue it. The evidence is the logs, which are ours to read." The sharp version is specific enough that two people would make the same course correction. The vague one is not. Working draft: Threshold: [what evidence will trigger change] Evidence source: [where that evidence comes from] Action that follows: [what action follows if it is met or missed] Task: Decide whether this decision threshold is specific enough that two people would make the same course correction. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what evidence will trigger change, where it will come from and what action follows? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Setting the threshold before the data arrives is what stops you arguing with it once it lands. That is [Ways to run it for real](https://vibe2value.com/ways-to-run-it-for-real/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card Decide before the dinner what would make you retire a recipe: "if nobody asks for seconds, this one comes off the menu." Set that line in the calm before, and the answer is clear afterwards. Leave it until everyone is being kind at the table and you will keep cooking the dish nobody actually enjoys for years. Your decision threshold is that line set before the meal. Name the evidence that would change your mind, where it will come from and what you will do when it arrives. Decide it in advance while you are calm, so feedback settles the question instead of reopening the same argument every time. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A decision threshold is not a future feeling. It is the line that says what evidence would make you continue, cut or change direction. Until you can name one threshold, one evidence source and one action you will take if it is met, you are still improvising. AI can help compare scenarios, but it cannot commit you to a line. ## Make the decision threshold concrete Compare the broad version with a version you can actually test. - **Too vague:** We will keep watching and change course if needed. - **Concrete enough to test:** If nobody sends twice in the first fortnight we stop, and we write up why rather than adding features to rescue it. The evidence is the logs, which are ours to read. The second version lets two people make the same course correction from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). finish a searchcome backsearch againrecommend itfind it useful↑ keep going↓ change your mindthe bar, set in advance A decision threshold is a line you draw before the results are in. Each signal is measured against it: the ones that clear the bar say keep going, the ones below it are what would change your mind. Deciding the line in advance stops you moving the goalposts to match whatever you got. ## Check the decision threshold - **Pass:** You can say what evidence will trigger change, where it will come from and what action follows. - **Fail:** If changing your mind still depends on watching how it feels over time, the threshold is not clear enough yet. Do not move into launch or iteration work until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/launch/decision-threshold.md` written and sharpened: the decision threshold pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `decision-threshold.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/launch/decision-threshold.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Moving the threshold after feedback arrives, which turns every comment into a new argument and slows launch decisions. - **Mitigation:** Define one clear evidence rule before release and revisit it only when new data shows the original rule no longer protects user outcomes. ## Key takeaway Do not move forward until you can say what evidence will trigger change, where it will come from and what action follows. ## How to document your decision threshold Write your decision threshold up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Decision threshold ## Answer Threshold: [what evidence will trigger change] Evidence source: [where that evidence comes from] Action that follows: [what action follows if it is met or missed] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Threshold: Nobody asks for seconds Evidence source: What happens at the dinner table Action that follows: The dish comes off the menu ## Evidence I have kept dishes too long on gut feeling, so deciding the cut-off before the meal keeps me honest. ## Decision Optimising for a rule set in advance. Saying no to arguing the dish back onto the menu after the fact. ## Risk One quiet night might not be a fair test. Set the threshold across a couple of meals, not one. ## AI instruction Decide in advance: if nobody asks for seconds across the next dinners, the dish comes off the menu. Judge it by what happens at the table, and follow the rule. ``` ### 3.1.2 - Ask for Signals, Not Opinions, From the People You Trust URL: https://vibe2value.com/ask-for-signals-not-opinions/ Last updated: 2026-09-07T05:58:26.000Z ## Decision signal Are you seeing real signals or just opinions? ## The call Ask for behaviour, not applause. Otherwise feedback confirms what you already believe while real friction stays hidden. ## Sharpen the decision signal with AI This is a Launch idea, so there are two AI moves: first **Sharpen** the decision signal using the prompt below, then **Build it with AI**, building carefully to carry the decision into the live system. This idea also calls for **Run it for real** and **Make the output trustworthy**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real decision signal and keep the instruction exactly as visible here. It helps you put your launch/decision-signal.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this decision signal is clear enough before you move forward. Constraint: The decision signal must be specific enough that two people would interpret the same evidence from it. Example of the standard: Vague: "We want feedback on whether people like it." Sharp: "We want to see a second week of captures nobody reminded them about, because that means it became part of finishing a task, and it decides whether the digest is worth paying to run." The sharp version is specific enough that two people would interpret the same evidence. The vague one is not. Working draft: Signal to watch: [what behavior or result you need to see] Behavior behind it: [what action creates that signal] Decision it changes: [what decision it will change] Task: Decide whether this decision signal is specific enough that two people would interpret the same evidence. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. 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 point to the behavior or result you need to see and explain what decision it will change Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Signals come out of a running system and opinions come out of a conversation. That is [Ways to run it for real](https://vibe2value.com/ways-to-run-it-for-real/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card At dinner, everyone says "lovely, thank you" to be polite, whether they mean it or not. What actually tells you is the empty serving dish and the guest quietly going back for a second helping. One is good manners, the other is real evidence. Asking for signals not opinions is watching the second helpings instead of fishing for compliments. Name the behaviour you can actually see, what it would tell you and the decision it would change. "Do you like it?" invites politeness, but an empty dish cannot lie. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A decision signal is not just more feedback. It is an observable behaviour or result that can change the next product decision. Until you can name one observable signal, one behaviour behind it and one decision it will change, the conversation will drift into opinion. AI can help summarise reactions, but it cannot turn vague feedback into evidence on its own. ## Make the decision signal concrete Compare the broad version with a version you can actually test. - **Too vague:** We want feedback on whether people like it. - **Concrete enough to test:** We want to see a second week of captures nobody reminded them about, because that means it became part of finishing a task, and it decides whether the digest is worth paying to run. The second version lets two people interpret the same evidence from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). "I love it""looks great""I'd totally use this"opinions (noise)filterThey came backand searched again Opinions are cheap and mostly noise, people are kind. A decision signal is a behaviour you can count, like someone coming back unprompted, so you ask for signals not opinions and let what they do outweigh what they say. ## Check the decision signal - **Pass:** You can point to the behaviour or result you need to see and explain what decision it will change. - **Fail:** If you are still asking for thoughts, opinions or reactions in general, the signal is not defined well enough yet. Do not move into feedback collection or iteration work until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/launch/decision-signal.md` written and sharpened: the decision signal pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `decision-signal.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/launch/decision-signal.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Treating confident opinions as evidence, which can push launch decisions in the wrong direction while real user issues stay hidden. - **Mitigation:** Agree on one behaviour signal per decision and only change direction when that signal crosses the threshold you set in advance. ## Key takeaway Do not move forward until you can point to the behaviour or result you need to see and explain what decision it will change. ## How to document your decision signal Write your decision signal up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Decision signal ## Answer Signal to watch: [what behavior or result you need to see] Behavior behind it: [what action creates that signal] Decision it changes: [what decision it will change] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Signal to watch: The empty serving dish Behavior behind it: A guest quietly going back for a second helping Decision it changes: Whether this dish stays on the menu ## Evidence The dishes that sold out quietly are the ones I kept, and the ones I only heard nice words about often did not last. ## Decision Optimising for what people do, not what they say. Saying no to letting polite comments decide the menu. ## Risk An empty dish could just mean it was first out or there was little else. Watch it across more than one meal. ## AI instruction Judge this dish by the signal of an empty serving dish and guests quietly going back for more, not by their opinions. Let that decide whether it stays on the menu. ``` ### 3.1.1 - Why Sharing Early Creates the Learning Your Build Needs URL: https://vibe2value.com/why-sharing-early-creates-learning/ Last updated: 2026-09-07T05:58:25.000Z ## Early sharing plan Are you sharing early enough to learn something useful? ## The call Share before it feels ready. Otherwise you launch with assumptions that could have been tested weeks earlier. ## Sharpen the early sharing plan with AI This is a Launch idea, so there are two AI moves: first **Sharpen** the early sharing plan using the prompt below, then **Build it with AI**, building carefully to carry the decision into the live system. This idea also calls for **Run it for real**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real early sharing plan and keep the instruction exactly as visible here. It helps you put your launch/early-sharing-plan.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this early sharing plan is clear enough before you move forward. Constraint: The early sharing plan must be specific enough that two people would run the same learning loop from it. Example of the standard: Vague: "We should share it early and get feedback." Sharp: "Give it to four people who write and do not read the site. They get an address and one line about what to send. The question is whether anything arrives without being asked for." The sharp version is specific enough that two people would run the same learning loop. The vague one is not. Working draft: Audience: [who will see it] What they will see: [what they will see] Question to answer: [what question their reaction needs to answer] Task: Decide whether this early sharing plan is specific enough that two people would run the same learning loop. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state who will see it, what they will see and what question their reaction needs to answer? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Putting something in front of people is the moment a build becomes a live thing you are answerable for. That is [Ways to run it for real](https://vibe2value.com/ways-to-run-it-for-real/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card Picture asking someone to taste the sauce while you are still at the stove: "try this, does it need more salt?" You can still fix it. Wait until the full dinner is plated and served before you find out it was bland, and there is nothing left to do but apologise. Sharing early is that spoonful held out mid-cook. Pick one person to taste, one thing to show them and the one question you need answered, before the dish is finished. You share to learn while you can still change it, not to collect applause once the plates are already down. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means Sharing early is not just posting work sooner. It is choosing who should see what and what question that exposure is meant to answer. Until you can name one audience, one thing to show and one question you need answered, early sharing turns into noise. AI can help package the work, but it cannot decide what learning matters. ## Make the early sharing plan concrete Compare the broad version with a version you can actually test. - **Too vague:** We should share it early and get feedback. - **Concrete enough to test:** Give it to four people who write and do not read the site. They get an address and one line about what to send. The question is whether anything arrives without being asked for. The second version lets two people run the same learning loop from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). A rough buildshared this week5 real userstry it nowsharelearningshare lateno time to learn Sharing early creates a loop: a rough build goes to a few real users and what you learn comes straight back while you can still act on it. Share late and the build is finished before the learning arrives, when it is too expensive to use. ## Check the early sharing plan - **Pass:** You can say who will see it, what they will see and what question their reaction needs to answer. - **Fail:** If sharing early still means putting it in front of people and seeing what happens, it is not clear enough yet. Do not move into outreach, launch or feedback collection until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/launch/early-sharing-plan.md` written and sharpened: the early sharing plan pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `early-sharing-plan.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/launch/early-sharing-plan.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Sharing early without a clear intent, which invites broad opinions that slow launch choices and hide real user friction. - **Mitigation:** Define one learning question for each share and only act on feedback tied to observable behaviour. ## Key takeaway Do not move forward until you can say who will see it, what they will see and what question their reaction needs to answer. ## How to document your early sharing plan Write your early sharing plan up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Early sharing plan ## Answer Audience: [who will see it] What they will see: [what they will see] Question to answer: [what question their reaction needs to answer] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Audience: Someone in the kitchen with you What they will see: A spoonful of the sauce while it is still on the stove Question to answer: Does it need more salt ## Evidence When I have let someone taste mid-cook they have caught an underseasoned sauce while I could still fix it. ## Decision Optimising for one quick taste while it is still on the stove. Saying no to waiting until it is plated to ask. ## Risk A single taster's palate might not match the table's. Take it as one signal, not the final word. ## AI instruction Share a spoonful of the sauce with someone in the kitchen while it is still cooking. Ask one question, does it need more salt, and use the answer while there is time to change it. ``` ### 2.3.3 - The One Metric That Proves This Works for Real Users URL: https://vibe2value.com/the-one-metric-that-proves-this-works/ Last updated: 2026-09-07T08:58:52.000Z ## Proof metric Is this metric proving real value or just reporting activity? ## The call Choose one metric before you measure everything. Otherwise AI helps you build dashboards that track activity while value stays invisible. ## Sharpen the proof metric with AI This is a Build idea, so there are two AI moves: first **Sharpen** the proof metric using the prompt below, then **Build it with AI**, vibeCoding the thinnest working code that tests the decision. This idea also calls for **Make the output trustworthy**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real proof metric and keep the instruction exactly as visible here. It helps you put your build/proof-metric.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this proof metric is clear enough before you move forward. Constraint: The proof metric must be specific enough that two people would make the same keep or cut decision from it. Example of the standard: Vague: "We will track engagement and adoption." Sharp: "We will track captures per sender per week, because it means they reached for it while still working. Three a week from more than one person is proof." The sharp version is specific enough that two people would make the same keep or cut decision. The vague one is not. Working draft: Metric: [what the metric is] User behavior behind it: [what user behavior creates it] Threshold: [what threshold counts as enough] Task: Decide whether this proof metric is specific enough that two people would make the same keep or cut decision. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what the metric is, what user behavior creates it and what threshold counts as enough? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. A metric only proves anything once real people are using it, which puts this on the live-system side of the work. That is [Ways to run it for real](https://vibe2value.com/ways-to-run-it-for-real/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card The proof a meal worked is not how many pans you used or how long you were in the kitchen. It is the clean plates and the hand reaching out for seconds. A kitchen can be a whirl of activity all night and still send out food that comes back barely touched. Your proof metric is the clean plate and not the busy kitchen. Name the one signal that shows the user got the outcome you promised, the behaviour behind it and the line that counts as proof. Measure the seconds being asked for and not the number of pots, so activity never gets mistaken for value. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A proof metric is not a dashboard full of numbers. It is the one signal that tells you whether the work created the result you care about. Until you can name one metric, one user behaviour behind it and one threshold that counts as proof, measurement will stay fuzzy. AI can help analyse data, but it cannot decide which metric is the decision line. ## Make the proof metric concrete Compare the broad version with a version you can actually test. - **Too vague:** We will track engagement and adoption. - **Concrete enough to test:** We will track captures per sender per week, because it means they reached for it while still working. Three a week from more than one person is proof. The second version lets two people make the same keep or cut decision from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). vanity metricssignups, page views, likesTHE PROOF METRICusers who come back and search again Most metrics are vanity, they move and prove nothing. The one proof metric is the single signal that would change your mind about whether this works, like users returning to search again, and it is the only one worth watching closely. ## Check the proof metric - **Pass:** You can say what the metric is, what user behaviour creates it and what threshold counts as enough. - **Fail:** If the metric still depends on general words like usage, growth or engagement, it is not clear enough yet. Do not move into launch, iteration or analysis work until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/build/proof-metric.md` written and sharpened: the proof metric pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `proof-metric.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/build/proof-metric.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Optimising for a metric that looks strong while user value stays flat, which can push the build in the wrong direction. - **Mitigation:** Pair the core metric with one user-impact check and only scale changes when both move in the same direction. ## Key takeaway Do not move forward until you can say what the metric is, what user behaviour creates it and what threshold counts as enough. ## How to document your proof metric Write your proof metric up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Proof metric ## Answer Metric: [what the metric is] User behavior behind it: [what user behavior creates it] Threshold: [what threshold counts as enough] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Metric: Clean plates and hands reaching for seconds User behavior behind it: Guests going back for a second helping Threshold: More than half the table asks for seconds ## Evidence The dishes people love are the ones the serving dish empties on, and the ones they do not come back to sit half eaten. ## Decision Optimising for a dish people want more of. Saying no to judging success by polite compliments. ## Risk People might take seconds out of politeness or hunger. Look for more than half the table doing it, not one guest. ## AI instruction The proof this dish works is clean plates and hands reaching for seconds. Count it a success when more than half the table goes back for more. ``` ### 2.3.2 - Why Cutting Features Is a Design Skill Most Builders Skip URL: https://vibe2value.com/why-cutting-features-is-a-design-skill-in-ai-assisted-software-development/ Last updated: 2026-09-07T05:58:22.000Z ## Feature cut Are you cutting features that distract from the main user path? ## The call Cut before AI adds more. Otherwise every option AI generates becomes a feature and the product grows without getting better. ## Sharpen the feature cut with AI This is a Build idea, so there are two AI moves: first **Sharpen** the feature cut using the prompt below, then **Build it with AI**, vibeCoding the thinnest working code that tests the decision. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real feature cut and keep the instruction exactly as visible here. It helps you put your build/feature-cut.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this feature cut is clear enough before you move forward. Constraint: The feature cut must be specific enough that two people would remove the same complexity from it. Example of the standard: Vague: "We should probably keep it simple." Sharp: "We protect email in, digest out, and we cut drafting the post for you, because a draft nobody asked for buries the suggestion underneath it." The sharp version is specific enough that two people would remove the same complexity. The vague one is not. Working draft: Core path to protect: [what must stay central] Feature to cut: [what gets removed] Why the cut strengthens it: [why the product gets stronger because of that cut] Task: Decide whether this feature cut is specific enough that two people would remove the same complexity. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what stays central, what gets removed and why the product becomes stronger because of that cut? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Cutting is a build decision usually made under pressure, which is when having a method rather than an instinct matters most. That is [Ways to build it with AI](https://vibe2value.com/ways-to-build-it-with-ai/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card A great plate is often three things done perfectly, not eleven crowded together. Taking the extra garnish and the third sauce off the plate is a real skill, because it lets the main flavour come through clearly. Pile more on and every bite tastes muddier, even though it looks like more for the money. Cutting features is that same skill of taking things off the plate. Name the core flavour you are protecting, the thing you are removing and why the dish is stronger without it. Removing is a decision and not an accident, the way a chef plates three things well rather than eleven badly. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A feature cut is not an omission by accident. It is a design decision that protects the core path from noise. Until you can name one core path, one feature to cut and one reason the cut strengthens the product, the product will keep expanding. AI can help add surface area fast, but it cannot decide what should stay out. ## Make the feature cut concrete Compare the broad version with a version you can actually test. - **Too vague:** We should probably keep it simple. - **Concrete enough to test:** We protect email in, digest out, and we cut drafting the post for you, because a draft nobody asked for buries the suggestion underneath it. The second version lets two people remove the same complexity from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). candidate featuresemail in, digest outdrafting the posta dashboardschedulinganalyticsThe coredone really well Cutting features is a design skill because every feature you keep dilutes the one that matters. You strike out everything that is not the core, not because it is bad, but so the core has room to be genuinely good. ## Check the feature cut - **Pass:** You can say what stays central, what gets removed and why the product becomes stronger because of that cut. - **Fail:** If the cut still sounds like we will keep it simple for now, it is not concrete enough yet. Do not move into implementation or polish work until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/build/feature-cut.md` written and sharpened: the feature cut pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `feature-cut.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/build/feature-cut.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Cutting a feature that looked optional but protected a critical edge case, which can degrade trust after release. - **Mitigation:** Define one user-critical scenario before each cut and validate that scenario with real usage signals before rollout. ## Key takeaway Do not move forward until you can say what stays central, what gets removed and why the product becomes stronger because of that cut. ## How to document your feature cut Write your feature cut up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Feature cut ## Answer Core path to protect: [what must stay central] Feature to cut: [what gets removed] Why the cut strengthens it: [why the product gets stronger because of that cut] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Core path to protect: The main flavour of the plate Feature to cut: The extra garnish and the third sauce Why the cut strengthens it: The main flavour comes through clearly instead of muddy ## Evidence The last plate had three sauces and a garnish, and tasters said it was busy and hard to place the main flavour. ## Decision Optimising for one clear main flavour. Saying no to the extra garnish and the third sauce. ## Risk Cutting too much could leave the plate plain. Cut the extras first and taste before removing anything core. ## AI instruction Protect the main flavour of the plate. Cut the extra garnish and the third sauce so that flavour comes through clearly instead of muddy. ``` ### 2.3.1 - Where the Real Differentiation Actually Lives in Your Build URL: https://vibe2value.com/where-the-real-differentiation-actually-lives/ Last updated: 2026-09-07T08:58:50.000Z ## Real differentiation Where does real differentiation show up for users? ## The call Name the advantage before building around it. Otherwise AI helps you add features that look different but feel the same as every alternative. ## Sharpen the real differentiation with AI This is a Build idea, so there are two AI moves: first **Sharpen** the real differentiation using the prompt below, then **Build it with AI**, vibeCoding the thinnest working code that tests the decision. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real differentiation and keep the instruction exactly as visible here. It helps you put your build/differentiation.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this real differentiation is clear enough before you move forward. Constraint: The real differentiation must be specific enough that two people would invest in the same custom work from it. Example of the standard: Vague: "Our differentiation is that we use AI to help you write." Sharp: "Our differentiation is the policy, refined by the person it serves, so a suggestion sounds like them. The capture, the storage and the sending all stay standard." The sharp version is specific enough that two people would invest in the same custom work. The vague one is not. Working draft: Real advantage: [what the real advantage is] Where the user feels it: [where the user feels that advantage] What stays standard: [what should remain commodity or standard] Task: Decide whether this real differentiation is specific enough that two people would invest in the same custom work. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. 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 point to the advantage, show where the user feels it and say what should remain standard Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Knowing which part is genuinely yours decides where the careful building goes and where good enough will do. That is [Ways to build it with AI](https://vibe2value.com/ways-to-build-it-with-ai/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card Everyone can boil pasta. The reason people come to your table is the sauce, the one handed down with a spice blend nobody else quite gets right. Buying fancier plates and a new tablecloth makes the meal look different, but it tastes the same as every other table in town. Your real differentiation is that sauce. Name the one thing the user genuinely cannot get from the obvious alternative, the place it shows up and what should stay plain and standard. Put your effort into the sauce and not the tablecloth, so people can actually taste the difference and not just see it. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means Real differentiation is not a pile of features. It is the specific advantage the user cannot easily get from the obvious alternative. Until you can name one real advantage, one place it shows up and one thing that should stay standard, the product will blur. AI can help generate ideas, but it cannot choose what deserves custom effort. ## Make the real differentiation concrete Compare the broad version with a version you can actually test. - **Too vague:** Our differentiation is that we use AI to help you write. - **Concrete enough to test:** Our differentiation is the policy, refined by the person it serves, so a suggestion sounds like them. The capture, the storage and the sending all stay standard. The second version lets two people invest in the same custom work from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). TABLE STAKES (everyone has)login and accountsan inboxan email digestYOUR EDGE (only you)suggestions shaped by thepolicy you refined yourself Most of what a product does is table stakes that everyone has. The real differentiation is the narrow thing only you do, and knowing exactly where it lives tells you where to spend effort and where to just match the standard. ## Check the real differentiation - **Pass:** You can point to the advantage, show where the user feels it and say what should remain standard. - **Fail:** If differentiation still sounds like AI-powered or better experience in general, it is not clear enough yet. Do not move into roadmap, feature or platform work until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/build/differentiation.md` written and sharpened: the real differentiation pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `differentiation.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/build/differentiation.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Confusing extra features with real differentiation, which adds complexity while the core value stays unclear to users. - **Mitigation:** Choose one user-critical signal of differentiation and use it to accept or reject every build decision. ## Key takeaway Do not move forward until you can point to the advantage, show where the user feels it and say what should remain standard. ## How to document your real differentiation Write your real differentiation up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Real differentiation ## Answer Real advantage: [what the real advantage is] Where the user feels it: [where the user feels that advantage] What stays standard: [what should remain commodity or standard] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Real advantage: The handed-down sauce with a spice blend nobody gets right Where the user feels it: The first taste at the table What stays standard: The boiled pasta, the plates and the tablecloth ## Evidence Guests always ask about the sauce and never about the pasta or the plates, which are the same as anywhere. ## Decision Optimising the sauce that nobody else gets right. Saying no to spending effort on the pasta, plates and table. ## Risk I might polish the standard parts and neglect the sauce. Protect the time and care the sauce needs first. ## AI instruction The real advantage is the handed-down sauce with its spice blend, felt at the first taste. Keep the pasta, plates and tablecloth standard and put the care into the sauce. ``` ### 2.2.3 - Understanding the Shape of the System Before You Change It URL: https://vibe2value.com/understanding-the-shape-of-the-system/ Last updated: 2026-09-07T05:58:20.000Z ## System shape Is the system shape clear? ## The call Map the boundaries before building across them. Otherwise AI helps you connect parts that should have stayed separate. ## Sharpen the system shape with AI This is a Build idea, so there are two AI moves: first **Sharpen** the system shape using the prompt below, then **Build it with AI**, vibeCoding the thinnest working code that tests the decision. This idea also calls for **Build an AI agent**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real system shape and keep the instruction exactly as visible here. It helps you put your build/system-shape.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this system shape is clear enough before you move forward. Constraint: The system shape must be specific enough that two people would draw the same core boundaries from it. Example of the standard: Vague: "The system has a few parts that connect together." Sharp: "A mailbox, a log store, a skill runner and a digest. The registered skill belongs to the user rather than to us, so we own the run and they own the policy." The sharp version is specific enough that two people would draw the same core boundaries. The vague one is not. Working draft: Part or boundary: [which part owns what] Dependency or handoff: [where the important dependency or handoff happens] Ownership boundary: [what each part should not own] Task: Decide whether this system shape is specific enough that two people would draw the same core boundaries. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state which part owns what, what each part depends on and where the important handoff happens? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Understanding a system before you change it is exactly what a planning pass is for, with nothing committed while you look. That is [Plan first](https://vibe2value.com/plan-first/), one of the ways to build it with AI. ## The same idea on a recipe card Before cooking a big meal you picture the kitchen: which station preps, which one cooks, what gets handed from the board to the pan to the plate. Move the chopping board somewhere random without knowing what depends on it and the whole flow jams just as the orders pile up. Understanding the shape of the system is that mental map of the kitchen. Name the boundaries between the parts, what depends on what and where one part hands off to the next, before you start moving things. See the layout first and your change helps, the way a cook who knows the kitchen does not knock the sauce off the stove reaching for a spoon. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means System shape is not an abstract architecture diagram. It is the practical boundary between parts, the dependencies they carry and the handoffs that matter. Until you can name one boundary, one dependency and one handoff between parts, design decisions stay fuzzy. AI can help sketch architecture, but it cannot decide which boundary reduces risk in your system. ## Make the system shape concrete Compare the broad version with a version you can actually test. - **Too vague:** The system has a few parts that connect together. - **Concrete enough to test:** A mailbox, a log store, a skill runner and a digest. The registered skill belongs to the user rather than to us, so we own the run and they own the policy. The second version lets two people draw the same core boundaries from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). A TANGLEyou cannot tell what touches whatmap the shapeA SHAPEInterfaceLogicDatayou can see what connects to what Understanding the shape of the system means turning the tangle in your head into a structure you can actually reason about. Once you can see the few parts and how they connect, you can tell what a change will touch before you make it. ## Check the system shape - **Pass:** You can say which part owns what, what each part depends on and where the important handoff happens. - **Fail:** If architecture still means a rough stack or a list of services, the system shape is not clear enough yet. Do not move into system design or implementation work until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/build/system-shape.md` written and sharpened: the system shape pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `system-shape.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/build/system-shape.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Letting system shape drift while features expand, which creates unclear ownership and fragile behaviour under load. - **Mitigation:** Define one boundary decision per change and validate it against a real user-critical flow before release. ## Key takeaway Do not move forward until you can say which part owns what, what each part depends on and where the important handoff happens. ## How to document your system shape Write your system shape up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # System shape ## Answer Part or boundary: [which part owns what] Dependency or handoff: [where the important dependency or handoff happens] Ownership boundary: [what each part should not own] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Part or boundary: The chopping board station Dependency or handoff: It hands prepped food to the pan, then to the plate Ownership boundary: The prep cook owns the board, the line cook owns the pan ## Evidence When the board and the pan were run by the same person under pressure, prep fell behind and the line stalled. ## Decision Optimising for clear handoffs between stations. Saying no to blurring who owns the board and who owns the pan. ## Risk A handoff can be missed if nobody owns the moment food leaves the board. Name the owner on each side. ## AI instruction Map the kitchen as stations: the board hands prepped food to the pan, then to the plate. Keep the prep cook owning the board and the line cook owning the pan, and respect the handoffs between them. ``` ### 2.2.2 - Buy vs Build Is a Strategy Choice, Not an Engineering One URL: https://vibe2value.com/buy-vs-build-is-a-strategy-choice/ Last updated: 2026-09-07T08:58:48.000Z ## Buy versus build decision Is this buy-vs-build choice improving the first user outcome? ## The call Buy means acquire, not pay. Build is what you write, buy is everything you don't. Make the call on where value lives, or AI helps you build what should have been acquired and rebuild what already works. ## Sharpen the buy versus build decision with AI This is a Build idea, so there are two AI moves: first **Sharpen** the buy versus build decision using the prompt below, then **Build it with AI**, vibeCoding the thinnest working code that tests the decision. This idea also calls for **Set AI up to help**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real buy versus build decision and keep the instruction exactly as visible here. It helps you put your build/buy-vs-build.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this buy versus build decision is clear enough before you move forward. Constraint: The buy versus build decision must be specific enough that two people would choose the same leverage point from it. Example of the standard: Vague: "We should decide whether to use an existing service or build it ourselves." Sharp: "Buy inbound email and delivery, because a mailbox was never the differentiation. Build the policy, because that is the part that makes a suggestion sound like the person it is for." The sharp version is specific enough that two people would choose the same leverage point. The vague one is not. Working draft: Decision area: [what the decision is about] Why buy or build: [why one side wins] Deciding constraint: [which constraint makes the call] Task: Decide whether this buy versus build decision is specific enough that two people would choose the same leverage point. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what the decision is about, why one side wins and which constraint makes the call? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Buying or building changes what you actually construct, so it sits with the decisions about how the build goes together. That is [Ways to build it with AI](https://vibe2value.com/ways-to-build-it-with-ai/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card A smart cook does not make everything from scratch. You buy the puff pastry and the stock, then pour your real effort into the filling that makes the pie yours. Milling your own flour to save a few pence is effort spent where no guest will ever taste the difference. Buy versus build is that same call. Buy the standard parts that are good enough off the shelf and build only where your effort actually shows up for the user. Decide it on where the value lives and not on what is fun to make, the way a cook spends their time on the filling and not on the flour. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means Buy versus build is not a tooling preference and buy does not mean paying a vendor. Build is the code you write yourself. Buy is everything you could acquire instead: a managed service, a platform primitive, an open-source library, a framework you install from a public package registry. It is a strategy call about where your effort creates advantage and where it does not. Until you can name one decision area, one reason to buy or build and one constraint that decides it, the discussion will loop. AI can help compare the options, but it cannot choose your leverage point. Two things make acquiring the strong default in AI-assisted building. A framework is bought judgment: you inherit decisions already made and tested, not just code. And you do not resend the tokens on what already works, so your build effort goes to the part that is actually yours. Acquired is not free. Open source and frameworks carry no invoice and still carry a cost: you own the patching, the maintenance and the adaptation, and you inherit a framework's opinions whether they fit or not. Weigh that cost like any other, it is just paid in time rather than on a bill. ## Make the buy versus build decision concrete Compare the broad version with a version you can actually test. - **Too vague:** We should decide whether to use an existing service or build it ourselves. - **Concrete enough to test:** Acquire inbound email and delivery because it is not where value lives. We weighed a managed mail service, an open-source relay and the platform's own primitive, then chose the managed one to protect the deadline. Build the policy because that is where the product makes a unique decision for the user. The second version lets two people choose the same leverage point from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). A capabilityyou needIs it yourdifferentiation?yesnoBuild itBuy or reuse Buy versus build is not about cost, it is about focus. Build the one capability that is your real differentiation, and buy or reuse everything that is not, so your effort goes where it actually sets you apart. ## Check the buy versus build decision - **Pass:** You can say what the decision is about, why one side wins and which constraint makes the call. - **Fail:** If the discussion still lives at the level of flexibility or control in general, it is not specific enough yet. Do not move into vendor selection or implementation work until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/build/buy-vs-build.md` written and sharpened: the buy versus build decision pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `buy-vs-build.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/build/buy-vs-build.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Treating buy vs build as a technical argument and missing the user outcome, which leads to slow delivery and avoidable complexity. - **Mitigation:** Define one user-impact metric first and use it to score both options before deciding. ## Key takeaway Do not move forward until you can say what the decision is about, why one side wins and which constraint makes the call. ## How to document your buy versus build decision Write your buy versus build decision up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Buy versus build decision ## Answer Decision area: [what the decision is about] Why buy or build: [why one side wins] Deciding constraint: [which constraint makes the call] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Decision area: The puff pastry and the stock Why buy or build: Buy them, they are good enough off the shelf Deciding constraint: Put your effort into the filling that makes the pie yours ## Evidence The shop puff pastry and stock have tested as good as my homemade ones, and making them ate hours I needed for the filling. ## Decision Optimising effort into the filling that makes the pie mine. Saying no to making pastry and stock from scratch. ## Risk A weak pastry or stock could let the pie down. Buy good ones and taste them before committing. ## AI instruction Buy the puff pastry and the stock, they are good enough off the shelf. Spend the saved effort on the filling, which is what makes this pie ours. ``` ### 2.2.1 - The Routine Work Checklist Nobody Talks About URL: https://vibe2value.com/the-routine-work-checklist-nobody-talks-about/ Last updated: 2026-09-07T08:58:43.000Z ## Routine work checklist Is this routine work clear or drifting into unnecessary custom build? ## The call Name the routine work before it hides inside custom effort. Otherwise AI helps you over-engineer tasks that should stay standard. ## Sharpen the routine work checklist with AI This is a Build idea, so there are two AI moves: first **Sharpen** the routine work checklist using the prompt below, then **Build it with AI**, vibeCoding the thinnest working code that tests the decision. This idea also calls for **Set AI up to help**. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real routine work checklist and keep the instruction exactly as visible here. It helps you put your build/routine-checklist.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this routine work checklist is clear enough before you move forward. Constraint: The routine work checklist must be specific enough that two people would do the same checks from it. Example of the standard: Vague: "We will sort out the routine operational work later." Sharp: "On each plan frequency the service runs the digest unattended. It is done when every active sender has been emailed or explicitly skipped." The sharp version is specific enough that two people would do the same checks. The vague one is not. Working draft: Recurring task: [what repeats] Owner: [who owns it] Done condition: [what done looks like each time] Task: Decide whether this routine work checklist is specific enough that two people would do the same checks. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what repeats, who owns it and what done looks like each time? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Routine work you repeat on every project is the clearest case there is for packaging the job once instead of explaining it from scratch every time. That is [Custom slash commands and skills](https://vibe2value.com/custom-slash-commands-and-skills/), one of the ways to set AI up to help. ## The same idea on a recipe card Every kitchen runs on dull, repeated jobs: wiping down, prepping, restocking the shelves. Nobody writes a blog post about washing a pan, and you certainly do not invent a clever new way to do it each night. You just do it reliably, because the kitchen quietly grinds to a halt when it is skipped. Your routine work checklist is that unglamorous kitchen routine. Name the jobs that have to happen every time, who does each one and what done looks like, then keep them standard. Save your invention for the dish and not for reinventing the washing up, the way a good kitchen keeps the basics boring so the food can be interesting. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means Routine work is not background noise. It is the repeatable work that keeps the core path reliable once people start using it. Until you can name one recurring task, one owner and one done condition, routine work stays invisible and under-owned. AI can help automate pieces of it, but it cannot decide what must be checked every time. ## Make the routine work checklist concrete Compare the broad version with a version you can actually test. - **Too vague:** We will sort out the routine operational work later. - **Concrete enough to test:** On each plan frequency the service runs the digest unattended. It is done when every active sender has been emailed or explicitly skipped. The second version lets two people do the same checks from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). Every timethe schedule fires1 · run the digest per sender2 · check nothing else broke3 · retry anything that bounced4 · skip senders with nothing new5 · note it in the log The routine work nobody talks about is the loop that runs every time something changes. Writing it as a fixed checklist around the cycle turns invisible, error-prone busywork into the same handful of steps anyone can run the same way each time. ## Check the routine work checklist - **Pass:** You can say what repeats, who owns it and what done looks like each time. - **Fail:** If routine work still means all the boring parts, the checklist is not clear enough yet. Do not move into scale, release or automation work until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/build/routine-checklist.md` written and sharpened: the routine work checklist pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `routine-checklist.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/build/routine-checklist.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Treating routine work as strategic by default, which increases complexity while the core user outcome stays unchanged. - **Mitigation:** Require one direct user-impact signal before moving any routine item into custom implementation. ## Key takeaway Do not move forward until you can say what repeats, who owns it and what done looks like each time. ## How to document your routine work checklist Write your routine work checklist up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Routine work checklist ## Answer Recurring task: [what repeats] Owner: [who owns it] Done condition: [what done looks like each time] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Recurring task: Wipe down, prep and restock the shelves Owner: Whoever closes the kitchen Done condition: The station is clean and stocked for the next service ## Evidence On nights the closing wipe-down was skipped the next service started slow and short of prepped stock. ## Decision Optimising for a station that is ready for the next service. Saying no to leaving we will sort it tomorrow jobs. ## Risk The checklist can be ticked without the work being done. Define done as clean and stocked, checked by the next cook. ## AI instruction The routine work is wiping down, prepping and restocking at close. It is done when the station is clean and stocked for the next service, and whoever closes owns it. ``` ### 2.1.3 - What This Build Is Meant to Teach You, Not Just to Ship URL: https://vibe2value.com/what-this-build-is-meant-to-teach-you/ Last updated: 2026-09-07T05:58:16.000Z ## Learning goal Is this build teaching one clear lesson? ## The call Name the lesson before you build. Otherwise AI helps you ship fast without learning anything you can act on. ## Sharpen the learning goal with AI This is a Build idea, so there are two AI moves: first **Sharpen** the learning goal using the prompt below, then **Build it with AI**, vibeCoding the thinnest working code that tests the decision. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real learning goal and keep the instruction exactly as visible here. It helps you put your build/learning-goal.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this learning goal is clear enough before you move forward. Constraint: The learning goal must be specific enough that two people would collect the same evidence from it. Example of the standard: Vague: "This build should help us learn what people want." Sharp: "This build should tell us whether the input people have is their week rather than a list of topics: do they send things that happened, or ask us for subjects?" The sharp version is specific enough that two people would collect the same evidence. The vague one is not. Working draft: Hypothesis: [what you believe] Question: [what the build needs to answer] Signal: [what signal will prove or weaken that belief] Task: Decide whether this learning goal is specific enough that two people would collect the same evidence. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what you believe, what the build needs to answer and what signal will prove or weaken that belief? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. A build meant to teach you something wants building differently from one meant to last. That is [Ways to build it with AI](https://vibe2value.com/ways-to-build-it-with-ai/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card Picture trying a new recipe to learn one specific thing. "I am making this curry to find out whether the kids will eat more vegetables when they are spiced" is a question the dinner can actually answer. "I felt like cooking something different" teaches you nothing you can use next week. Your learning goal is that one question on the plate. Before you build, name the thing you are trying to find out, the build that tests it and the sign that answers it. A meal cooked to answer a question teaches you something, the same as a build aimed at one lesson rather than just more output. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A learning goal is not a loose hope that the build will teach something. It is the exact question the build is meant to answer. Until you can name one hypothesis, one question and one signal that answers it, the build will collect noise instead of evidence. AI can help generate experiments, but it cannot decide what counts as learning. ## Make the learning goal concrete Compare the broad version with a version you can actually test. - **Too vague:** This build should help us learn what people want. - **Concrete enough to test:** This build should tell us whether the input people have is their week rather than a list of topics: do they send things that happened, or ask us for subjects? The second version lets two people collect the same evidence from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). We believe...a hypothesisA thin testthe buildtrue?YesNo A build is not just work, it is an experiment with a learning goal: you believe something, you build the thinnest test of it, and you read the result. Naming the belief up front is what turns building into learning. ## Check the learning goal - **Pass:** You can say what you believe, what the build needs to answer and what signal will prove or weaken that belief. - **Fail:** If the build is still meant to teach something useful without a clear question, the learning goal is not sharp enough yet. Do not move into implementation or prototype work until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/build/learning-goal.md` written and sharpened: the learning goal pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `learning-goal.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/build/learning-goal.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Expanding the build before the lesson is clear, which creates output but hides whether anyone learned anything useful. - **Mitigation:** Define one learning signal for each iteration and pause new scope when that signal is still unclear. ## Key takeaway Do not move forward until you can say what you believe, what the build needs to answer and what signal will prove or weaken that belief. ## How to document your learning goal Write your learning goal up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Learning goal ## Answer Hypothesis: [what you believe] Question: [what the build needs to answer] Signal: [what signal will prove or weaken that belief] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Hypothesis: The kids eat more vegetables when they are spiced Question: Will they eat more of this curry than plain veg Signal: Their plates come back empty ## Evidence The kids left plain vegetables untouched last week but cleared a mildly spiced dish the week before. ## Decision Optimising for learning whether spice gets them eating veg. Saying no to changing three things at once and losing the lesson. ## Risk They might eat it for a reason other than the spice, like hunger. Compare it against plain veg on a similar night. ## AI instruction This dish is a test of whether the kids eat more vegetables when spiced. Watch whether their plates come back empty compared with plain veg, and change one thing at a time. ``` ### 2.1.2 - Where the User First Feels Value Is Where to Start Building URL: https://vibe2value.com/where-the-user-first-feels-value/ Last updated: 2026-09-07T08:58:39.000Z ## First value moment Where do users first feel real value in this flow? ## The call Find the first moment value lands. Otherwise AI helps you build a longer path to a reward users never reach. ## Sharpen the first value moment with AI This is a Build idea, so there are two AI moves: first **Sharpen** the first value moment using the prompt below, then **Build it with AI**, vibeCoding the thinnest working code that tests the decision. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real first value moment and keep the instruction exactly as visible here. It helps you put your build/first-value-moment.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this first value moment is clear enough before you move forward. Constraint: The first value moment must be specific enough that two people would optimize the same step from it. Example of the standard: Vague: "People feel value once they start using it." Sharp: "Someone who has sent a few lines feels value when the first digest names something they had already forgotten. The step right before it is a week of captures they never looked at." The sharp version is specific enough that two people would optimize the same step. The vague one is not. Working draft: User: [who first feels value] First value moment: [the first moment they feel relief or progress] Step right before it: [the step immediately before that moment] Task: Decide whether this first value moment is specific enough that two people would optimize the same step. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. 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 point to the moment the user first feels relief or progress and the step immediately before it Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Starting where the value first lands changes the order you build in, which is a build-approach decision. That is [Ways to build it with AI](https://vibe2value.com/ways-to-build-it-with-ai/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card Think of the first moment a meal feels worth it: the smell of garlic hitting the pan, or the first warm bite. That is the point where everyone is glad they waited. A meal whose only reward comes after an hour of prep and a sink full of washing up loses people long before they taste anything. Your first value moment is that first good smell. Find the earliest point the user feels real reward and build the short path that gets them there first. Do not make them earn it through a long setup, the way a good cook gets something delicious going early so the kitchen smells like dinner within minutes. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means The first value moment is not the full product promise. It is the earliest point where the user can feel that this was worth starting. Until you can name one user, one first value moment and the step that gets them there, the flow will stay vague. AI can help shorten the path, but it cannot decide where value begins. ## Make the first value moment concrete Compare the broad version with a version you can actually test. - **Too vague:** People feel value once they start using it. - **Concrete enough to test:** Someone who has sent a few lines feels value when the first digest names something they had already forgotten. The step right before it is a week of captures they never looked at. The second version lets two people optimise the same step from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). arriveset upfirst valuethe aharepeat The first value moment is the exact point on the journey where the user first thinks "oh, that is useful". Find it and you know what to rush them toward, instead of making them earn the payoff through setup. ## Check the first value moment - **Pass:** You can point to the moment the user first feels relief or progress and the step immediately before it. - **Fail:** If value still means the product feels useful in general, it is not specific enough yet. Do not move into feature, onboarding or optimisation work until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/build/first-value-moment.md` written and sharpened: the first value moment pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `first-value-moment.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/build/first-value-moment.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Adding setup work before users experience value, which increases drop-off and weakens trust in the product. - **Mitigation:** Define one first-value signal and reject any change that delays that signal without clear user benefit. ## Key takeaway Do not move forward until you can point to the moment the user first feels relief or progress and the step immediately before it. ## How to document your first value moment Write your first value moment up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # First value moment ## Answer User: [who first feels value] First value moment: [the first moment they feel relief or progress] Step right before it: [the step immediately before that moment] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer User: A hungry guest waiting for dinner First value moment: The smell of garlic hitting the pan Step right before it: The pan gets hot and the garlic goes in ## Evidence Guests always perk up the moment the garlic hits the pan, well before anything is on a plate. ## Decision Optimising for that first hit of smell early. Saying no to prep that delays getting something aromatic going. ## Risk Rushing the garlic in on a cold pan gives no smell. Get the pan properly hot first. ## AI instruction The first value moment is the smell of garlic hitting a hot pan. Get to it early, and make sure the step right before it, heating the pan, is done well. ``` ### 2.1.1 - The Only Path Your Prototype Actually Needs to Walk URL: https://vibe2value.com/the-only-path-your-prototype-needs/ Last updated: 2026-09-07T08:58:37.000Z ## Prototype path Is this the only prototype path users need? ## The call Build one path first. Otherwise AI helps you prototype everything at once and you learn nothing clearly. ## Sharpen the prototype path with AI This is a Build idea, so there are two AI moves: first **Sharpen** the prototype path using the prompt below, then **Build it with AI**, vibeCoding the thinnest working code that tests the decision. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real prototype path and keep the instruction exactly as visible here. It helps you put your build/prototype-path.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this prototype path is clear enough before you move forward. Constraint: The prototype path must be specific enough that two people would build the same thin test from it. Example of the standard: Vague: "Test whether people like the idea." Sharp: "Learning goal: whether anyone will email a thought to an address. Test path: one mailbox, a log file and a skill run by hand. Proof signal: a second email arrives without a reminder." The sharp version is specific enough that two people would build the same test. The vague one is not. Working draft: Learning goal: [what the prototype is meant to teach] Test path: [which path will test it] Proof signal: [what signal counts as proof] Task: Decide whether this prototype path is specific enough that two people would build the same thin test. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what the prototype teaches, which path tests it and what signal counts as proof? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Deciding how thin the first build can be is a choice about how to build it, not about what it is. That is [Ways to build it with AI](https://vibe2value.com/ways-to-build-it-with-ai/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card Before cooking a new dish for a dinner party you make one small test portion. You do not cook the whole five-course meal just to find out whether the sauce works. One trial spoonful answers the only question that matters right now, and it costs you almost nothing if it fails. Your prototype path is that test portion. Build the thinnest version that answers your one question, not a small version of the whole product. Name the question, the single path that tests it and the sign it passed, the way one taste of the sauce tells you whether to cook the full batch. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A prototype path is not a mini product. It is the thinnest route that can answer the question you actually have. Until you can name one learning goal, one path to test and one signal that would prove it, the prototype will keep growing. AI can help build quickly, but it cannot protect a prototype from drift. ## Make the prototype path concrete Compare the broad version with a version you can actually test. - **Too vague:** The prototype should show the main features. - **Concrete enough to test:** The prototype only needs to show whether someone will email a thought to an address, and then come back a second time without being reminded. The second version lets two people build the same thin test from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). start✕✕what itteaches A prototype only needs one path, the thin line from start to the single thing it is meant to teach you. Every tempting side route gets cut, because the prototype exists to answer one question, not to be the product. ## Check the prototype path - **Pass:** You can say what the prototype is meant to teach, which path will test it and what signal counts as proof. - **Fail:** If the prototype still sounds like a lighter version of the full product, the path is not tight enough yet. Do not move into prototype build or polish work until this passes. ## What you'll walk away with This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own `knowledge-base/build/prototype-path.md` written and sharpened: the prototype path pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call. ## Write it down Your `prototype-path.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/build/prototype-path.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Expanding into multiple prototype paths too early, which dilutes learning and makes user feedback contradictory. - **Mitigation:** Define one path-level success signal and reject new branches until that signal is stable. ## Key takeaway Do not move forward until you can say what the prototype is meant to teach, which path will test it and what signal counts as proof. ## How to document your prototype path Write your prototype path up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Prototype path ## Answer Learning goal: [what the prototype is meant to teach] Test path: [which path will test it] Proof signal: [what signal counts as proof] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Learning goal: Whether the sauce works Test path: Make one small test portion, not the whole meal Proof signal: The trial spoonful tastes right ## Evidence Every time I have committed a full batch to an untested sauce I have wasted it, so a small trial first pays off. ## Decision Optimising for learning whether the sauce works. Saying no to cooking the whole meal before I know. ## Risk A tiny portion might not behave like the full pan. Make it big enough to taste properly, small enough to throw away. ## AI instruction The prototype is one small test portion to learn whether the sauce works. Do not scale up to the full meal until the trial spoonful tastes right. ``` ### 1.3.3 - Describe One Main Path First, Then Ignore Everything Else URL: https://vibe2value.com/describe-one-main-path-then-ignore-the-rest/ Last updated: 2026-09-07T05:58:12.000Z The earlier files describe what the product is, what pain it solves, what it promises and what it is and is not in scope to do. `path.md` is the how: the specific sequence of steps a user takes from the trigger to the promised outcome. The earlier files name the destination; path.md names the route. ## Main path Is the main path clear enough to ignore the rest? ## The call Describe one path first. Otherwise AI generates alternatives that split attention before the core flow is proven. ## Sharpen the main path with AI This is a Shape idea, so the AI move is to **Sharpen** the main path: run your draft through the prompt below until two people would make the same decision from it. Build and Launch ideas have their own AI moves, building and running the code. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real main path and keep the instruction exactly as visible here. It helps you put your path.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this main path is clear enough before you move forward. Constraint: The main path must be specific enough that two people would design the same flow from it. Example of the standard: Vague: "People can use it in a few different ways." Sharp: "A thought lands and the person with the material emails one line. It goes into their log, and on the rhythm they chose it emails back what is worth saying." The sharp version is specific enough that two people would design the same flow. The vague one is not. Working draft: User: [who the path is for] Trigger: [what starts the flow] Path to outcome: [the exact steps that lead to the outcome] Task: Decide whether this main path is specific enough that two people would design the same flow. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. 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 describe the user, what starts the flow and the exact steps that lead to the outcome Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Choosing one path and deliberately ignoring the rest is a narrowing. Narrowing is what getting to a sharp answer is. That is [Ways to get to a sharp answer](https://vibe2value.com/ways-to-get-to-a-sharp-answer/), one of the [six ways to work with AI](https://vibe2value.com/working-with-ai/). ## The same idea on a recipe card Picture the numbered steps of a recipe. "Chop, then fry, then simmer, then serve" is one clear route from raw ingredients to a plated meal, and a beginner can follow it. A card that says "you could roast or fry or boil this, in any order you like" leaves the cook frozen at step one. Your main path is those steps in order. Pick one user, one starting point and one route to the outcome, and write that route down before mapping every other way through. A cook needs one path that works, not a menu of maybes, and so does your first build. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A main path is not the average journey. It is the single route that matters most for the user and the decision in front of you. Until you can point to one user, one trigger and one path to the outcome, attention will keep splitting. AI can help map flows, but it cannot decide which one deserves focus first. ## Make the main path concrete Compare the broad version with a version you can actually test. - **Too vague:** People can use it in a few different ways. - **Concrete enough to test:** A thought lands and the person with the material emails one line. It goes into their log, and on the rhythm they chose it emails back what is worth saying. The second version lets two people design the same flow from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). startside path (later)side path (later)done The main path is the one route through the product you will describe end to end. The side branches are real, but you grey them out for now, because a clear single path beats three half-drawn ones. ## Check the main path - **Pass:** You can describe the user, what starts the flow and the exact steps that lead to the outcome. - **Fail:** If the path still reads like a menu of possibilities instead of one route, it is not focused enough yet. Do not move into feature, navigation or prototype work until this passes. ## What you'll walk away with You put this into practice with the prompt above. You'll come out with a main path clear enough that every later decision flows from it. UI choices, what screens exist, what waits for version two and the prompts you write to AI all inherit that clarity. You write the main path before you build any screen, so every UI decision and AI prompt is anchored against one concrete sequence of steps. The file is called `path.md` because that is what it is: the one path through the product that has to work end to end. The post calls it a "main path" because the act here is choosing one path and consciously ignoring the others. ## Write it down Your `path.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/shape/path.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Adding side paths too early, which dilutes focus and makes feedback contradictory. - **Mitigation:** Define one path-level success signal and decline extra routes until that signal is stable. ## Key takeaway Do not move forward until you can describe the user, what starts the flow and the exact steps that lead to the outcome. ## How to document your main path Write your main path up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Main path ## Answer User: [who the path is for] Trigger: [what starts the flow] Path to outcome: [the exact steps that lead to the outcome] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer User: A beginner cook Trigger: They have the raw ingredients and want to eat Path to outcome: Chop, then fry, then simmer, then serve ## Evidence A beginner following this the first time managed it by sticking to one straight run of steps with no detours. ## Decision Optimising for one clear path from raw ingredients to a plate. Saying no to variations, substitutions and side dishes for now. ## Risk They might get stuck if a step assumes knowledge they do not have. Keep each step to a single plain action. ## AI instruction The one main path is chop, fry, simmer, serve, for a beginner with the ingredients ready. Ignore variations and side dishes until this path works end to end. ``` ### 1.3.2 - What This Will Not Do (On Purpose) Is Half the Decision URL: https://vibe2value.com/what-this-will-not-do-on-purpose/ Last updated: 2026-09-07T05:55:17.000Z `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. ## Sharpen the scope boundary with AI This is a Shape idea, so the AI move is to **Sharpen** the scope boundary: run your draft through the prompt below until two people would make the same decision from it. Build and Launch ideas have their own AI moves, building and running the code. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real scope boundary and keep the instruction exactly as visible here. It helps you put your scope.md together by refining your three lines until two people would make the same product decision from them. ``` 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. Example of the standard: Vague: "Version one will stay focused and not do too much." Sharp: "Version one takes an email, keeps a log for each sender and returns a digest of what is worth writing. It will not draft the post, schedule it or show you a dashboard, because the last log died when using it became a separate job." The sharp version is specific enough that two people would cut the same feature. The vague one is not. 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 that two people would cut the same feature. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what stays in, what stays out and why the cut protects the core path? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. An exclusion is only worth deciding if it keeps holding later, so it belongs somewhere the AI reads every time rather than in one conversation it will forget. That is [Project memory and rules](https://vibe2value.com/project-memory-and-rules/), one of the ways to set AI up to help. ## The same idea on a recipe card Think of a host deciding what not to cook. "No starter and no homemade dessert tonight so the main course is genuinely good" is a deliberate cut that protects the meal. Try to cook five courses to impress and each one suffers, the kitchen overflows and you never actually sit down with your guests. Your scope boundary is that list of what you are leaving off the menu on purpose. Say what is in, what is out and why each cut makes the main thing stronger. Decide it before the pressure to add "just one more dish" makes the choice for you, the way a good host commits to one course done well. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means 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 takes an email, keeps a log for each sender and returns a digest of what is worth writing. It will not draft the post, schedule it or show you a dashboard, because the last log died when using it became a separate job. The second version lets two people cut the same feature from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). IN SCOPEemail in, a log per senderone digest, on your rhythmOUT, ON PURPOSEdrafting the post for youa dashboard A scope boundary is a line you draw on purpose. What is inside, you will build; what is outside, you are choosing not to do yet, and saying so out loud is what stops version one from quietly sprawling. ## 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 You put this into practice with the prompt above. 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. 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. ## Write it down Your `scope.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/shape/scope.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## 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. ## How to document your scope boundary Write your scope boundary up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Scope boundary ## Answer Keep in: [what stays in scope] Leave out: [what stays out] Why the cut helps: [why the cut protects the core path] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Keep in: The main course Leave out: The starter and the homemade dessert Why the cut helps: The main course is genuinely good instead of three rushed ones ## Evidence The last time I attempted three courses the main came out rushed and lukewarm while I plated the dessert. ## Decision Optimising for one genuinely good main course. Saying no to a starter and a homemade dessert this time. ## Risk Guests might expect a full three courses. If that matters, buy a simple dessert rather than making one. ## AI instruction The scope is the main course only, on purpose. Leave out the starter and the homemade dessert so the main is genuinely good. ``` ### 1.3.1 - The One Outcome That Makes This Build Worth Doing in the First Place URL: https://vibe2value.com/the-one-outcome-that-makes-this-worth-doing/ Last updated: 2026-09-07T05:58:10.000Z The earlier files describe the product (`user.md`, `problem.md`, `promise.md`, `positioning.md`) and what shipping version one means (`success.md`, `risks.md`). `goal.md` is the one outcome that makes the whole build worth doing in the first place: the change in the user's world you are chasing. success.md tells you when version one is done; goal.md tells you why version one was worth starting. ## Main outcome Is this outcome clear enough to guide every decision? ## The call Choose one outcome first. Otherwise AI generates options that pull the product in multiple directions at once. ## Sharpen the main outcome with AI This is a Shape idea, so the AI move is to **Sharpen** the main outcome: run your draft through the prompt below until two people would make the same decision from it. Build and Launch ideas have their own AI moves, building and running the code. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real main outcome and keep the instruction exactly as visible here. It helps you put your goal.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this main outcome is clear enough before you move forward. Constraint: The main outcome must be specific enough that two people would prioritize the same work from it. Example of the standard: Vague: "This creates more value for people who write." Sharp: "They publish more often without trying harder. The loss was never the writing, it was the forgetting, and the forgetting is silent. The signal is that they still email it in a week they published nothing." The sharp version is specific enough that two people would prioritize the same work. The vague one is not. Working draft: User outcome: [what changes for the user] Why it matters: [why that change matters] Proof signal: [what signal will show it is real] Task: Decide whether this main outcome is specific enough that two people would prioritize the same work. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what changes for the user, why that change matters and what signal will show it is real? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Going from several plausible outcomes to the single one that matters is the vague-to-sharp move itself. That is [Then sharpen](https://vibe2value.com/then-sharpen/), one of the ways to get to a sharp answer. ## The same idea on a recipe card Ask why you are cooking this particular meal at all. "To give my parents a proper sit-down dinner on their anniversary" is a reason worth the effort, and it quietly decides the menu, the table and the timing. If the only honest answer is "we needed to eat", you would order a takeaway and save yourself the work. Your main outcome is that reason for cooking. Name the one change in the user world you are chasing, why it matters and the sign you will know it happened. It is not the same as the dish being done, it is why the dinner was worth starting, the thing every other choice quietly serves. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A main outcome is not a broad aspiration. It is the one result that justifies the work if it actually happens. Until you can point to one user outcome, one reason it matters and one signal that proves it happened, the work is still spread too wide. AI can help explore options, but it cannot choose what matters most. ## Make the main outcome concrete Compare the broad version with a version you can actually test. - **Too vague:** This creates more value for people who write. - **Concrete enough to test:** They publish more often without trying harder. The loss was never the writing, it was the forgetting, and the forgetting is silent. The signal is that they still email it in a week they published nothing. The second version lets two people prioritise the same work from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). many nice-to-havesThe one outcomethat makes it worth doingpick the one that matters Plenty of outcomes would be nice. The main outcome is the single one that makes the whole effort worth it, and naming it tells you what to protect when everything else competes for your time. ## Check the main outcome - **Pass:** You can say what changes for the user, why that change matters and what signal will show it is real. - **Fail:** If the outcome still sounds like value, impact or improvement without a concrete result, it is not clear enough yet. Do not move into roadmap, feature or build work until this passes. ## What you'll walk away with You put this into practice with the prompt above. You'll come out with a main outcome clear enough that every later decision flows from it. Scope, priorities, what you cut and the prompts you write to AI all inherit that clarity. You write the goal before you commit any scope, so every later trade-off is measured against the change you are actually trying to make in the user's world. The file is called `goal.md` (not outcome.md) because the runner already inserts an "Outcome" heading at the top of every framework post; one short noun keeps the two distinct. The post calls it a "main outcome" because that is the role the goal plays here: the one user-facing change that justifies the whole build. ## Write it down Your `goal.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/shape/goal.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Letting multiple outcomes compete at once, which creates conflicting priorities and slows meaningful progress. - **Mitigation:** Define one measurable outcome signal and defer requests that do not improve that signal. ## Key takeaway Do not move forward until you can say what changes for the user, why that change matters and what signal will show it is real. ## How to document your main outcome Write your main outcome up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Main outcome ## Answer User outcome: [what changes for the user] Why it matters: [why that change matters] Proof signal: [what signal will show it is real] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer User outcome: My parents get a proper sit-down dinner Why it matters: It is their anniversary and worth the effort Proof signal: They stay at the table long after the plates are clear ## Evidence My parents rarely get a proper sit-down meal, and last time they lingered for an hour once one was in front of them. ## Decision Optimising for a relaxed dinner they linger over. Saying no to anything that rushes them or turns it into a show. ## Risk I might pour effort into the food and forget the setting that makes them stay. Watch whether they relax, not just eat. ## AI instruction The outcome that matters is my parents enjoying a proper sit-down anniversary dinner. Judge every choice by whether it helps them settle and stay at the table. ``` ### 1.2.3 - The Risks You're Avoiding Naming Are the Ones That Bite You URL: https://vibe2value.com/the-risks-youre-avoiding-naming/ Last updated: 2026-09-07T08:58:35.000Z The earlier files describe what we want to happen: who the user is, what pain we are solving, what we promise, how we explain it, what success looks like. `risks.md` names what could go wrong on the way: the specific failures worth preparing for now. The earlier files are the plan; risks.md is the audit of where the plan can break. ## Named risk Are the key risks named before they hit users? ## The call Name the risks early. Otherwise AI helps you move faster toward a failure you have not prepared for. ## Sharpen the named risk with AI This is a Shape idea, so the AI move is to **Sharpen** the named risk: run your draft through the prompt below until two people would make the same decision from it. Build and Launch ideas have their own AI moves, building and running the code. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real named risk and keep the instruction exactly as visible here. It helps you put your risks.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this named risk is clear enough before you move forward. Constraint: The named risk must be specific enough that two people would prepare for the same failure from it. Example of the standard: Vague: "There are some risks around privacy." Sharp: "A digest quotes one person's log to another. Everyone who trusted it with private thinking is affected, so each sender gets their own log and replies only ever go back to the address they came from." The sharp version is specific enough that two people would prepare for the same failure. The vague one is not. Working draft: Likely failure: [what might fail] Affected user or workflow: [who or what it would affect] Mitigation: [what action reduces the damage] Task: Decide whether this named risk is specific enough that two people would prepare for the same failure. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what might fail, who or what it would affect and what action will reduce the damage? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. The risks you are avoiding are the ones you will never volunteer, so this wants a prompt that interrogates rather than one that answers. That is [Interview me](https://vibe2value.com/interview-me/), one of the ways to get to a sharp answer. ## The same idea on a recipe card Picture cooking for guests and thinking ahead to what could ruin it. "The chicken might still be pink when everyone sits down and someone could get sick" names the failure, who it hits and how you would spot it. "It will probably be fine" names nothing, so you only find out when a guest pushes the plate away. Your named risks are that bit of thinking ahead. For each one say what could go wrong, what would set it off and how you would catch it in time. Name them while you can still start the chicken earlier or check it with a thermometer, not once the guests are already eating. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A named risk is not general caution. It is a specific failure that could happen, who it would affect and what would make it visible. Until you can say what could fail, where it would show up and how you would respond, the plan is too soft. AI can help surface options, but it cannot own risk judgement. ## Make the named risk concrete Compare the broad version with a version you can actually test. - **Too vague:** There are some risks around privacy. - **Concrete enough to test:** A digest quotes one person's log to another. Everyone who trusted it with private thinking is affected, so each sender gets their own log and replies only ever go back to the address they came from. The second version lets two people prepare for the same failure from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). naming a risk moves it from hidden to handledNAMED, with a mitigationcontext could leak, so add a per-user checkname itempty results look brokencontext could leak between usersresults come back slowly The risks you avoid naming do not go away, they just stay below the line where you cannot plan for them. Naming one lifts it into view, where it gets a mitigation instead of becoming the surprise that takes you down at launch. ## Check the named risk - **Pass:** You can say what might fail, who or what it would affect and what action will reduce the damage. - **Fail:** If the risk still sounds like a vague concern instead of a concrete failure, it is not named well enough yet. Do not move into build, launch or rollout work until this passes. ## What you'll walk away with You put this into practice with the prompt above. You'll come out with named risks clear enough that every later decision flows from them. Mitigations, scope cuts, what you defensively avoid and the prompts you write to AI all inherit that clarity. You write each risk in advance so the team has a shared map of where version one could break, not a list assembled in the post-mortem. The file is called `risks.md` (plural) because over time you accumulate several named risks in one file as you discover them. The post calls each entry a "named risk" because the unit of work is one risk at a time, written in the same three-line shape so the file stays scannable. ## Write it down Your `risks.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/shape/risks.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Allowing unnamed risks to survive planning, which leads to weak decisions and rushed fixes after users are affected. - **Mitigation:**��Require one named risk, one assumption and one user-impact statement before each major build decision. ## Key takeaway Do not move forward until you can say what might fail, who or what it would affect and what action will reduce the damage. ## How to document your named risk Write your named risk up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Named risk ## Answer Likely failure: [what might fail] Affected user or workflow: [who or what it would affect] Mitigation: [what action reduces the damage] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Likely failure: The chicken is still pink when everyone sits down Affected user or workflow: The guests, who could get sick Mitigation: Check the thickest part with a thermometer before serving ## Evidence At the last dinner the chicken looked cooked but was pink at the bone, and I only noticed when I cut into it. ## Decision Optimising for safe chicken every time. Saying no to guessing doneness by colour or by time in the pan. ## Risk The thermometer can mislead if I probe the wrong spot. Check the thickest part, near the bone. ## AI instruction The risk is serving undercooked chicken that makes guests sick. Always check the thickest part with a thermometer before it leaves the kitchen. ``` ### 1.2.2 - What Does "Success" Actually Mean for the First Version You Ship? URL: https://vibe2value.com/what-does-success-mean-for-version-one/ Last updated: 2026-09-07T08:58:32.000Z The earlier files (`user.md`, `problem.md`, `promise.md`, `positioning.md`) describe the product: who it is for, what pain it solves, what it promises, how to explain it. `success.md` is the objective bar that tells you when version one is done. The earlier files frame what you are building; success.md is how you know when you have built enough to ship. ## Version one success definition Does version one success stay clear before users see it? ## The call Version one succeeds when one measurable user outcome is clear before scope expands. AI can produce fast drafts, but only you can decide what counts as enough. ## Sharpen the version one success definition with AI This is a Shape idea, so the AI move is to **Sharpen** the version one success definition: run your draft through the prompt below until two people would make the same decision from it. Build and Launch ideas have their own AI moves, building and running the code. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real version one success definition and keep the instruction exactly as visible here. It helps you put your success.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this version one success definition is clear enough before you move forward. Constraint: The version one success definition must be specific enough that two people would make the same go or no-go call from it. Example of the standard: Vague: "Users find the suggestions useful and keep coming back." Sharp: "Something gets published that came out of a suggestion. We count posts that trace back to a captured line, and version one works if there are four in the first month, at least one of them not mine." The sharp version is specific enough that two people would make the same go or no-go call. The vague one is not. Working draft: Outcome: [what has to happen] Metric: [how it will be measured] Threshold: [what number counts as enough] Task: Decide whether this version one success definition is specific enough that two people would make the same go or no-go call. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state what has to happen, how it will be measured and what number or threshold counts as enough? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Success only counts if two people could make the same go or no-go call from it, so this is the move that pins an ask to something testable. That is [Then sharpen](https://vibe2value.com/then-sharpen/), one of the ways to get to a sharp answer. ## The same idea on a recipe card Think of knowing when a cake is done. "Bake until ready" tells you nothing, so you either pull it out raw or leave it until it burns. "Golden on top and a skewer comes out clean" is a line anyone can check, so the cake comes out right every time. Your success definition for version one is that skewer test. Name the one outcome that has to be true, how you will check it and the line that counts as done. Agree it before users taste anything, the same way the skewer test is settled before the cake goes in and not argued over once it is on the table. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means Version one success is not a mood. It is a concrete line that says what has to be true for this release to count as enough. Until you can name one outcome, one proof metric and one threshold that counts as success, the work is still too open. AI can help model options, but it cannot decide what enough means. ## Make the version one success definition concrete Compare the broad version with a version you can actually test. - **Too vague:** Users find the suggestions useful and keep coming back. - **Concrete enough to test:** Something gets published that came out of a suggestion. We count posts that trace back to a captured line, and version one works if there are four in the first month, at least one of them not mine. The second version lets two people make the same go or no-go call from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). Version one is done when…"it works"no finish linea user completes one full searcha finish line Success for version one is a finish line you can stand on, a specific thing a user can do, like completing one full search. "It works" has no finish line, so you never know when you are done. ## Check the version one success definition - **Pass:** You can say what has to happen, how it will be measured and what number or threshold counts as enough. - **Fail:** If success still depends on words like traction, engagement or momentum without a threshold, it is not clear yet. Do not move into roadmap, launch or growth work until this passes. ## What you'll walk away with You put this into practice with the prompt above. You'll come out with a success definition clear enough that every later decision flows from it. Scope cuts, what you leave out, when you ship and the prompts you write to AI all inherit that clarity. You write the success definition before you start cutting scope, so you have one objective bar to make trade-offs against instead of "does this feel done?" The file is called `success.md` because that is what it is: the bar that version one has to clear. The post calls it a "version one success definition" because that is the role it plays at this stage, the moment you commit to what shipping actually means. ## Write it down Your `success.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/shape/success.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Treating activity as success, which hides whether users actually get value in version one. - **Mitigation:** Define one measurable success signal first and reject changes that do not improve that signal. ## Key takeaway Do not move forward until you can say what has to happen, how it will be measured and what number or threshold counts as enough. ## How to document your version one success definition Write your version one success definition up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Version one success definition ## Answer Outcome: [what has to happen] Metric: [how it will be measured] Threshold: [what number counts as enough] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Outcome: The cake comes out baked, not raw or burnt Metric: A skewer pushed into the middle Threshold: It comes out clean and the top is golden ## Evidence The last bake looked done on top but was raw in the middle, so looks done is not enough to trust. ## Decision Optimising for a reliable done test. Saying no to judging by colour alone or by the timer. ## Risk A clean skewer near the edge can still miss a raw centre. Test the middle, not the side. ## AI instruction Success for version one is a cake baked through, not raw or burnt. Judge it by a skewer in the centre coming out clean and a golden top, nothing fancier. ``` ### 1.2.1 - Can You Explain This in 30 Seconds Without Mentioning the Tech? URL: https://vibe2value.com/can-you-explain-this-in-30-seconds/ Last updated: 2026-09-07T05:58:06.000Z The earlier files (`user.md`, `problem.md`, `promise.md`) are written for the builder and the AI tools they prompt: who the user is, what pain we are solving, what the product promises. `positioning.md` is written for everyone else. It is the answer to "what is it?" when someone asks at a meetup, lands on the homepage or pastes a competitor's URL into AI chat. The three lines borrow from the earlier files because they pull from the same source of truth, but they are written to be said out loud, not read. ## 30-second explanation Can you explain this in 30 seconds before users ask? ## The call If the explanation takes longer than 30 seconds, the idea is still too loose. AI can rewrite it quickly, but only you can decide whether the boundaries are right. ## Sharpen the 30-second explanation with AI This is a Shape idea, so the AI move is to **Sharpen** the 30-second explanation: run your draft through the prompt below until two people would make the same decision from it. Build and Launch ideas have their own AI moves, building and running the code. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real 30-second explanation and keep the instruction exactly as visible here. It helps you put your positioning.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this 30-second explanation is clear enough before you move forward. Constraint: The 30-second explanation must be specific enough that two people would describe the same product from it. Example of the standard: Vague: "This is an AI tool that helps people write." Sharp: "This helps anyone who publishes less than they could, because the good thought turns up while they are busy. Every week it sends back a short note on what is worth saying, and why." The sharp version is specific enough that two people would describe the same product. The vague one is not. Working draft: User: [who it is for] Problem: [what problem it fixes] Useful result: [what useful result appears] Task: Decide whether this 30-second explanation is specific enough that two people would describe the same product. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. 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 explain who it is for, what problem it fixes and what useful result appears without adding a second paragraph Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Thirty seconds with none of the tech in it is a cutting exercise. AI is better at cutting your words than you are. That is [Then sharpen](https://vibe2value.com/then-sharpen/), one of the ways to get to a sharp answer. ## The same idea on a recipe card Imagine telling a friend what is for dinner in one breath. "It is a creamy chicken pasta, on the table in twenty minutes" lands straight away. If you need three minutes, a list of equipment and a diagram of your kitchen before they understand what they are eating, the dish is still muddled in your own head. Your 30-second explanation is that one-breath answer. Say what it is, who it is for and what they get, with no kitchen jargon. If it does not land in a breath the idea is still too loose, the same way a dish you cannot describe simply is one you have not really pinned down. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A short explanation is not about compression alone. It is a test of whether you actually understand the user, the problem and the outcome. If the explanation needs a follow-up paragraph to land, the idea is still too loose. AI can help rewrite the message, but it cannot create clarity that is not there. ## Make the 30-second explanation concrete Compare the broad version with a version you can actually test. - **Too vague:** This is an AI tool that helps people write. - **Concrete enough to test:** This helps anyone who publishes less than they could, because the good thought turns up while they are busy. Every week it sends back a short note on what is worth saying, and why. The second version lets two people describe the same product from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). 30 secondsFits in 30 secondsone user, one outcome, in plain wordsNeeds five minutesstill too tangled to build from The thirty-second test is a clarity test. If you can say what it is and who it is for in half a minute, it is sharp; if you need five minutes and a whiteboard, it is not ready to build from yet. ## Check the 30-second explanation - **Pass:** You can explain who it is for, what problem it fixes and what useful result appears without adding a second paragraph. - **Fail:** If the explanation depends on follow-up clarification to make sense, it is still too vague. Do not move into messaging, review or build work until this passes. ## What you'll walk away with You put this into practice with the prompt above. You'll come out with a 30-second explanation clear enough that every later decision flows from it. Landing-page copy, how you describe it in conversation, the README and the prompts you write to AI all inherit that clarity. You write the positioning before you start describing the product publicly, so you have one source of truth when the question comes up in person, on a landing page or inside an AI prompt. The file is called `positioning.md` because that is what it is: how this product positions itself in plain language. The post calls it a 30-second explanation because that is how the positioning shows up in practice, in the moment someone asks "what is it?" ## Write it down Your `positioning.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/shape/positioning.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Using a long explanation that sounds complete but means different things to different people, which causes decision drift and rework. - **Mitigation:** Agree on one 30-second explanation and check every new request against it before adding scope. ## Key takeaway Do not move forward until you can explain who it is for, what problem it fixes and what useful result appears without adding a second paragraph. ## How to document your 30-second explanation Write your 30-second explanation up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # 30-second explanation ## Answer User: [who it is for] Problem: [what problem it fixes] Useful result: [what useful result appears] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer User: A hungry friend Problem: They do not know what is for dinner Useful result: A creamy chicken pasta on the table in twenty minutes ## Evidence When I described it as a creamy chicken pasta on the table in twenty minutes, my friend knew straight away whether they wanted it. ## Decision Optimising for a plain plate they can picture. Saying no to naming the pan, the technique or the brand of pasta. ## Risk Creamy chicken pasta might still be vague if they picture something different. Check they imagine the same plate I do. ## AI instruction Explain the dish in one plain sentence a hungry friend gets in thirty seconds. No equipment or technique, just who it is for, the problem and the plate they end up with. ``` ### 1.1.3 - The One-Line Promise That Keeps Your Build Honest Throughout URL: https://vibe2value.com/the-one-line-promise-that-keeps-you-honest/ Last updated: 2026-09-07T05:58:05.000Z `user.md` and `problem.md` describe the gap between where the user is and where they want to be. `promise.md` is the shape of what fills it: one promised outcome to one user with one explicit boundary on what this is deliberately NOT trying to do. ## One-line promise Is your one-line promise clear enough to keep decisions honest? ## The call Write the promise first. Otherwise AI generates options that sound right but pull the product in different directions. ## Sharpen the one-line promise with AI This is a Shape idea, so the AI move is to **Sharpen** the one-line promise: run your draft through the prompt below until two people would make the same decision from it. Build and Launch ideas have their own AI moves, building and running the code. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real one-line promise and keep the instruction exactly as visible here. It helps you put your promise.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether the one-line promise is clear enough before you decide what to build. Constraint: The one-line promise must be specific enough that two people would position the product the same way from it. Example of the standard: Vague: "This helps people publish more." Sharp: "This helps someone with more material than published work: email it a line when the thought lands and get back what is worth writing. It never writes the post, schedules it or publishes it." The sharp version is specific enough that two people would position the product the same way. The vague one is not. Context: User: [name one real user] Promised outcome: [name one promised outcome] Boundary: [name one thing this does not promise] Task: Decide whether this one-line promise is clear enough to guide the product. If it already is, say so. If it is vague, rewrite it so you can name one user, one promised outcome and one clear boundary on what is not promised. Check: - Does it name one real user instead of a broad audience? - Is the promised outcome specific enough that two people would describe the same value from it? - Is the boundary clear enough to stop the promise from expanding? Return: - Verdict: clear, or needs work - The corrected one-line promise, the three lines, or the original if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. A promise that has to hold throughout is not something you get sharp once. It has to survive every future session, which makes it project context rather than a conversation. That is [Project memory and rules](https://vibe2value.com/project-memory-and-rules/), one of the ways to set AI up to help. ## The same idea on a recipe card Think of the one line at the top of a recipe that tells you what you will end up with. "A warm, filling bowl for two on a cold night" is a promise you can hold the cook to. A card that promises healthy and quick and fancy and cheap and impressive all at once promises everything and delivers nothing in particular. Your one-line promise is that top line. Say who it feeds, the one outcome it creates and where it stops, then keep it to a single honest line. Every later choice now has something to answer to, the same way a cook keeps checking the dish against "warm and filling for two". The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A one-line promise is not a slogan. It is the shortest honest statement of who this is for, what outcome it creates and where the boundary sits. Until you can say the promise without piling on extra claims, the product direction is too soft. AI can help produce options, but it cannot decide what should and should not be promised. ## Make the one-line promise concrete Compare the broad version with a version you can actually test. - **Too vague:** This helps people publish more. - **Concrete enough to test:** This helps someone with more material than published work: email it a line when the thought lands and get back what is worth writing. It never writes the post, schedules it or publishes it. The second version lets two people position the product the same way from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). one line, three partsFORan organic paid userI PROMISEto find their content gapsBUT NOTgeneric advice A one-line promise keeps you honest because it is one line: who it is for, the single outcome you promise, and the boundary on what it deliberately will not do. If it needs a paragraph, it is not a promise yet. ## Check the one-line promise - **Pass:** You can say who it is for, what result it creates and what it is deliberately not trying to do. - **Fail:** If the sentence still works after swapping in words like better, smarter or easier, the promise is still vague. Do not move into messaging, scope or build work until this passes. ## What you'll walk away with You put this into practice with the prompt above. You'll come out with a one-line promise clear enough that every later decision flows from it. Positioning, scope, success criteria, what you cut and the prompts you write to AI all inherit that clarity. ## Write it down Your `promise.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/shape/promise.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Writing a vague promise that sounds inspiring but allows conflicting interpretations, which increases scope drift and rework. - **Mitigation:** Define one measurable outcome in the promise and reject changes that do not improve that outcome. ## Key takeaway Do not move forward until you can say who it is for, what result it creates and what it is deliberately not trying to do. ## How to document your one-line promise Write your one-line promise up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # One-line promise ## Answer User: [name one real user] Promised outcome: [name one promised outcome] Boundary: [name one thing this does not promise] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer User: Two people on a cold night Promised outcome: A warm, filling bowl Boundary: Not healthy or quick or fancy, just warm and filling ## Evidence They arrived cold and tired and asked for nothing fancy, just something hot to hold. ## Decision Optimising for warm and filling. Saying no to healthy, quick or fancy when it gets in the way of that. ## Risk I might drift into making it impressive instead of comforting. If a choice adds flair but not warmth, drop it. ## AI instruction The promise is a warm, filling bowl for two on a cold night. Judge every choice against warm and filling, not healthy, quick or fancy. ``` ### 1.1.2 - Describe the Pain Without Mentioning the Solution URL: https://vibe2value.com/describe-the-pain-without-mentioning-the-solution/ Last updated: 2026-09-07T05:58:03.000Z `user.md` names who the user is and what they want. `problem.md` names what is actually wrong right now: the pain that sits between the trigger and the outcome. They sit side by side: user.md is the person, problem.md is what is hurting them. ## Pain statement Can we describe the pain clearly before naming a solution? ## The call Describe the pain first. Otherwise AI generates solutions for a problem nobody has confirmed. ## Sharpen the pain statement with AI This is a Shape idea, so the AI move is to **Sharpen** the pain statement: run your draft through the prompt below until two people would make the same decision from it. Build and Launch ideas have their own AI moves, building and running the code. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real pain statement and keep the instruction exactly as visible here. It helps you put your problem.md together by refining your three lines until two people would make the same product decision from them. ``` You are checking whether this pain statement is clear enough before you move forward. Constraint: The pain statement must be specific enough that two people would frame the same problem from it. Example of the standard: Vague: "Users struggle to keep up with writing." Sharp: "Someone a month past a good idea opens the log they were keeping and finds the last entry is two months old. The insight is still true and no longer sharp, because what made it worth saying was the detail they have now forgotten." The sharp version is specific enough that two people would frame the same problem. The vague one is not. Working draft: Affected user: [who is affected] Trigger: [what happens right before the pain appears] Visible cost: [what it costs the user] Task: Decide whether this pain statement is specific enough that two people would frame the same problem. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state who is affected, what happens right before the pain appears and what it costs the user? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Keeping the solution out of the description is hard on your own and much easier when something keeps asking you what you actually mean. That is [Interview me](https://vibe2value.com/interview-me/), one of the ways to get to a sharp answer. ## The same idea on a recipe card Picture tasting a soup before you change anything. "The soup is bland and watery and the guests will push it aside" names exactly what is wrong. Jumping straight to "buy a fancy new blender" names a gadget before anyone has tasted the problem, and the blender might fix nothing. Name the trouble on the plate first. Your pain statement is that taste test. Say who is eating, what makes it wrong and what it costs them, all before you reach for any tool. Get the problem right and the fix becomes obvious, the same way a flat soup just needed salt and time and not new kit. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A pain statement is not a feature request. It is a clear description of what is going wrong for one user before solution ideas enter the room. Until you can name who is affected, what triggers the pain and what it costs, the brief is too soft. AI can generate options, but it cannot choose the right boundary without a clear pain. ## Make the pain statement concrete Compare the broad version with a version you can actually test. - **Too vague:** Users struggle to keep up with writing. - **Concrete enough to test:** Someone a month past a good idea opens the log they were keeping and finds the last entry is two months old. The insight is still true and no longer sharp, because what made it worth saying was the detail they have now forgotten. The second version lets two people frame the same problem from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). A real painsomething that hurts todayJump to a solution"we should build a dashboard"Describe what hurtsand why it mattersnot yetstay here A pain statement describes the hurt, not the cure. The moment you name a solution you stop understanding the problem, so you describe what hurts and why it matters, and leave the fix for later. ## Check the pain statement - **Pass:** You can say who is affected, what happens right before the pain appears and what it costs the user. - **Fail:** The statement still sounds like a feature gap or a general frustration. Do not move into solution, scope or prototype work until this passes. ## What you'll walk away with You put this into practice with the prompt above. You'll come out with a pain statement clear enough that every later decision flows from it. Scope, success criteria, what you build first and the prompts you write to AI all inherit that clarity. You write the problem statement before the pain is felt, so you know what to recognise when users hit it. The file is called `problem.md` because that is what it is: the problem this product solves. The post calls it a pain statement because that is how the problem shows up in practice, in the user's words and in the moment they feel it. ## Write it down Your `problem.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/shape/problem.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## Risk and mitigation - **Risk:** Jumping to solution language before the pain is clear, which creates scope growth and weak user outcomes. - **Mitigation:** Require one validated pain statement and one measurable user-impact signal before discussing implementation choices. ## Key takeaway Do not move forward until you can say who is affected, what happens right before the pain appears and what it costs the user. ## How to document your pain statement Write your pain statement up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Pain statement ## Answer Affected user: [who is affected] Trigger: [what happens right before the pain appears] Visible cost: [what it costs the user] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer Affected user: The dinner guests Trigger: They taste the soup Visible cost: It is bland and watery so they push it aside and stay hungry ## Evidence Last time I served this soup the guests went quiet and left half their bowls, and someone reached for bread instead. ## Decision Optimising for a soup with real body and flavour. Saying no to watering it down to stretch it further. ## Risk The blandness might be underseasoning, not thinness. Taste it for salt first before changing anything else. ## AI instruction The problem is a bland, watery soup that guests push aside. Keep every change aimed at body and flavour, not at making more of it. ``` ### 1.1.1 - If You Can't Name the User, You're Guessing What They Want URL: https://vibe2value.com/if-you-cant-name-the-user-youre-guessing/ Last updated: 2026-09-07T08:44:52.000Z ## Outcome Get the user right and every later decision gets easier. Scope, priorities, success criteria, what to leave out and the prompts you give AI all flow from it. If the user stays vague, every decision gets softer. AI then generates plausible options for an abstract audience instead of helping solve one real problem for one real person. ## User definition Can we name the user clearly before we decide what to build? ## The call Name the user first. Otherwise AI speeds up guesswork instead of solving a real problem. ## What you are making You are making your **user definition**: a short text file called `user.md` that you keep in your project and give to your AI as the brief. It is just three lines: ``` User: [one real person] Trigger: [what starts their need] Outcome: [what they want to reach] ``` Your AI builds from these three lines, so getting them right up front is what makes the result hold up instead of breaking on the first change. **How to do it** 1. Write your three lines using the template above. 2. Sharpen them with AI until two people would make the same decision from them. 3. Save the three lines as `user.md` and use it as your brief from here on. Prefer to let your AI do this with you? The next section shows how, with the exact prompt for ChatGPT or Claude. ## Sharpen the user definition with AI This is a Shape idea, so the AI move is to **Sharpen** the user definition: run your draft through the prompt below until two people would make the same decision from it. Build and Launch ideas have their own AI moves, building and running the code. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real user definition and keep the instruction exactly as visible here. It refines your three lines until two people would make the same product decision from them. ``` You are checking whether this user definition is clear enough before you move forward. Constraint: The user definition must be specific enough that two people would make the same product decision from it. Example of the standard: Vague: "This is for people who want help writing more often." Sharp: "This is for someone who does work worth writing about and publishes in bursts, because the insight lands mid-task and the work always wins." The sharp version is specific enough that two people would make the same product decision. The vague one is not. Working draft: User: [name one real user] Trigger: [what starts the need] Outcome: [what they are trying to reach] Task: Decide whether this user definition is specific enough that two people would make the same product decision. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above. Check: - Would two people interpret this the same way? - Does it stay concrete enough to guide the next step? - Can you state who the user is, what starts the need and what result they are trying to reach? Return: - Verdict: clear, or needs work - The corrected three lines, or the original three if already clear - What was vague, and the one change that fixed it ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Naming a user you cannot yet describe is the moment to have the AI interview you rather than answer you. That is [Interview me](https://vibe2value.com/interview-me/), one of the ways to get to a sharp answer. ## The same idea on a recipe card Imagine a recipe that just says "cook something for hungry people." It tells the cook nothing. How many plates? How spicy? Any allergies? Now imagine it says "cook for my friend, who is vegetarian and arrives starving after a long drive and wants something warm and filling." That tells the cook exactly what to make. Two cooks reading it would both make a hearty veg stew, not a light salad. Your user is the person you are cooking for. Name one real person (the friend), what made them hungry (a long drive) and what they want (something warm and filling). Get those three right and two people would build the same thing from them, the same way two cooks would make the same dish. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A user definition is not a market segment. It is one real user, the trigger that starts their need and the outcome they are trying to reach. Until you can state all three in plain language, the brief is too soft. AI can generate options, but it cannot choose the right boundary without a clear user. ## Make the user definition concrete Compare the broad version with a version you can actually test. - **Too vague:** This is for people who want help writing more often. - **Concrete enough to test:** This is for someone who does work worth writing about and publishes in bursts, because the insight lands mid-task and the work always wins. The second version lets two people make the same product decision from it. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). A broad audienceanyone who wants to write morename oneOne real usersomeone whose insights get lost A user definition earns its keep by naming one real person, not a crowd. "Anyone who wants to write more" gives you nothing to build for; "someone whose insights get lost before they are written up" tells you exactly who to design for. ## Check the user definition - **Pass:** You can say who the user is, what starts the need and what result they are trying to reach. - **Fail:** The statement still sounds like a broad audience or a generic need. Do not move into feature, scope or prototype work until this passes. ## Write it down Your `user.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/framework/shape/user.md` is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. The `.md` ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code. Writing it down is how you keep good context for your AI. See [Keep the signal, not the noise](https://vibe2value.com/your-context/) for why this matters across a whole build. ## When there is more than one user Not every product has a single user. When a system serves more than one side, each side needs its own user definition or the one you write will quietly exclude the other. More on this in [Multi-Sided Systems Blur Faster](https://vibe2value.com/multi-sided-systems-blur-faster/). ## Risk and mitigation - **Risk:** The user keeps being described as a generic audience, so AI-generated options feel productive while pushing the product toward ambiguity. - **Mitigation:** Require one named user, one concrete trigger and one measurable outcome before approving new scope. If a feature cannot be explained through that lens, it does not move forward. ## Key takeaway Do not move forward until you can say who the user is, what starts the need and what result they are trying to reach. ## How to document your user definition Once your three lines are sharp, write the user definition up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # User definition ## Answer User: [name one real user] Trigger: [what starts the need] Outcome: [what they are trying to reach] ## Evidence Why you believe this. Conversations, examples, tickets, your own experience. ## Decision What you are optimising for and what you are saying no to. ## Risk Where you might be wrong and what would tell you. ## AI instruction The standing note your AI reads on this project. ``` Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier. ``` ## Answer User: My friend Trigger: They arrive starving after a long drive Outcome: Something warm and filling to eat ## Evidence The last three visits they turned up late, tired and hungry and went straight for the fridge. They never want to wait or cook. ## Decision Optimising for warm and filling. Saying no to light, healthy, quick or fancy. One hearty bowl beats three clever small plates. ## Risk They might have eaten on the road and want something light. If they say they are not that hungry when they arrive, switch to a smaller dish. ## AI instruction Cooking for my friend, who arrives starving after a long drive and wants something warm and filling. Keep every choice warm and filling, not light or fancy. If that changes, check with me first. ```