Most advice about business plans for early-stage founders falls into two camps: "write a full business plan before you start" (wrong) and "business plans are useless, just ship" (also wrong).
The full business plan -- the 30-50 page document with five-year financial projections and extensive market analysis -- is a document designed for a specific audience. It's designed for investors and banks who need to evaluate risk across many companies. It's not useful as a thinking tool for a solo founder in the first ninety days.
The "plans are useless" response overcorrects. There is significant value in the act of writing down your assumptions explicitly before starting -- not because the document is right, but because writing it reveals where it's wrong in ways that fuzzy thinking doesn't.
The right version is neither of these. It's a one-page document that makes your eight most important assumptions explicit, creates a reference point against which reality can be compared, and forces you to articulate the condition that would make you stop before you're emotionally invested in continuing.
Here is the format.
The Eight Sections
1. The Problem (One Sentence)
Format: "[Specific customer type] consistently struggles with [specific problem] when [specific triggering situation], costing them [specific consequence]."
Bad version: "Freelancers have trouble with their finances."
Good version: "Independent consultants with three or more retainer clients consistently fail to invoice on a reliable monthly schedule, resulting in unpredictable cash flow that creates recurring stress and occasional genuine cash shortfalls."
The good version contains a specific customer type (independent consultants with retainer clients), a specific problem (failing to invoice reliably), a specific trigger (the monthly invoicing cycle), and a specific cost (unpredictable cash flow, stress, cash shortfalls).
If you cannot write a problem statement that contains all four elements with specificity, you don't yet understand the problem well enough to design a solution for it. This section failing to write cleanly is one of the most useful outputs of the exercise.
2. The Specific Customer (Two to Three Sentences)
Not the segment. The individual person. Describe them as if you know one:
"She's been independent for two to four years. She has a bookkeeper she talks to quarterly, not a full accounting firm. She sends invoices manually from a Word template or Google Docs and tracks them in a spreadsheet. She has at least one client who has paid late in the past six months."
This is the person the product needs to make happy. Every product decision is implicitly a decision about whether to make this specific person's life easier. Writing her down makes the decisions more grounded.
If your customers are businesses rather than individuals, describe the specific person inside the business who has the problem and makes the purchasing decision.
3. The Solution (One Sentence)
Format: "[Product name or description] allows [specific customer] to [achieve specific outcome] by [core mechanism]."
"An automated invoicing tool allows independent consultants to ensure invoices are sent on time every month without thinking about it, by generating and sending invoices automatically based on a preset schedule."
The one-sentence constraint is intentional. If the solution description requires more than one sentence, the solution is probably too broad. What is the product's single most important function?
4. The First Revenue Assumption
The most important number in the plan, and the one that most founders are vague about.
Specify: who pays (the individual, the business, a specific role), how much (what you will charge, not a range -- a specific number), when they pay (monthly, annually, one-time), and by what date you expect to have the first paying customer.
"I expect to charge $49 per month, billed monthly. My first paying customer will be secured within twelve weeks of starting this project."
Write the specific number and the specific timeline before you've done the validation. This is an assumption. You're recording it now so that you can compare it to what happens. If you end up charging $29 or $89, the difference matters and deserves to be understood.
5. The Distribution Assumption
How will your first ten customers find you, or how will you find them?
Be specific. "Through content marketing" is not specific. "Through the Freelance Business Owners Facebook group, where I will post about the invoicing problem and respond to every reply, and through direct outreach to ten consultants in my existing network" is specific.
The distribution assumption is the one that founders most often get wrong. Ideas about how customers will be found that exist only in the founder's head have not been tested against the actual friction of finding customers in practice. Writing the assumption explicitly makes it testable.
6. The Alternative Assumption
What does your specific customer currently do instead of using your product?
This is the existing substitute that your product will compete with. Not a competing product -- the workaround your customer is using right now.
"Independent consultants currently send invoices manually from Google Docs or a Word template, tracking receipt and follow-up in a personal spreadsheet or mentally. Some use FreshBooks or Wave but don't use the automated reminders feature."
The alternative assumption is the most important product positioning input you have. Your product's value proposition is not "we do X." It's "we do X better than the thing people are currently doing." If you don't know the current workaround in detail, you don't know your actual competition.
7. The First Metric of Success
One metric. Not a dashboard. Not a list of KPIs. One number that, if it appears, tells you the business is working.
"My first metric of success: five paying customers within four months of launch who are still active at month five."
Why five customers? Because one or two paying customers could be friends, anomalies, or people who signed up out of politeness and will churn. Five independent paying customers who are still active one month after signing up is the threshold at which the signal becomes clear enough to interpret.
Your metric should be specific enough that you can't rationalize your way around it when it appears. "Good traction" is not a metric. "Five paying customers still active at month five" is a metric.
8. The Kill Condition
The section most founders skip. The most important section.
The kill condition is the specific outcome that would cause you to stop working on this project. Write it before you start. Write it before you're emotionally invested.
Format: "I will stop working on this project if [specific observable condition] occurs by [specific date]."
"I will stop working on this project if I cannot reach five paying customers within six months of launch, or if I cannot reach 200 email signups from cold traffic within three months of activating the landing page."
Two conditions: one for the validation metric, one for the revenue metric. If either is breached by the specified date, you stop.
Why write this now? Because the decision to continue or stop a project that isn't working is infinitely harder to make when you're inside it than when you define the threshold before you start. Founders who don't define a kill condition in advance face a permanent series of rationalized continuations: "next month might be different," "we almost had a good signal," "one more pivot and it might click."
The kill condition is a commitment device. You write it when you have information (your current best judgment about what you should see if this is working) and use it when you have emotion (the desire to continue regardless of signal because you've invested time and identity).
How to Use the Plan
This document is not a presentation. Don't share it with investors or send it to advisors seeking feedback. It's a thinking reference for you.
Write it before you start: The value is in the act of writing it -- in finding the sentences that won't write cleanly and identifying the gaps they reveal.
Review it monthly: Once a month, read the plan against what has actually happened. Where were the assumptions correct? Where were they wrong? Update the distribution and revenue assumptions as you learn more. Do not update the kill condition once it's set.
Update the customer description: As you do customer interviews and talk to real users, the specific customer profile will sharpen. Update the description to match what you've learned. This is healthy. It means you're listening.
Hold the kill condition stable: The temptation when approaching the kill condition threshold is to revise it. Resist this. If you set a six-month customer threshold and you're at month five with one paying customer, the answer is not to change the threshold to ten months. The threshold was your best pre-emotional judgment. Honor it.
The Honest Value
Writing this plan will take two to four hours if you do it seriously. If some sections don't write cleanly on your first attempt, that's the document working as designed -- revealing assumptions that aren't yet well-formed.
The plan will be wrong in specific ways. Distribution will be harder than you expected. The first revenue will come later. The customer profile will be different from the description. What the plan gives you is not accuracy. It's a structured record of what you thought before you knew what you now know.
That record is valuable. It shows you where your mental model of the business was right and where it was wrong. It's the input to the better judgment you'll have in six months.
Write the plan. Look at it honestly. Then go test the assumptions.
Ready to validate your idea?
Start using WarmLaunch today to grow your waitlist.