How to Market a Vibe-Coded App (Validate It Before You Buy Ads)

Building the app got cheap. Finding out whether anyone needs it did not. This is the sequence to run before you put money into ads: state the job, watch real people do it, record what happened, define what counts as success, and only then test a message.

Open the App Validation & First-Users ScorecardFree. No account, no email. Opens in a new tab — print it or save it as a PDF.

Direct link: /downloads/vibe-coded-app/app-validation-scorecard.html

Before you read on

Marcus Bennett is an AI-created educational host. Examples are illustrative; results vary. Nothing here reports campaign performance, and no figure on this page is a benchmark.

Step one

Write the job statement

One sentence with specifics in every slot. If you cannot fill a slot, that is the thing to go and find out.

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].

The last slot does the most work. “Saves time” is not observable. “They can paste a header and tell their manager which check failed and why” is.

Step two

Ask about the last real occurrence

Behaviour, not opinion. Asking 'would you use my app?' is less reliable than watching what someone did the last time the job came up.

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? Which part took the longest?
What went wrong, or nearly went wrong, because of how long it took?
Who else got pulled in, and what did you have to send them?
How many times did this happen last month?
Have you looked for something to make this easier? What did you try, and why did you stop?
Can you show me the whole thing, with anything sensitive removed?

Sanitized walkthrough rule. Ask people to redact before they share, or hand them synthetic data. Never ask someone to paste a real customer record, credential or internal header into your app to prove a point.

Step three

Keep an evidence log

One row per real person. Fill it in from what you saw, not from what they said they might do.

Role: Who they actually are, in their setting.
Trigger: The event that started it, with a date.
Workaround: What they do today without you.
First useful result: The outcome they could show someone.
Confusion: Where they hesitated, guessed or asked you.
Return: Did they come back later, unprompted?

“Return” tells you whether the job recurs — but judge it against the job’s natural frequency. Coming back weekly means little for a task that happens once a year; coming back at all for a rare task is a strong signal. Match the window to how often the trigger actually occurs.

Step four

Build the audience matrix

Each row is a person you could actually reach, with a promise they could call wrong.

Role: The person, not a segment name.
Trigger: When the need appears.
Testable promise: A claim they can call wrong in a minute.
First action: The single thing they do on arrival.
Discovery channel: Where that person already goes.

Step five

Define activation and repeat use

Clicks are arrivals. Activation is a completed useful outcome. Write both down before you measure anything.

Click

Someone arrived. It tells you a message got attention. It tells you nothing about whether the app worked.

Activation

The first completed useful outcome, inside one session — the user got the thing your job statement promised, and the event fires at that moment, not on page load.

Repeat use

Activation again, on a later calendar day, inside a window you stated in advance. Pick the window from how often the trigger actually happens — the interviews tell you that.

Step six

A small ad test — hypothetical example

Two audiences, two message angles, four cells. Shown here as a planning shape, not a result.

This matrix was not run. The audiences, angles, caps and signals below are placeholders to show the structure of a test. No campaign described here was run, and no performance is implied. (Tunde says he separately tested Reddit ads for MailSleuth — that is his account, not a result we report.)

Cell	Audience	Angle	UTM	Cap	Signal
A1	Audience A	Angle 1 — name the trigger	utm_campaign=validation-v1&utm_content=a1-aud-a-angle-1	$__ total	Completed use
A2	Audience A	Angle 2 — name the outcome	utm_campaign=validation-v1&utm_content=a2-aud-a-angle-2	$__ total	Completed use
B1	Audience B	Angle 1 — name the trigger	utm_campaign=validation-v1&utm_content=b1-aud-b-angle-1	$__ total	Return within window
B2	Audience B	Angle 2 — name the outcome	utm_campaign=validation-v1&utm_content=b2-aud-b-angle-2	$__ total	Return within window

Every cell gets a distinct utm_content, its own spend cap and a stop date decided before launch. Judge cells on completed use and return — never on clicks or impressions. Google’s own conversion documentation and Reddit’s SMB playbook, both linked below, are the references for wiring those signals up.

Step seven

Six gates before you scale spend

These are checks before you increase or scale paid marketing. A modest, capped learning test is fine before all six are clear — the gates gate scaling, not the first exploratory spend.

1Product reliability
The core path completes every time, on a phone, for someone who has never seen it. Not "usually".
2Result comprehension
A first-time user can say in their own words what the result means and what to do next.
3Accurate activation measurement
Your activation event fires on the completed outcome, and you have watched it fire end to end yourself.
4Repeat-use window
You have written down the window — 7 days, 30 days — and you can see returns inside it.
5Privacy and availability honesty
The page states what data is sent where, what is stored, what is not, and what happens when a dependency fails.
6Plausible acquisition economics
You can write the arithmetic for what you can afford per activated user. If you cannot write it, you are not ready to buy traffic.

Case

MailSleuth.ai

A real, attributed example of a narrow tool built by the person who has the problem.

Tunde, an Email Engineer, built MailSleuth.ai for email-header troubleshooting — his own daily work. He says he tested it with coworkers and with Reddit ads. That is his account of how he looked for users; we are not reporting what those tests returned.

What is publicly observable on the product today: you can paste a raw header, get an AI explanation of it, see authentication and route indicators, and reach related DNS tools. That is a clean job statement made visible — the person, the trigger, and a first useful result you can show a colleague.

We make no claim here about user numbers, revenue, what the Reddit ads produced, or any app-store or add-in listing. No testimonials are quoted. Anything not listed above as publicly observable is outside what we checked.

A synthetic header you can practise with

Synthetic and safe — not real mail. Every domain and address below is reserved for documentation: example.com, example.net and 198.51.100.10. It describes no real sender and no real incident.

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 the thing a header tool is meant to surface.

If you paste this into any live header tool, the tool may look up the real DNS records for those domains, report the mismatch above, or attach a numerical risk score. Those outputs are artefacts of running 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. They say nothing about any real sender.

Primary sources

MailSleuth.ai — The product page for the case discussed here
Y Combinator Startup School videos — Talking to users and launching early
Google Search Essentials — What it takes to be findable at all
Google Ads Help — conversion measurement — Reference for what a conversion actually records
Reddit Conversions Playbook for SMBs (PDF) — Reddit's own guidance for small advertisers

Optional

Get new episodes and resources by email

Completely optional. The scorecard downloads without it.

Educational content only — not financial, legal, tax or career advice. Marcus Bennett is an AI-created educational host. Examples are illustrative; results vary.