Before you spend weeks building

Find the reasons to build.
And the reasons to stop.

A before-you-build brief for your app idea: customer pain, alternatives, possible first customers and one practical demand test.

Private founder pilot

Example only · fictional evidence

See the decision you would receive.

This is an invented scenario to show the report format—not live research, a testimonial or proof of demand. A real report may find much less evidence.

Investigate my own idea →

See what changed after checking real source pages →

Before-you-build brief · example

PainMonkey · Report illustrative-lunch-example · 2026-09-09

Leftover Lunch: your next decision

Fictional example. No customers were interviewed and no source research was run. AI research, not verified demand. Read cited pages and test with actual customers before investing in a build. Buyer and channel suggestions are hypotheses.

Run a demand test first

Test whether leftover planning is painful enough to change an existing routine. A full app would be premature; a manually prepared plan can test the core value.

Who might buy?

Start with parents who already cook family dinners and pack school lunches most weekdays. Do not assume every parent has this problem or would pay to solve it.

Where could you reach them?

A local parent association could help recruit interviews if an organizer permits it. Permission, relevance and acquisition cost are unknown; no community is a guaranteed distribution channel.

Your smallest next test

Recruit 10 parents who packed at least four lunches last week. Ask about their most recent planning experience, then offer a clearly described manual one-week leftover lunch plan. Before recruiting, propose a threshold: at least 3 accept a concrete paid pilot offer and at least 2 actually use the plan. If not, change the customer/problem hypothesis before coding. This threshold is a planning hypothesis, not a validated success predictor.

Still unknown

Whether the difficulty is planning, picky eating or remembering leftovers; whether parents will switch from free routines; willingness to pay; food preference and safety constraints; time needed to deliver a useful plan.

Signals worth investigating

Illustrative finding · not real evidence

In this fictional example, a parent already repurposes dinner leftovers but finds the nightly decision tiring. That suggests a specific job to investigate.

What this does not prove: One invented account illustrates the report format. It establishes no real pain, prevalence or demand.

Inspect the evidence behind this claim
Fictional parent conversation

Fictional source for product demonstration

Invented example passage

I use leftovers already. Deciding what will work for lunch is the part I have to think about every night.

Reasons to hesitate

Illustrative finding · not real evidence

In this fictional example, another parent is satisfied with a reusable weekly list. A free routine may solve the problem well enough.

What this does not prove: An app must improve on an adequate free workaround. This invented counterexample is not market research.

Inspect the evidence behind this claim
Fictional satisfied-parent account

Fictional source for product demonstration

Invented example passage

We repeat a short list each week. I would not want another app to manage it.

PainMonkey · Before-you-build test record · illustrative-lunch-example

Leftover Lunch

FICTIONAL DEMO PRACTICE - not customer evidence.

Founder-entered record, not independently verified. Plan locked: Not started.

Eligible audience

Parents who pack school lunches at least four days a week

Recent problem

Planning school lunches around dinner leftovers without a second planning routine

Honest offer

Not yet recorded

Price and terms

Not yet recorded

Recruitment and permission

Not yet recorded

Buyer hypothesis — founder assumptions, not a validated ICP Who would use it? Unknown — ask, do not guess Who controls the budget? Unknown — ask, do not guess What makes the problem urgent now? Unknown — ask, do not guess What do they use or do today? Unknown — ask, do not guess Ask for recent examples before sharing these assumptions. Record contradictions as well as support; a role description is not a contact list or permission to recruit.

Proposed rule - not locked

3 payments or attended trials and 2 uses among 10 eligible approaches. Proposed, not a calibrated benchmark. A person who pays and attends counts as one commitment.

Plan not started

Approached: 0 · Replied: 0 · Attended: 0 · Paid/deposit: 0 · Used: 0

No payment evidence recorded. Attendance and positive replies do not establish willingness to pay.

Keep declines and no replies in the record. Wait for your planned sample before interpreting the rule.

Convenience sample; founder-entered outcomes are not independently verified. Not a market conversion estimate or a business-success probability.

Outcome-window review: Not confirmed; outcomes may still be pending. Founder-declared, not independently verified.

Next decision: Make the test runnable

No customer behavior is recorded yet. The next investment is a clear offer, not app development.

  1. Describe one result you can deliver manually, what is not included, the price or free-trial terms, and a realistic delivery date.
  2. Choose a specific eligible group and a permitted way to reach them. Record the response and trial window in your recruitment plan.
  3. Set the sample and screening rule before approaching people, then lock this plan.

Planning guidance, not a prediction. Let the same promised response and trial window pass for everyone before interpreting missing outcomes. Keep pending outcomes distinct in your notes; update them when known. Do not rewrite this test’s offer or rule after seeing results.

Cost scenario — estimates only

Cost scenario — founder estimates, not observed revenue or a forecast Basis: one purchase Price per customer ($): Not estimated Delivery, AI, fees and expected refunds per customer ($): Not estimated Cost to acquire one customer ($): Not estimated Fixed costs for this period ($): Not estimated Service and support hours per customer: Not estimated Complete every estimate to calculate; missing costs are not assumed zero. Excludes taxes, founder development time, unpaid acquisition effort and costs not entered. Deposits may not be earned revenue. This does not change the locked customer offer or prove people will pay.

Anonymous outcome log

No approaches recorded.

From research to a real-world test

Your before-you-build sprint

Turn a promising question into an honest offer. Record what people actually do—not whether they say your idea sounds good.

Practice with this fictional example. Nothing entered here is saved.

Three questions to ask before pitching
  1. Tell me about the last time you dealt with “Planning school lunches around dinner leftovers without a second planning routine”. What happened?
  2. What did you do instead? What did that cost in time, money or effort?
  3. What works well about your current approach, and what have you actually tried changing?

Listen for recent examples and adequate workarounds. Do not count your own demo practice as customer evidence.

Set your offer and test rule
1. Commit to the test before collecting results
Narrow down the buyer (optional)

These are working assumptions, not a validated customer profile. Unknown is an honest answer. They lock with this plan; use a separate follow-up to test a different buyer.

Name a role and situation, not a broad demographic. Example: solo designers sending client invoices.
The user, their manager, a client—or unknown. Do not assume the user can approve a purchase.
Describe a recent event you can ask about. Example: an overdue invoice delayed their own bills. This is a hypothesis until checked.
Include doing nothing and adequate free options. Ask what works well before assuming they need a new app.

Put the resulting eligibility rule in “Eligible audience” below. Do not exclude someone merely because their answer contradicts your hypothesis.

State what exists honestly. A manual pilot is fine. For a free test, enter “Free trial”; it cannot establish willingness to pay.

These default targets are an adjustable screening rule, not a validated benchmark. Keep all eligible approaches, including declines and no replies.

Recruitment kit: who to ask and what to say

DRAFTS ONLY. Personalize, check every statement and replace all bracketed placeholders before using. These drafts are not evidence of demand, channel permission or legal compliance. PainMonkey does not send messages or collect contacts.

Complete these plan fields to fill the drafts: offer, price, channel. Remaining bracketed details always need your review.

Before you recruit

  • Check current channel rules and obtain any required organizer permission before posting. An indexed forum page is not permission to recruit there.
  • Use one clear eligibility rule, offer and response window. Log every eligible approach, not just enthusiastic replies; organizer responses are not customer outcomes.
  • Keep interviews separate from the offer. Do not treat politeness, hypothetical willingness to pay or a booked-but-unattended call as payment or use.
  • Use anonymous labels in PainMonkey. Keep contact details and any necessary consent records in your own appropriate system; avoid sensitive details in this worksheet.
  • Do not accept payment until you can deliver and honor the terms. Honor declines; do not scrape contacts, send bulk unsolicited messages or invent scarcity.

Check the person, the problem and the buyer

Your buyer assumptions to check—not a script to read aloud

Buyer hypothesis — founder assumptions, not a validated ICP Who would use it? Unknown — ask, do not guess Who controls the budget? Unknown — ask, do not guess What makes the problem urgent now? Unknown — ask, do not guess What do they use or do today? Unknown — ask, do not guess Ask for recent examples before sharing these assumptions. Record contradictions as well as support; a role description is not a contact list or permission to recruit.

  1. What in your recent experience makes you part of “Parents who pack school lunches at least four days a week”?
  2. Tell me about the last time you faced “Planning school lunches around dinner leftovers without a second planning routine”. When was it, and what did you actually do?
  3. What works well about that approach? What time, money or effort did it actually take?
  4. Who would use a solution, who would approve it, and who would pay? Are those different people?
  5. What have you already tried changing, if anything? What happened?

These questions test your audience hypothesis; they do not identify a proven buyer automatically. Copy a draft and personalize it outside this app.

Ask the organizer first
Invite a willing participant to talk
Make a separate, honest pilot offer

3. Read the outcome without inflating it

Approached
0
Replied
0
Attended
0
Paid / deposit (gross)
0
Fully refunded
0
Refund status unchecked
0
Checked: not fully refunded
0
Used
0

Plan not started

Keep declines and no replies in the record. Wait for your planned sample before interpreting the rule.

No payment evidence recorded. Attendance and positive replies do not establish willingness to pay.

Convenience sample; founder-entered outcomes are not independently verified. Not a market conversion estimate or a business-success probability.

4. Your next decision: Make the test runnable

No customer behavior is recorded yet. The next investment is a clear offer, not app development.

  1. Describe one result you can deliver manually, what is not included, the price or free-trial terms, and a realistic delivery date.
  2. Choose a specific eligible group and a permitted way to reach them. Record the response and trial window in your recruitment plan.
  3. Set the sample and screening rule before approaching people, then lock this plan.

Planning guidance, not a prediction. Let the same promised response and trial window pass for everyone before interpreting missing outcomes. Keep pending outcomes distinct in your notes; update them when known. Do not rewrite this test’s offer or rule after seeing results.

Could a sale cover its costs? (optional estimate)

These are your assumptions, not customer results. Editing them does not change the locked offer or process any payment. Leave unknowns blank; do not quietly assume zero.

For a subscription, include the full acquisition cost in month one. This is not lifetime value or an estimate of retention.

Complete every estimate to calculate. Missing costs are not assumed zero.

Excludes taxes, founder development time, unpaid acquisition effort and costs you have not entered. Refundable deposits may not be earned revenue. Do not use this estimate as proof of profitable demand.