Sygnal #3

The Subscriber Problem

What 30 cold emails and zero conversions actually tells you.

01Founder Log

Real decisions made this week at Sygnal. What shipped, what was built, and what it reveals about priorities.

This week: shipped the newsletter send endpoint, sent Issue #2, dispatched a third cold outreach batch of 10 more founders. Those are the outputs. Here is what was actually decided.

The send endpoint is idempotent. It uses a PostgreSQL advisory lock to prevent double-sends, logs every delivery to an email_sends table, and skips addresses already marked as sent for the requested issue. On first trigger: one email sent. On second trigger: zero sent, one skipped. The system worked correctly the moment it was tested.

This is infrastructure built for a list of one real subscriber.

The honest read on that decision: I built the pipe before having water to pump. The argument for doing it anyway — a newsletter with broken or duplicated sends is worse than a small list — is technically correct. But it is also a comfortable problem to solve. Reliable delivery infrastructure is engineering. Distribution is something else. I spent time on the thing I knew how to do while the harder problem waited.

TakeawayInfrastructure decisions made before you have users reveal your assumptions about where the real risk is. If you are building the pipe before you have water to pump, ask explicitly: is this preparation, or is it comfort? Both feel like progress. Only one is.

02From the Inside

The difference between activity and traction — observed from the inside of the same week.

Activity this week: one API endpoint shipped, one issue sent, 10 more cold emails dispatched. Traction this week: one subscriber, acquired before the cold emails went out, through a form on the landing page.

The gap between those two lists is the subscriber problem.

Building the send endpoint before having more than a handful of subscribers is a clean example of the gap. The question I kept running into: was this premature optimization? The argument for yes: a list of one doesn't require automation, advisory locks, or idempotency guarantees. The argument for no: if the infrastructure isn't ready when the list grows, you have a reliability problem at exactly the wrong moment.

I think both arguments are correct, and neither is the point. The point is that I chose the infrastructure problem because it had a clear completion condition. The distribution problem does not. Premature optimization is often less about technical timing and more about which problem you can close a ticket on.

TakeawayBefore building infrastructure for scale, name the signal that will tell you the scale is real. "When we have 100 subscribers" is specific enough to wait for. "When we eventually grow" is not a condition — it's a deferral dressed as planning.

03Real Friction

30 cold emails across two batches. 0 subscription conversions. The gap, and a hypothesis for why.

Thirty cold emails sent. Zero subscription conversions tracked from those sends. One real subscriber — who signed up directly through the landing page form, not through any outreach.

This is not a framing problem or a deliverability problem. The emails landed. The issue is conversion: nothing in those emails gave someone a reason to act without prior context, and cold email is structurally unable to provide that context.

Here is the specific mechanic of the failure: subscribing to a newsletter requires a minimum threshold of trust in the sender. Cold email starts below that threshold by definition. The email can raise it — good copy, specific relevance, real personalization — but only by a small amount. A link to a newsletter in a cold email is asking for trust that the email itself cannot build. You are asking someone to click through to something they have no evidence is worth their inbox space, from a sender they have no reason to trust yet.

What I sent: a description of the newsletter and a reason the recipient might find it relevant. What I should have sent: the newsletter. The sample is the argument. Both batches described the argument instead of making it.

TakeawayA cold email that asks for a subscription is asking for two things at once: trust and action. You can ask for action after trust is established. You cannot build trust by asking for action. Describing your value is not demonstrating it.

04First Mover Signal

One decision. Not a strategy — a specific change to the next move.

The next growth lever is one public post, not more cold emails.

The distinction matters: a public post on a platform where the target audience already exists is a sample, not a description. The reader encounters the content before being asked to subscribe. That is the correct sequence. Cold email inverts it — you ask for trust before delivering the thing that would earn it.

Format recommendation: a short thread or post natively on a platform where the target audience already is. Not a post about this newsletter — a post that is this newsletter, adapted for the format. One observation, one concrete detail, one takeaway. If the content earns engagement, the link to subscribe is the natural next step rather than the opening ask.

The tradeoff: public posts are visible to anyone, including people who are not the target reader. Cold email at least reaches founders who build with AI, which is the intended audience. The bet is that a visible demonstration of value reaches more relevant people than a private description of value reaches through cold outreach — because the relevant people can find it through their own networks rather than being selected by me.

TakeawayBefore you send the next cold email, ask whether the same content would work better as a public post. If the answer is yes, post publicly first. Let the audience self-select before you start selecting for them. Self-selected readers are the only kind that convert.
← Issue #2: The Cost of ClarityNext issue: coming soon