BuildForReal · worksheet
App Validation & First-Users Scorecard
Fill this in before you spend money on ads. Print it, or save it as a PDF from your browser. Nothing here is a promise of results — it is a way to see whether real people get a useful outcome from your app.
1 · Job statement
One sentence, filled with specifics. No adjectives.
When [specific person, by role and setting] faces [trigger event], they currently [workaround x], which costs them [cost y: minutes, money, risk, repeated escalation]. The observable useful outcome is [z: the thing they can show someone afterwards].
| Your version |
|---|
2 · Behaviour-based interview questions
Ask about the last real occurrence. Asking “would you use my app?” is less reliable than watching what someone did the last time the job came up — answers to that question are opinions, and opinions are free.
- Walk me through the last time this happened. What day was it, and what were you doing right before?
- What did you open first? Then what?
- Which tools were involved — including the ones you only half-use?
- How long did it take, start to finish? What part took the longest?
- What went wrong, or nearly went wrong, because of how long it took?
- Who else got pulled in? What did you have to send them?
- What did you do with the answer once you had it?
- How often does this happen — last month, how many times?
- Have you looked for something to make this easier? What did you try, and why did you stop?
- Can you show me, with anything sensitive removed? (sanitized walkthrough)
Sanitized walkthrough rule. Ask them to redact before they share, or use synthetic data. Never ask someone to paste a real customer record, credential or internal header into your app to prove a point.
3 · Evidence log
One row per real person, filled in from what you saw — not what they said they might do.
| Role | Trigger | Workaround | First useful result | Confusion | Return |
|---|---|---|---|---|---|
Return means they came back on their own, on a later day, without you asking. Judge it against the job’s natural frequency — weekly returns mean little for a once-a-year task.
4 · Audience matrix
| Role | Trigger | Testable promise | First action | Discovery channel |
|---|---|---|---|---|
A testable promise is one someone can call wrong within a minute of using the app. “Paste a header, see which check failed and why” is testable. “Email, simplified” is not.
5 · Activation and repeat use
Clicks are traffic. Activation is a completed useful outcome. Write both definitions down before you measure anything.
| Event | Your definition | Where it fires |
|---|---|---|
| Click arrival only — not a result | ||
| Activation first completed useful outcome, in one session | ||
| Repeat use activation again on a later calendar day, within a stated window |
Repeat-use window I am committing to: ______ days. Counted from first activation, not from the click.
6 · Ad-test matrix — HYPOTHETICAL EXAMPLE
This matrix was not run. The audiences, angles, caps and signals below are placeholders to show the shape of a test. No campaign described here was run, and no performance figures are implied. (Tunde says he separately tested Reddit ads for MailSleuth — that is his account, not a result we report.)
| Cell | Audience | Message angle | UTM | Spend cap | Success signal |
|---|---|---|---|---|---|
| A1 | Audience A | Angle 1 — name the trigger | utm_source=…&utm_medium=paid&utm_campaign=validation-v1&utm_content=a1-aud-a-angle-1 | $___ total | completed use |
| A2 | Audience A | Angle 2 — name the outcome | …&utm_content=a2-aud-a-angle-2 | $___ total | completed use |
| B1 | Audience B | Angle 1 — name the trigger | …&utm_content=b1-aud-b-angle-1 | $___ total | return within window |
| B2 | Audience B | Angle 2 — name the outcome | …&utm_content=b2-aud-b-angle-2 | $___ total | return within window |
Every cell gets its own utm_content, its own cap, and a stop date. Judge cells on completed use and return — never on clicks or impressions.
7 · Six gates before you scale spend
Checks before you increase or scale paid marketing. A modest, capped learning test is fine before all six are clear — these gate scaling, not the first exploratory spend.
1. Product reliability. Does the core path work every time, on a phone, for someone who has never seen it?
Yes ☐ No ☐ Evidence: ______________________
2. Result comprehension. Can a first-time user say, in their own words, what the result means and what to do next?
Yes ☐ No ☐ Evidence: ______________________
3. Accurate activation measurement. Does your activation event actually fire on the completed outcome — verified by you, end to end?
Yes ☐ No ☐ Evidence: ______________________
4. Repeat-use window. Have you defined the window, and can you see returns inside it?
Yes ☐ No ☐ Window: ______ days
5. Privacy and availability honesty. Does the page state plainly what data is sent where, what is stored, what is not, and what happens when the app is down or a dependency fails?
Yes ☐ No ☐ Where stated: ______________________
6. Plausible acquisition economics. Write the arithmetic: what you can afford per activated user, and what it would take for a channel to reach that. If you cannot write it, you are not ready to buy traffic.
Yes ☐ No ☐ Arithmetic: ______________________
Synthetic example header — NOT REAL
Synthetic and safe for practice only. Every domain and address below is reserved for documentation (example.com, example.net, 198.51.100.10). It is not real mail and describes no real sender.
Received: from mail.example.net (mail.example.net [198.51.100.10]) by mx.example.org with ESMTPS id DEMO-001; Wed, 16 Sep 2026 09:00:00 -0500 Authentication-Results: mx.example.org; spf=pass smtp.mailfrom=bounces@example.net; dkim=fail header.d=example.com; dmarc=fail (p=reject) header.from=example.com From: "Example Support" <support@example.com> To: analyst@example.org Subject: Synthetic training message — no real sender Date: Wed, 16 Sep 2026 09:00:00 -0500 Message-ID: <demo-001@example.com>
The mismatch this example demonstrates: the envelope comes from example.net (SPF passes), but the From header says example.com, so DKIM and DMARC fail for that domain. That gap between the sending domain and the visible From address is what a header tool is meant to surface.
If you paste this into a live header tool, the tool may look up the real DNS records for the domains, report the mismatch above, or attach a numerical risk score. Those outputs are artefacts of using invented data against live lookups. Any score a tool displays is not a stable or definitive verdict, and these outputs are not real threat findings and say nothing about any real sender.
Primary sources
- MailSleuth.ai — the product page for the case discussed in the episode
- Y Combinator Startup School videos — talking to users, launching early
- Google Search Essentials — what it takes to be findable at all
- Google Ads Help — conversion measurement reference
- Reddit Conversions Playbook for SMBs (PDF)