Business Plan Template for Pre-Revenue Startups

A pre-revenue business plan is not a strategy document, no matter how many founders write it like one. It's a hypothesis document: a structured list of bets about customers, problems, and money that the founder hasn't proven yet, and isn't supposed to. This piece breaks down what that document actually looks like, section by section, so the plan reflects reality instead of pretending to have skipped past it.

Why a pre-revenue business plan is a hypothesis document

Most business plans are written to persuade. That's the whole design flaw, right there. They're optimized to look certain, polished, buttoned-up, at exactly the stage when certainty is the one thing nobody has.

A founder with no revenue has no proven pricing, no validated channel, and no customers who've handed over money to confirm any of it works. Every claim in that plan is a bet dressed up as a fact. So the honest version of the document doesn't hide that. It names the fact that every claim in that plan is a bet dressed up as a fact. Each section should answer a version of the same question: what do we need to believe here, and how are we going to find out if it's true?

That framing isn't just more honest, it's also more persuasive, oddly enough. Investors and co-founders who've read enough of these plans can smell false certainty from across the room. A plan that claims to know things nobody could know yet loses credibility fast. A plan that shows sharp thinking about what's still unknown builds it. A large share of startups fail by building something nobody actually wanted, and that's a planning failure, not an execution one ycombinator.com CB Insights. Nobody writes bad code and dies. They build the wrong thing, well.

What this template covers and leaves out

This template is for a specific kind of founder: someone with an idea and a decent amount of conviction, maybe a rough prototype, but no revenue and no confirmed customer base yet. If that's the stage, here's what belongs on the page: the problem, the customer, the solution and MVP, market sizing, the business model, go-to-market, the team, and the financial assumptions.

What doesn't belong yet is just as important. The detailed org chart can wait. Skip the three-year P&L dressed up as a forecast nobody could possibly stand behind. Skip the full legal and compliance section. Those things come after validation, not before it, and stuffing them in early just signals the founder is performing seriousness instead of doing the actual work.

Format matters too. This is a working document, not a pitch deck, and definitely not a 40-page MBA capstone project ycinsight.com. It should be as long as the founder's current knowledge justifies, and not one page longer. Treat each heading in the sections below as the hypothesis itself, the body as the reasoning behind it, and the end of every section as an open question the founder still needs to close. That last part is the whole point. A plan that ends every section with a tidy conclusion is a plan that's lying to itself.

Section 1: The problem, stating what you believe is broken and for whom

This section states what's broken and for whom, and it needs to name the underlying pain, not the feature that patches it. The comparison isn't length, it's precision. One of those descriptions could be turned into a phone call list. The other one couldn't.

Evidence quality matters here too, and it stacks in a clear order: direct founder observation sits above customer interviews, which sit above secondary research pulled from someone else's report. The plan should be honest about which level it's actually standing on. The hypothesis itself should get spelled out in full, something close to: "We believe [specific customer] experiences [specific problem] because [root cause], and that this causes [some consequence that can be described or measured]."

A strong version of this section names the customer precisely enough that a stranger could go find one this week. It describes the pain using the customer's own words, not founder-speak, and it describes what currently happens today, before the product ever enters the picture. The open question at the end should be blunt: has the founder talked to enough of these people to know the problem is consistent and actually felt as a priority, not just a mild annoyance somebody shrugs off? The most common failure here is writing the problem backward from a solution that's already been decided on. The tell is simple: every sentence in the problem section quietly sounds like a product brief in disguise. The customer specificity test holds that "people who commute" is not specific enough, while "logistics coordinators at 10–50 person freight brokers who manually reconcile carrier invoices every Friday" is.

Section 2: The customer (defining who you're building for before you build anything)

Once the problem is named, the customer section gets concrete about who feels it hardest. For consumer products, demographics are close to useless on their own. Behavior and situation carry the weight: what is this person doing right now, what's frustrating them, what have they already tried and abandoned?

For B2B products, the picture splits into three roles that rarely belong to the same person: the buyer who signs the check, the user who actually operates the thing day to day, and the champion inside the company who fights for it in meetings the founder isn't in. Conflating those three is one of the fastest ways to build a go-to-market plan that quietly targets nobody.

Early adopters deserve their own callout, because they are not average customers and shouldn't be treated like a preview of the mass market. They're the subset who feel the problem most sharply, who've already tried to duct-tape together some workaround, and who'll tolerate a rough, half-finished early product because the alternative is worse. The section should commit to a named archetype specific enough that the founder could go find 50 real humans matching it inside 30 days. If that sounds hard, that's the point, it's supposed to be a real test. The closing point: is this segment big enough to matter, reachable without a massive marketing budget, and actually willing to pay, or is this just the easiest group of people to talk to?

Section 3: The solution and MVP, what you'll build first

The MVP section describes the smallest version of the product that delivers real value to that early adopter and produces usable feedback ycombinator.com CB Insights. It is the smallest version of the product that delivers real value to that early adopter and produces usable feedback. It is not a feature list dressed up in bullet points. It's the first experiment in a build, measure, learn loop, built to test exactly one core hypothesis with real users.

Three terms get used interchangeably by founders who shouldn't be using them interchangeably. A proof of concept tests technical feasibility, internally, nobody outside the team ever sees it. A prototype tests design and flow with stakeholders. An MVP tests whether actual paying users will use the thing and pay for it. The plan should say, in plain words, which of these three the team is currently building, because investors read this distinction as a proxy for how clearly the founder is thinking.

Roughly 64% of software features are rarely or never used once a product ships, which makes a useful filter for cutting scope weweb.io. If a feature doesn't directly test the core hypothesis, it belongs in version two, not version one chronoinnovation.com.

Build paths vary wildly by cost and timeline. The plan should name the one being used and justify it. Cheap insurance, in other words.

The hypothesis to spell out reads something like: "We believe that if we give [specific customer] [specific core capability], they will [specific measurable behavior], and that behavior tells us whether the solution is on track." The closing question is the uncomfortable one: has scope actually been cut ruthlessly, or has the team rationalized its way into building most of the full product anyway, under the label of an MVP? AI builders operate in the $0–500 range and take days, which is appropriate for validation prototypes chronoinnovation.com. Freelancers operate in the $5K–50K range and take one to three months chronoinnovation.com. A $3K–8K discovery sprint prevents an estimated $50K in rework, and teams that invest in pre-development planning are 3x more likely to ship a successful product, so the business plan should budget this discovery sprint investment explicitly chronoinnovation.com uinno.io waveup.com.

Section 4: Market size, estimating the opportunity without pretending to precision

Market sizing gets a bad reputation because most founders do it backward. They start with the customer definition from Section 2 and build up from there, rather than starting with a market research report and working down to a customer who may not exist. Bottom-up beats top-down here: count the specific customers who match the archetype, multiply by a realistic price they'd actually pay, and arrive at a number grounded in something real chronoinnovation.com uinno.io. That approach is more credible than waving around a headline "$50 billion market" figure that has no visible connection to the actual customer being described three sections earlier chronoinnovation.com uinno.io.

Three layers do the work. TAM is the full universe of customers with this problem, assuming a perfect solution reaches all of them. SAM narrows that to what's realistically reachable given geography, segment, and go-to-market limits. SOM is the number that matters most: what the startup could plausibly capture in the first two or three years, and it's the figure the whole plan should be built around.

Uncertainty deserves to be stated outright rather than smoothed over. What assumptions drive this number? What would need to be true for the estimate to hold? A range beats a single confident-sounding figure every time at this stage. Investors reading this section aren't grading the size of the TAM, they're checking whether the founder actually understands where the real opportunity sits, and whether the SOM is big enough to be worth chasing but small enough to sound believable. The closing point: is this market large enough to support a venture-scale outcome, or is it a genuinely good business that would never attract outside capital, and does the founder know which one is being built?

Section 5: Business model, stating your revenue hypothesis before you have revenue

This section names the current best guess at how the company makes money: who pays, how much, how often, and why they'd choose this over doing nothing or using a competitor. It should name the revenue model explicitly, whether that's subscription, transaction fee, usage-based pricing, licensing, or a marketplace take rate, and explain why that structure fits this particular customer.

Pricing deserves an actual number, or at least a range, grounded in what customers have said they'd pay, not in cost-plus math done on a spreadsheet. "TBD" It's an admission nobody's asked yet ycombinator.com CB Insights. The plan should also separate who pays from who uses, since in many B2B and multi-sided products these are different (the plan should name both).

Unit economics belong here too, even rough ones. Something like: "We believe a customer is worth roughly $X over Y months, and we expect to acquire them for around $Z through [channel]." That's customer acquisition cost and lifetime value stated as hypotheses, not spreadsheet fiction. The closing point: has the founder actually talked to potential customers about price, or is this a number that sounds reasonable in a pitch meeting but has never been tested against a real wallet?

Section 6: Go-to-market, how you'll get your first customers, not your thousandth

It is a channel mix slide borrowed from a later-stage company's deck. It is not a channel mix slide borrowed from a later-stage company's deck.

Acquisition and retention are not the same problem, and conflating them muddies the section. Getting someone to try the product is a different job than keeping them around, and while retention becomes the defining metric later, this section should stay locked on acquisition. It needs to name the specific channel for reaching early adopters (direct outreach, an existing community, a personal network, a targeted partnership) and explain why these particular customers are reachable through it. It needs the actual message that turns interest into a trial or purchase, tied directly back to the problem and customer sections written earlier. And it needs to define what counts as a win at this stage, whether that's a paid subscription, a signed letter of intent, or just a booked call.

What this section should never be is a list of channels the company might eventually try, SEO, paid social, PR, some influencer partnership, with no ranking and no commitment. That's a menu, and it tells a reader the founder hasn't actually picked a first move yet. The closing point cuts right to it: is there a concrete path to the first 25 customers that doesn't depend on luck, virality, or a channel nobody's tested uinno.io? What goes here is a specific, executable plan for acquiring the first 10–50 customers.

Section 7: Team, what the founding team can and can't do yet

The team section is an honest accounting of capability. If either one is missing, the plan needs to say so and explain how the gap gets closed.

Co-founder fit gets treated as a soft factor way too often, when it's one of the highest-stakes decisions in the whole company. 23% of failed startups cite "not the right team" as a primary failure reason, and a co-founder mismatch is harder to unwind than almost any other early mistake CB Insights uinno.io.

Solo founding is a real, legitimate path, not a red flag by default, and YC has funded more than 40 solo founders since W24 ycinsight.com. What matters is naming the specific reason for going solo and how the capability gaps get covered without a co-founder. For founders actively searching for one, the plan should name the exact skill profile being sought and the process being used to find it. Structured matching, like the kind run through YC's co-founder platform, which has facilitated well over 100,000 matches across a large pool of profiles, tends to beat informal networking on rigor ycinsight.com. Investors reading this section aren't grading how impressive the résumés look. They're checking whether this team can test the core hypothesis in the next 90 days without hiring anyone, and whether the founder is honest about what's still missing. The team section should honestly address capability (what each person can build or sell), commitment (full-time vs. part-time (43% of active profiles on the YC platform are working 40+ hours a week on their startup), and conviction (whether each founder believes in this specific problem and market) ycinsight.com ycombinator.com CB Insights.

Section 8: Financial assumptions, what the numbers need to be true, not what you hope they'll be

At the pre-revenue stage, the financial section is not a three-year P&L, and pretending otherwise fools nobody who's read more than one of these plans. It's a set of explicit, testable assumptions instead. What does the burn rate actually need to look like for the runway to last through the next validation milestone? What conversion rate, from trial to paying customer, would need to show up for the SOM in Section 4 to be remotely reachable chronoinnovation.com?

None of these numbers are facts yet. They're the conditions under which the rest of the plan holds together, stated clearly enough that six months from now, the founder can check them against what actually happened and know, without flinching, whether the whole thing was right or needs a rewrite chronoinnovation.com uinno.io.