Companion to Great App. Bad Business.

The Shipped-to-Paid Field Guide

Practical tools for app builders who have shipped (or nearly shipped) something real, with weak or uncertain revenue. These are the working versions of the tools in Oliver A. Ellison’s book, collected so you can use them without rereading the chapters.

You do not need to buy the book to use this guide. You do not need Make it RAIN. Each tool is meant for a first pass in under twenty minutes: a decision or a next test, not a document.

ISBN 9798171849252 · First edition · Tools © 2026 Oliver A. Ellison

What this is

The book’s Practical Tools (Appendices A through I) as worksheets. A first pass should take under twenty minutes per tool and produce a decision or a next test, not a document.

Who it is for

Builders with a shipped or nearly shipped product and weak or uncertain revenue. You do not need to buy the book. You do not need Make it RAIN.

How to use it

Type in the lined areas, print a section, or generate a Commercial Frontier Report from a short intake.

How to use this

A rule that applies to every tool: write what you have observed, not what you believe. “Said the reports take a senior person most of a day each month” is an observation. “Has a strong need” is an interpretation. The tools work when the entries could be checked by someone else.

Start here if you are unsure.

  1. Complete Appendix A. Stop at the first step your evidence cannot support.
  2. That break is the current commercial frontier. Do not skip ahead because a later problem feels more comfortable.
  3. Use Appendix I to turn the diagnosis into thirty days of buyer conversations, bounded offers, real prices, and explicit decisions. Or generate the report from a short intake.

Print a section if you want lined paper. The worksheets stay on this page. The Commercial Frontier Report is the interactive path.

The commercial failure path

The diagnostic replaces “nobody is buying” with the specific point at which the path from buyer to retained customer breaks. Treatment follows diagnosis. The remedy that helps one failure state hurts another.

cannot find buyer→ no reply→ will not try→ tries but does not value→ values but will not pay→ pays but does not stay

If two states both look broken, the earlier one is the constraint. The later one cannot be diagnosed until the earlier one passes.

Appendix A: Commercial Failure Diagnostic

Introduced in Chapter 5. Reused in Chapters 17, 21, 23, and 24. Read this appendix in the book.

Answer the six questions in order. For each, write the evidence that says yes. Stop at the first question you cannot support with observed behavior. That is where the next test belongs. Do not guess about anything after it.

1. Can I identify plausible buyers?

Not a persona. People you can name or describe by observable conditions, who own the consequence of the problem.

2. Do those buyers respond when I reach them?

Replies, not opens.

3. Will they undertake a real evaluation?

Against a real case, with their own data or workflow.

4. Do they experience meaningful value?

The promised outcome occurred, in their terms.

5. Will they pay under real terms?

The standard offer at the standard price, not a favor.

6. After paying, do they continue to judge the exchange worthwhile?

Activation, continued use, renewal.

Reading the result

  • A break at 1 or 2 is a buyer, message, path, or trust problem. More traffic may help and may not.
  • A break at 3 is an offer or trust problem.
  • A break at 4 is a product, activation, or use-case problem.
  • A break at 5 is a price, urgency, purchase-moment, or economic-value problem.
  • A break at 6 is a retention problem. More acquisition will make it more expensive.

Common misuse. Placing the app at the furthest point you hope it reaches rather than the furthest point you have observed. If you have never asked anyone to pay, the diagnostic stops at 5 regardless of how much usage you have.

Appendix B: Paid Problem Test

Introduced in Chapter 7. Reused in Chapters 11, 12, 19, and 20. Read this appendix in the book.

Pain is abundant. The test asks whether the problem already has an economic cost that causes behavior. The strongest problems are the ones somebody is already spending money, labor, risk, or attention on. For one target problem and one buyer:

1. What happens if the problem continues?

Next week, next month, next quarter. Name the consequence, not the feeling.

2. What is the buyer already doing because the problem exists?

Spreadsheet, contractor, part-time employee, manual review, duplicate tool, monthly fire drill. If nothing, note that. It is evidence.

3. What does the current response consume?

Hours of whose time, at what cost; money spent; revenue leaked; deadlines missed; risk carried. Use the buyer’s numbers where you have them and mark estimates as estimates.

4. Who owns the consequence?

The person whose budget, staff, or performance absorbs the cost. This is frequently not the person who experiences the problem.

5. Why does it matter now?

The trigger, if any: deadline, departure, audit, new client, failed alternative, budget cycle.

6. Is doing nothing still a reasonable decision?

Answer honestly from the buyer’s side. If yes, the problem is real and not yet paid.

Scoring without false precision. A problem passes when questions 2 and 3 have concrete answers, question 4 names a person, and question 6 is “no” or “not for long.” Strong 1 with weak 2 and 3 is a pain, not a paid problem. Strong 2 and 3 with no answer to 4 has cost and no buyer. Find the owner before proceeding.

False positives. Interesting problem, no authority. Large problem, no budget line. Painful problem, entrenched alternative that works. Costly problem that occurs once a year. Each passes part of the test and fails the part that produces purchase.

Appendix C: Build Permission Checklist

Introduced in Chapter 4. Reused in Chapter 21. Read this appendix in the book.

A feature request is evidence that somebody wants a feature. Build Permission asks whether there is evidence that building it changes buying behavior. The larger the build and the weaker the evidence, the more valuable it is to test the commercial assumption first.

1. Who needs this?

Paying customers, qualified prospects, free users, one vocal person, or the founder. Label the source accurately. There is nothing wrong with wanting a feature. There is something wrong with mislabeling why.

2. What do they do today without it?

The workaround, or the absence of one.

3. What financial or operational consequence exists?

For the person in question 1, in their terms.

4. What decision is blocked?

“They would like it” is not a blocked decision. “They cannot begin the evaluation without it” is.

5. What commitment has been made?

Verbal interest, agreement to evaluate, acceptance of a price, a dated conditional commitment, a paid pilot contingent on the feature, or nothing.

6. What result would justify the build?

Write this before the build starts. If the feature ships and this result does not follow, what will you conclude?

Decision rule. Concrete answers to 4 and 5 from a qualified buyer: Build Permission. Strong 1 through 3 and weak 4 and 5: a hypothesis. Ask what they would commit to if it existed. A feature the founder wants for product reasons can still be built. It should not be described as monetization work.

The one question that saves the most time. If we deliver this by an agreed date and the rest of the product performs as demonstrated, are you prepared to proceed at the proposed terms? The answer is the evidence.

Appendix D: Commitment Evidence Ladder

Introduced in Chapter 8. Reused in Chapters 13, 14, 20, 22, and 23. Read this appendix in the book.

Evidence gets progressively more expensive to produce, and its value rises with its cost. Lower rungs are not useless. They are weaker. One higher-rung event does not generalize. Never describe evidence from a lower rung as if it came from a higher one.

expressed pain→ agrees to evaluate→ accepts a price→ dated pilot or conditional commitment→ pays→ renews
RungWhat the buyer didWhat it provesWhat it does not prove
Expressed pain Described the problem, perhaps with frustration The problem is recognized That it is costly, urgent, or theirs to solve
Agrees to evaluate Scheduled time; supplied a real case or data The problem is worth an hour That they value the solution or can buy
Accepts a price Heard a specific number and did not decline The number is not disqualifying in context That they will pay it
Dated pilot or conditional commitment “If X by date Y at price Z, we proceed”; a paid pilot Purchase intent tied to specific conditions That the purchase will follow if conditions are met
Pays Moved money under real terms Expected value exceeded price plus risk for this buyer That value was realized; that others will pay
Renews Paid again with knowledge of what the first payment bought Realized value justified continued commitment That the business repeats or the economics work

Place every current “lead” on the rung their observed behavior supports, not the rung the conversation felt like. Then ask each for the next rung up, not for the top. A prospect at “expressed pain” should be asked to evaluate, not to sign an annual contract. Weak commercial evidence includes: “cool idea,” “I’d use this,” “let me know when it’s ready,” a feature request, a signup, a download, free usage, and social engagement. All of these sit at or below the first rung.

Current leads, placed on the ladder

Appendix E: Buyer Stress Test

Introduced in Chapter 16. Reused in Chapter 20. An early-market version appears in Chapter 9. Read this appendix in the book.

Argue the no. Before spending money or reputation amplifying a proposition, construct the strongest honest case a rational buyer could make for not purchasing, and find out where the offer is actually weak. This is not a script for rebuttals. It is a search for the variable to fix before scaling.

Answer from the perspective of a skeptical but reasonable buyer:

1. Alternative

If they reject this, what do they actually do instead, and why is that good enough? Include doing nothing.

2. Economics

What materially improves if they buy, and is the expected improvement worth the total cost of change: price, implementation, learning, disruption?

3. Confidence

What are they being asked to believe, and what evidence makes that belief reasonable for someone who does not know you?

4. Friction

What must happen between saying yes and reaching credible value, including work outside the product and people outside the conversation?

5. Timing

Why does this belong on their calendar now? What materially changes if they wait a quarter?

6. Internal purchase

Who else pays, works, approves, accepts risk, or can veto? What will each of them ask?

7. Diagnosis

Which argument against the purchase is strongest, and which variable does it implicate: offer, proof, target buyer, product, price, trust, or timing?

Decision rule. Fix the variable named in question 7 before increasing exposure. If the strongest argument against the purchase is one you cannot currently answer, do not scale the message. The scale will distribute the weakness.

Early-market version (Chapter 9). For a candidate first buyer segment, score fit, economic pain, urgency, authority, reachability, and trust on a three-point scale of none, plausible, or observed. A segment with high fit and zero on reachability or trust is a poor first buyer however attractive the eventual market.

ConditionNonePlausibleObserved
Fit
Economic pain
Urgency
Authority
Reachability
Trust

Appendix F: First Customer Path Worksheet

Introduced in Chapter 20. Reused in Chapter 24. Read this appendix in the book.

“Get your first customer” is a chain of decisions, most of which founders make by default. The path makes each one explicit and asks for evidence rather than assumption. Enter at the first step where the word “evidence” is doing more work than the evidence can support.

buyer→ paid problem→ smallest offer→ price and commitment test→ skeptical-buyer check→ conversation→ buying decision

For one real buyer, complete each step with observed information:

1. Buyer

Who, by name or by observable conditions, owns the consequence of the problem and can act? How do you reach them? What evidence supports this?

2. Paid problem

What are they already spending, doing, or risking because of it? Use Appendix B. What is the cost in their terms?

3. Smallest offer

What single bounded outcome could this buyer evaluate and purchase within a clear scope? State it without naming a feature unless the feature explains the outcome.

4. Price and commitment test

What number, what terms, what ask? What did the buyer do when they heard it?

5. Skeptical-buyer check

Appendix E, applied to this buyer. What is the strongest reason they would decline, and what did you do about it?

6. Conversation

Through what path did it happen? What was asked, clearly? What did the buyer say and do?

7. Buying decision

Yes, no, or deferred. The stated reason. The commitment made, if any.

Keep one row per buyer. That record is what makes Appendix G possible. After each decision, run the same path with the next similar buyer if the evidence says it is working. Change one step if the decision showed that step was wrong. Do not change three steps at once.

Self-serve products: the steps do not change; where they happen does. The buyer is defined by in-product behavior, the paid problem by what users abandon or pay for elsewhere, the offer by what is legible on a pricing page in four seconds, the commitment test by the checkout, the conversation by onboarding and first emails, and the record by instrumentation. Find the cohort that reached the price step and treat what distinguishes it as the buyer definition.

Appendix G: Payer Delta Interview and Comparison

Introduced in Chapter 22. Reused in Chapters 23 and 24. Read this appendix in the book.

One customer does not prove the thesis. Compared with similar prospects who did not buy, one customer can reveal the conditions that crossed the payment line. The near-misses are the control group. Without them the payer only confirms what you already believed.

Comparison group: one payer and at least two near-misses (prospects who qualified, had the problem, reached a decision point, and did not buy). The nearer, the better. A random non-payer produces a useless delta. For each person, record in observed terms:

  • Trigger: what changed shortly before the decision?
  • Urgency and consequence: what would have happened if they did nothing for a quarter?
  • Use case: what specifically did they intend to do with the product?
  • Economic impact: what was the problem costing, in their accounting?
  • Existing workaround: what were they doing instead, at what cost?
  • Authority: could they decide alone, and who else was involved?
  • Acquisition path: how did they encounter the offer?
  • Trust: what did they already believe about you, and why?
  • Proof: what evidence did they see before deciding?
  • Timing: budget cycle, project, contract, season?
  • Price tolerance: what number did they accept or refuse, compared against what?
  • Implementation conditions: what did adopting require of them?
Observed termPayerNear-miss 1Near-miss 2
Trigger
Urgency and consequence
Use case
Economic impact
Existing workaround
Authority
Acquisition path
Trust
Proof
Timing
Price tolerance
Implementation conditions

Find the rows where the payer differs from most or all near-misses. Those are the delta. There are usually two or three, and they are frequently not the ones you were selling on. Write them as a hypothesis about who buys and why. Test it on the next three prospects who match it before changing the pricing page, the outreach list, or the roadmap.

Interview prompts for near-misses. Frame as research, not as a second attempt at the sale. “I’m trying to understand who this is right for, and you were close enough that your view would help. What would have needed to be different?” “What did you end up doing instead?” “What was the moment you decided not to go ahead?”

Retention version: run the same table with retained customers against churned customers. The acquisition delta and the retention delta together describe the business. Where they differ is the most important thing the tool can show you.

Delta hypothesis (who buys and why)

Appendix H: The Ten Conversations Worth Having

Derived from Chapter 19. Read this appendix in the book.

Before a repeatable channel exists, the founder’s hours are the acquisition system. Rank prospective conversations by what they can reveal, not by what they feel like. This is a way of noticing, not a formula.

For each of the next ten possible conversations, score each condition 0 (no evidence), 1 (plausible), or 2 (observed). Do not use a finer scale.

Condition What “observed” looks like
FitLives with the problem in a context where it matters
Economic painExisting workaround, spend, or labor you can name
AuthorityCan decide, or credibly moves the decision
TriggerA visible reason action is plausible soon
Reachability and trust pathCan be reached in a way that lets a serious conversation happen; arrived with some reason to take you seriously
CandorLikely to tell you the truth, or the conversation is structured to allow it
#WhoFitPainAuthTriggerReach / trustCandor
1
2
3
4
5
6
7
8
9
10

Sum the scores if you like, then read the rows. A single zero often matters more than the total. A prospect with 2s everywhere except authority is a superb source of problem understanding and a poor use of an hour when you need purchase evidence. A prospect scoring 1 across the board is the most dangerous row: nothing disqualifies them and nothing recommends them.

Before the conversation

If this goes well, I will know more about ______ than I do now. If the blank fills with a specific belief the person can affect, take the hour. If it fills with “the product” or nothing, it is a social event. Do not count it as acquisition.

After the conversation

Which belief was strengthened or weakened, what commitment or specific refusal occurred, and whether any condition was scored wrong. Revise the score.

Appendix I: 30-Day Shipped-to-Paid Plan

Read this appendix in the book.

A sequence of the book’s tests. It guarantees a disciplined set of commercial experiments. It does not guarantee a customer or revenue, and any plan that does should be treated with the skepticism the book has recommended for every other claim.

The plan assumes a shipped product and weak or zero purchase evidence. Adjust the entry point using Appendix A: if you already have observed evidence for a step, do not repeat it.

Days 1 to 3: Diagnose

Complete Appendix A honestly. Write two lists: evidence the product works, and evidence the business works. No item appears on both without justification. Identify the first failure state you cannot support with observed behavior. Everything that follows targets that state.

Days 4 to 8: Buyer and paid problem

Rewrite the target customer as observable buying conditions rather than a persona. Complete Appendix B for one problem. Identify ten to fifteen reachable people who plausibly own the consequence. Do not build anything.

Days 9 to 15: Conversations that can change a belief

Use Appendix H to rank the list. Hold the top six to ten conversations, asking about current behavior and cost, not opinion. For each, complete the sentence in Appendix H before and record the result after. Stop the plan here and revise the buyer definition if fewer than three conversations produce an observable paid problem.

Days 16 to 20: Offer, price, and the skeptical case

From the conversations, define the smallest bounded outcome a buyer could evaluate and purchase. Write the offer without naming a feature unless needed. Attach a price and a commitment ask. Run Appendix E against it and fix the variable it names. Run Appendix C against any feature you are tempted to build first. Build it only if it has Build Permission.

Days 21 to 27: Create the purchase moment

Return to the three to five highest-scoring buyers with the specific offer, the price, a start date, and a clear ask. Ask for a decision. Record every response in the Appendix F format, including the stated reason for every no and every deferral.

Days 28 to 30: Compare and decide

If anyone paid, run Appendix G and write the delta as a hypothesis. If nobody paid, code the refusals as in Chapter 21, identify the pattern, and decide which single variable to change: buyer, problem, offer, price, trust, path, or timing. Write the next thirty-day test. Do not automate anything yet.

Thirty days from now you will know which failure state the business is in, who the buyer is in observable terms, what one bounded offer at one price looked like to real buyers, and what those buyers did when asked to decide. That is more commercial evidence than most shipped products have accumulated in a year. It may include a customer. Its purpose is to make sure that whether it does or not, you know why.

Keep going

Keep the rule that has mattered throughout the book: do not automate a guess. Make the assumption visible, put it in front of a buyer, and let the next decision earn the next move.

The argument, the stories, and the full explanations live in Great App. Bad Business. You can read it online or buy it on Amazon (ISBN 9798171849252).

Make it RAIN is optional software for working through many of these questions interactively. No software can manufacture demand. If you would rather use a guided tool than a worksheet, it is at MakeItRainApp.com.

These tools are from Great App. Bad Business. by Oliver A. Ellison. They are presented here by Reliable AI Network, Inc. as a free companion for builders. Print the worksheets, or save a Commercial Frontier Report as an HTML file.