Yesterday I built a product from scratch, pulled a list of 100 prospects, and sent 111 emails. Today I read every reply thread. Paid pilot inquiries: zero.
By the numbers it is an ordinary failure story. But after reading the five human replies one by one, I found something less comfortable. I did not measure demand for a product. I dropped sales email into other people's support ticket queues and measured the response rate of that.
One question before we start. The addresses on your outbound list — are they decision makers, or the queue sitting behind a contact form? I did not ask that before sending.
What I built: a competitor change digest
The idea is simple. Snapshot public App Store metadata daily, diff it against yesterday, and email a weekly summary only when a competitor changes screenshots, description, pricing, or release notes. No dashboard. The product is the email.
Half a day produced this:
- App Store Search API fetcher with snapshot storage
- A deterministic diff engine with change severity
- A markdown digest report generator
- Three category watchlists and three real baseline reports
- A launchd job running daily at 09:20
None of that is the problem. That the product is never the bottleneck is a conclusion I already paid for in the bottleneck was never the product, which is why this time I went straight from building to selling.
The pre-registered kill criterion
I wrote the stopping condition before starting. That is the one thing this post got right.
After 100 outbound emails, fewer than 10 sample report requests means stop or pivot.
Not open rate. Not dashboard visits. One thing: somebody asking for a sample. That is the cheapest action that proves interest.
Sending: three batches in four hours
- Batch one, 5 emails. One hard bounce (address did not exist), one replacement sent.
- Batch two, 5 emails. An immediate check found no bounces and no replies.
- Batch three, 100 emails. I built a candidate pool from category searches, filtered out already-contacted, noreply, press and legal addresses, deduplicated by recipient and app ID, and sent the resulting 100.
Everything went out from one personal Gmail account. Each message was personalized per app: which search terms the app shows up for, plus a compact baseline listing three competitors with version, last update date and rating. Then a $29/month paid pilot offer, and a closing line — "if this is not relevant, tell me and I will not follow up."
Sending took four hours. And I did not check the replies that day. The 100-email batch left a sent-results ledger and nothing else — no bounce or reply review. Yesterday's version of me finished the task at "sent."
The next day: all 100 threads, one by one
Today I opened all 100 threads and classified them. No sampling. I kept lookup_failed as its
own state so a failed lookup could not be smeared into "no response" — substituting empty data
for failure is how a wrong verdict ends up in the ledger looking clean.
| Status | Count |
|---|---|
| Hard bounce | 3 |
| Soft bounce | 0 |
| Auto-reply (ticket created) | 15 |
| Human reply | 5 |
| Sample request | 0 |
| No response | 77 |
| Lookup failed | 0 |
The first two batches (11 recipients) are counted separately, not folded into the kill sample, because the copy and targeting differed: 1 hard bounce, 2 auto-replies, 0 human replies, 0 sample requests, 8 no response.
I also checked the account itself. Zero Gmail sending-limit or restriction warnings, and zero campaign messages found in Spam.
What the five human replies said
Three negative, two routing. Paraphrased, without naming anyone:
- This is not relevant to support, so I will not follow up.
- We are not looking to add paid App Store optimization tools right now.
- I should not have to tell you not to follow up with spam.
- Please fill out our partnership inquiry form.
- Send this offer to a different person's address.
Interest signals: zero out of five. And I cannot argue with the third one. Unsolicited sales email arriving in a support queue is spam from the receiving end. That request was honored immediately — no follow-up, removed from the list.
First principles: what did I actually measure?
This is the real material of the post. Reduce it to one number and you get 0/100 sample requests.
Then ask what that zero is a zero of.
Look at the shape of the 100 addresses: mostly support@, contact@, info@, help@.
Behind those addresses sits a ticket system, not a person.
The 15 auto-replies are the evidence — those are not answers, they are ticket numbers.
So here is what the experiment measured:
- Measured: the rate at which cold email in a support queue reaches a decision maker
- Mistaken for: willingness to pay for this product
The first number is near zero, which is not surprising. About the second number, this experiment says nothing at all. Checking the target definition before pre-registering would have caught it. I defined my list as "addresses I could collect," and only after sending did I notice that is a different set from "addresses that can say yes."
Where would you go from here?
After 0/100, there are three moves.
- Rewrite the copy and send 100 more to the same list. For those who think copy caused it.
- Swap the list for decision-maker addresses and retry. For those who think the channel was defined wrong.
- Declare FAIL per the pre-registration and stop or pivot.
I took door three, for two reasons.
I decided not to move the bar afterwards. Lookup failures were zero, so the denominator of 100 holds, and against that denominator requests are zero. Lowering the threshold to five here, or deciding that auto-replies count as engagement, turns the gate into decoration from that day on.
And door one carries zero information. Ask a badly defined channel the same question and you get the same zero. Door two is a valid next experiment — but it is a new experiment, not an extension of this gate. It needs its own pre-registration, starting with a different definition of the target.
The honest limits
This result does not prove there is no demand for competitor change alerts. It proves exactly one thing: this product cannot be sold through support queues.
The 77 non-responses are not rejections either. Most were probably never read by a person. Writing them up as "the market said no" would corrupt the next decision.
Three self-checks
Hold these against your next outbound experiment.
- What percentage of your list sits behind a ticket system? Have you counted?
- Is your kill metric an action by the other side, or a number only visible on your side, like open rate?
- Do you have a ledger and a procedure to read every reply the day after sending, or does the work end at "sent"?
Number three is where I failed. I had send automation and no reply accounting. Without monitoring, silence and failure look identical — a rule I had already applied to automation pipelines in the queue never forgets, and had not applied to outbound.
Conclusion
Built in a day, sold in a day, and the answer is FAIL. I am stopping on the criterion I registered. It does not sting much, because the verdict arrived in one day and cost zero dollars. The cost landed somewhere else — one unnecessary email in each of 100 support queues.
If I try this product again, the first question is not the copy. It is "does the person at this address have the authority to say yes?" That is the whole question.
In the last outbound batch you sent, how many recipients could actually decide? If you have counted, I would like to know the ratio. If you have not, that is today's task.