How to write a business plan: prove who pays first

To write a business plan, start with the section that can invalidate the rest: who pays, for what outcome, at what price, and through which repeatable route. Turn the price into a required customer count, then ask for a costly action. If that section does not close, revise the idea before writing the market narrative, operating plan, or financial forecast around it.

Write the who-pays section first

A business plan is useful when it makes a decision harder to evade. It is not useful when more pages let an unproven assumption look settled. The assumption underneath every later section is that a specific buyer will exchange money for a specific result.

Write that section as answers to these questions:

The buyer must be narrow enough to find. “Small businesses” is not a buyer you can put a priced offer in front of; a named role dealing with a current job is. The outcome must be narrow enough to deliver. “Save time” hides the task, baseline, and finish line; a defined file, decision, booking, recovery, or completed workflow can be accepted or rejected.

The alternative matters because it reveals both urgency and competition. A spreadsheet, assistant, agency, manual workaround, existing product, or decision to tolerate the problem already owns the budget. Your plan has to explain why the buyer changes behavior, not why your proposed solution has features.

Make the price produce a customer count

A revenue target divided by a recurring price gives the minimum number of active customers needed to reach that target. It is arithmetic, not a forecast. It does not show that those customers exist, that you can acquire them, that they stay, or that the revenue becomes profit.

Here is a planning model with a monthly revenue target of $5,000. The price points are visible authored inputs, not market observations. Customer counts come from the same calculation as the customers-needed tool.

This is where a business plan often changes direction. A low price may require more buyers than the founder can reach or support. A high price may reduce the count but require trust, service, proof, or a sales motion the founder cannot provide. Neither result says “raise the price” by itself. It says the price, buyer, channel, and delivery have to be tested as one system.

Write acquisition and retention beside the count. Where will the first buyer come from? What does that route cost? Why would the next similar buyer be reachable through it? How long must each account stay for the acquisition and delivery work to pay back? If the only answer is a future audience, viral loop, or advertising budget with no tested conversion, the plan still contains a placeholder.

Put evidence beside every claim

Label the difference between a fact, an assumption, and a result you intend to collect. A market size estimate is not evidence that your narrow buyer has the problem. A competitor's revenue is not evidence that your channel works. An encouraging reply is not evidence that your price works.

The most useful evidence is behavior close to the claim:

• Problem claim: a current complaint, workaround, lost time, error, delay, or payment attached to the named buyer.
• Reach claim: a channel that delivered a reply, booking, artifact, deposit, or purchase from that buyer.
• Price claim: a paid pilot, pre-order, deposit, or other payment at the amount in the plan.
• Delivery claim: a completed manual version with time, cost, exceptions, and support recorded.
• Retention claim: continued use or payment for the recurring job, not a statement that the buyer likes the concept.

Pre-register the test before you run it: action, minimum result, time window, and what you will do if the bar is missed. The payment-signal guide separates what each action can prove. A result can support one section and leave the others open; your plan should show that boundary rather than spreading the strongest signal across every claim.

Run the idea through the deal-breakers

The single-idea screen asks 12 questions before a favorable story gets more detail. They cover revenue, repeatability, price, buyer access, support, platform dependence, AI-provider dependence, founder fit, compliance, call-heavy sales, payback, and transferability.

Use a failed question as a revision instruction, not as a decorative “risk” paragraph. If the buyer cannot be reached, the plan needs a different channel or buyer. If support overwhelms delivery, the scope and service boundary need to change. If regulation or procurement blocks the first sale, a smaller unregulated buyer or a different job may be the honest wedge.

Some risks can be accepted. The plan should say who accepts them, why, and what would trigger a change. What it should not do is move them into an appendix where the revenue forecast can ignore them.

Earn the rest of the plan

Once the who-pays section survives, the longer document has work to do. Each section should answer a decision and name the evidence that would change it.

Do not confuse this sequence with a universal filing format. A bank may require forecasts and security. An investor may care about ownership, scale, and return. A partner may need authority and exit rules. A regulated activity may need records and approvals. Use the requested official format and qualified advice where consequences matter.

The ordering still holds for the founder: evidence for the exchange comes before precision about a company that may not yet have a customer. A plan can become more detailed after the buyer acts. It cannot become more true through formatting.

Keep the plan as a decision record

Update assumptions when evidence changes, and retain the old bar and result. Otherwise a living plan becomes a moving target that always agrees with the latest outcome. The record should show what you believed, what you asked a buyer to do, what happened, and which section changed because of it.

The short version is the order:

1. Name the buyer, current problem, alternative, outcome, and price.
2. Calculate the active customer count implied by the revenue target.
3. Test the channel and ask for an action strong enough to answer the open claim.
4. Record delivery, support, costs, cash timing, and stop conditions.
5. Add the structure and external format the real operation and reader require.

If the first section fails, the plan did its job early. Revise the business while the rest is still cheap to rewrite.