A business case template is a fill-in structure for arguing whether an idea deserves your time and money: the problem, who has it, how big the opportunity is, how it makes money, what the alternatives are, and what could kill it, ending in a decision. The one-page version below is built for product ideas and takes 30 minutes.
You have an idea. It arrived in the shower, it feels obvious, and part of your brain is already picking the tech stack. This is exactly the moment to spend 30 minutes trying to kill it.
Copy the template first, then read on for how to fill it in, two worked business case examples (one passes, one does not), the kill criteria, and the self-deceptions that sink otherwise smart people.
The one-page business case template (copy and paste)
This is designed for a strict 30-minute timebox. Five minutes per section, no research rabbit holes, guesses explicitly labelled as guesses.
Copy the markdown into your notes app, set a timer, and write in full sentences. Bullets let you hide from your own logic. Prose forces the argument to connect.
# Business Case: [idea name], [date]
## 1. Problem (5 min)
Who specifically has this problem? (a person you could DM, not a demographic)
What do they do today instead? (the current workaround IS your competitor)
How painful is it: annoyance, recurring cost, or hair-on-fire?
Confidence: guess / anecdote / evidence
## 2. Audience & reach (5 min)
Where do these people already gather? (subreddits, Slacks, newsletters)
Can I get 20 of them on a call or in a DM this month? How?
Confidence: guess / anecdote / evidence
## 3. Market framing (5 min)
SOM first: how many customers could I realistically win in 18 months?
At what price? SOM revenue = customers × price × 12.
Is that number worth my next year? (Compare to your alternatives, honestly.)
## 4. Monetization (5 min)
Who pays, the user or someone else? One-off, subscription, or usage?
What do they pay for adjacent tools today? (proof of willingness to pay)
What's my price anchor, and why would switching be worth it?
## 5. Competition & alternatives (5 min)
Top 2-3 alternatives, including "spreadsheet" and "do nothing."
Why do people churn from those? (If I can't answer, I haven't looked.)
What's my wedge, the one segment where I'm clearly better?
## 6. Kill risks (5 min)
The single assumption that, if false, kills this. How will I test it?
Distribution: what's my repeatable channel? ("Launch on PH" is an event, not a channel.)
Verdict: BUILD / TEST FIRST (name the test) / KILL
When the timer ends, read it back and make one of three calls: build, test one named assumption first, or kill.
Using it for an internal project instead
Most business case templates online are written for internal projects that need budget sign-off. The same six sections cover that case with different labels:
| Product idea section | Internal project equivalent |
|---|---|
| Problem | Current state and the problem it causes |
| Audience & reach | Stakeholders and who is affected |
| Market framing | Expected benefits, in money or hours where you can |
| Monetization | Costs, funding, and payback |
| Competition & alternatives | Options considered, including "do nothing" |
| Kill risks | Risks, assumptions, and the recommendation |
The discipline is the same either way: one page, confidence marked, a decision at the end.
What is a business case?
A business case is a short structured argument for why a product or project should exist. The problem, who has it, how big the opportunity is, how it makes money, and what could kill it.
Builders skip it for two reasons. The format has a corporate reputation, all committees and sign-off theatre. And writing one risks hearing "no" before the fun part starts.
The cost of skipping is lopsided, though. The case takes 30 minutes. An MVP takes six to twelve weeks of nights and weekends. CB Insights' post-mortem analysis puts "no market need" near the top of why startups fail, and that is a failure mode almost entirely detectable on paper, before a single line of code exists.
The reframe that makes it palatable: treat a business case as a pre-mortem rather than a permission slip. The corporate version optimises for defensibility. The builder version optimises for speed to a kill decision. Same name, different tool.
How to write a business case in 30 minutes
Answer six questions on one page. What is the problem and who has it? How are they solving it today? How big is the reachable market? Why would they pay, and how much? How does this make money? What would have to be true for this to fail?
Each answer is two to five sentences in plain language, with your confidence marked honestly as guess, anecdote, or evidence. The whole thing should fit on one screen. If it does not, you are padding, and padding is where self-deception hides.
The discipline matters more than the accuracy. The first pass is not trying to be right. It is trying to expose which sections you cannot fill in without hand-waving, and those sections become your validation to-do list.
The output is a decision rather than a grade. And if every idea you run through the template survives, your kill criteria are too soft.
TAM, SAM, and SOM in a business case
Four terms, defined once:
- TAM, total addressable market: everyone who could conceivably use a product like yours, in revenue terms.
- SAM, serviceable addressable market: the slice of TAM you could actually reach with your product and channels.
- SOM, serviceable obtainable market: the slice of SAM you can realistically win in the next couple of years.
- Willingness to pay: the price at which a specific customer actually hands over money, as distinct from whether they call the idea cool.
For solo builders, TAM is nearly useless and SOM is nearly everything. That is why section 3 of the template starts from SOM in real customer counts and works upward, instead of starting from a market-research headline and working down. TAM SAM SOM: what they mean and how to calculate each walks through the arithmetic with a worked example.
Business case example 1: a case that says yes
Here is a full example for a plausible indie SaaS idea, written in about 30 minutes, so you can see what good enough looks like, honest guesses included.
The idea: RetainerFlow, for freelance designers and developers who bill monthly retainers. It tracks hours against each client's retainer, sends an automatic monthly usage report, and flags overages before they become awkward conversations.
Problem. Freelancers on retainers track hours in Toggl or a spreadsheet, then manually assemble a monthly summary. Or they skip it, eat the overages silently, and quietly resent the client. Cost: one to two hours a month plus unbilled work. Confidence: anecdote, from three freelancer friends and two r/freelance threads.
Audience and reach. Freelance designers and developers with two or more retainer clients. They gather in r/freelance, Indie Hackers, and freelancer Slacks. I can DM 20 this month through two communities I am already in. Confidence: evidence for reachability.
Market framing. SOM of 300 paying users in 18 months at $15/month is $54k ARR. Small, but as a solo side product it clears my bar. I am not claiming the freelance-software TAM. I am claiming 300 specific people.
Monetisation. The freelancer pays. The report is client-facing and makes them look professional, which makes it a business expense. They already pay for Toggl and invoicing tools at $10 to $30 a month each. Anchor at $15: recover one overage hour and it pays for the year.
Competition. Toggl and Harvest track time but do not do retainer-aware client reporting. Spreadsheets do it badly. "Do nothing" is the real incumbent. Wedge: retainer-specific, client-facing by default.
Kill risk and verdict. The kill assumption is that freelancers will pay rather than tolerate the spreadsheet. Test: 20 DMs asking about their last overage conversation, past behaviour rather than hypotheticals. Verdict: TEST FIRST. Build only if six or more of 20 describe a recent, painful overage.
Notice what this case does not claim. No billion-dollar TAM. No "there are no competitors." And it still exits with a test rather than a build order.
Business case example 2: a case that says no
A case that kills an idea is a success. It just saved you a quarter.
The idea: HabitMind, an AI habit tracker giving personalised coaching nudges based on streak data. It feels compelling. Everyone struggles with habits, AI coaching is hot, and the builder would use it themselves.
Problem. People abandon habits. True and universal, and mostly already solved to the level people will pay for. Alternatives: Habitica, Streaks, Apple's built-ins, free ChatGPT prompts, paper. Pain level: annoyance, not hair-on-fire.
Audience and reach. "People who want better habits" is a demographic, not an audience. There is no room where they gather as buyers. Habit-tracker communities mostly compare free apps.
Market framing. The SOM math collapses. Consumer habit apps churn heavily, and the app stores show hundreds of free-tier competitors. $50k ARR at $5/month needs roughly 830 retained subscribers in a category where retention is the known graveyard.
Monetisation. This is the killer. People say habits matter but they pay for outcomes, a gym or a coach, not for tracking. My anchor competes with free, and "AI coaching" is a feature ChatGPT gives away.
Competition and wedge. No wedge. "Mine has better AI" is a hope, not a segment.
Kill risk and verdict. The kill assumption, that people will pay for AI habit nudges, already has abundant negative evidence in public churn data and the free-tier arms race. Verdict: KILL. Deciding cost 30 minutes. Learning it via an MVP would have cost a quarter of evenings.
It dies in three of six sections, and its failure modes are the most common ones in consumer-adjacent indie ideas: crowded market with free incumbents, low willingness to pay, no wedge, no channel. If your idea has this shape, the template will tell you quickly.
The kill criteria checklist
Kill criteria are conditions you pre-commit to walking away on, written down before you fall further in love with the idea. They turn a fuzzy emotional decision into a checklist you agreed to while still objective.
Run it after filling in the template. One hard fail means kill or fundamentally reframe. Two soft fails mean test before building.
The list deliberately weights distribution and willingness to pay over product cleverness, because post-mortems cite market and distribution failures far more often than product failures.
Hard kills, any one means stop or reframe:
- I cannot name a specific, reachable person with this problem
- The current workaround is free and good enough, so the pain is an annoyance rather than a cost
- Willingness to pay is unproven and untestable within a month
- SOM revenue at honest numbers does not clear my personal bar
- My only distribution plan is a launch event rather than a repeatable channel
Soft fails, two or more means test first:
- My confidence column says "guess" in more than three sections
- I cannot explain why people churn from the top alternative
- My wedge is a feature ("better AI") rather than a segment, or I am the only user I have talked to
If the idea survives, the next step is turning the case into a plan. Why AI code breaks without a plan and writing user stories with INVEST pick up from here.
Common self-deceptions
Self-deception in product validation is rarely lying. It is choosing the framing that lets the fun part start sooner. Three patterns account for most of it.
TAM theatre. Citing a giant market, "fitness is a $100B industry," as though size implied capturability. The template counters this by forcing SOM-first math in real customer counts.
Mistaking absence for opportunity. "No competitors means wide open." If nobody solves this problem for money, the likeliest explanation is that nobody will pay. The template forces you to list "spreadsheet" and "do nothing" as competitors, and those always exist.
Solution-first reasoning. Starting from a technology you want to use and back-filling a problem for it. The tell is a problem statement that mentions your solution.
There is a fourth, subtler one: validation by compliments. "Everyone I showed it to loved it" might be the most dangerous sentence in indie hacking. Rob Fitzpatrick's The Mom Test is the canonical fix. Ask about past behaviour and current spending, never hypothetical enthusiasm.
Each of these survives vibes and dies on one page of prose. That is the entire argument for writing it down.
Drafting a business case with AI
If the blank page is what stops you, VibeMap's free Business Case Generator drafts a first pass from a one-paragraph idea. It returns the problem, target audience, value proposition, a qualitative TAM/SAM/SOM framing, monetisation options, and the key risks with a mitigation for each. No signup.
Two things to know before you trust it. It reasons from what a language model already knows about comparable products and does not run live market research, so its market framing is a described band rather than a sourced figure. And it will not apply your kill criteria for you. Use it to fill the template faster, then correct its guesses against real conversations.
Once an idea genuinely passes, move fast on the next artifact. In VibeMap, the same idea description becomes a linked spec: personas, features, user stories, acceptance criteria, pages and a database schema, each tracing back to what justified it. Spec-driven development covers that path from verdict to buildable plan.
FAQ
How long should a business case take for an indie product?
Thirty minutes for the first pass, five minutes per section. The first draft's job is to expose which sections you cannot fill honestly, and those become your validation tasks. A second pass after customer conversations might take another hour. Days on it means you have drifted into corporate territory.
What is the difference between a business case and a business plan?
A business plan is a long operating document: financials, org structure, multi-year projections. A business case is a short argument for one decision, namely whether this product should exist. For builders the case is the useful one, because plans age badly while a one-page case gets re-tested against reality every time you learn something.
What are the key components of a business case?
Six sections: problem and who has it, audience and reach, market framing from SOM up, monetisation and willingness to pay, competition including "do nothing," and kill risks with a verdict. Add a confidence label per section so optimism cannot hide. For an internal project the same six map to current state, stakeholders, benefits, costs, options considered, and risks with a recommendation.
What is the format of a business case?
For a product idea, one page of short prose sections in a fixed order, ending in a verdict: build, test first, or kill. Longer corporate formats add an executive summary up front and a financial appendix at the back, but the core argument is the same, and if it does not fit on one page the extra length is usually padding.
How do I validate a product idea without building anything?
Test the kill assumption directly. Fifteen to twenty conversations about past behaviour and current spending, a landing page with a real price, or pre-sales. Each targets willingness to pay, which is the thing an MVP is worst at testing, since free beta users tell you nothing about paying customers.
What are TAM, SAM, and SOM in plain terms?
TAM is everyone who could conceivably use a product like yours. SAM is the slice you could actually reach. SOM is what you can realistically win in the next 18 to 24 months. Solo builders should do the math from SOM up, not TAM down.
Is a business case generator worth using?
As a first-draft accelerator, yes. As a verdict, no. A good one structures a one-paragraph idea into problem, audience, market framing, monetisation, and risks, which kills blank-page paralysis. You still supply the honesty: correct its guesses against real conversations, and let the kill criteria decide.
What is a good kill rate for product ideas?
If fewer than a third of your ideas die at this stage, your criteria are too soft. Ideas are cheap and abundant. Quarters of your life are not. A healthy pipeline kills most ideas on paper, tests a few, and builds the rare one that survives both.
When should I ignore the business case and build anyway?
When you are building for learning or joy rather than revenue. Say so explicitly and skip the theatre. Occasionally an idea fails on paper but you hold private conviction that the market is wrong, and the case still helps then, because it names precisely which assumption you are betting against.
If staring at a blank page is the blocker, the Business Case Generator drafts this first pass from a one-paragraph idea description. Free, and worth treating as a starting point to argue with rather than a verdict.
