This is the post I was hoping I wouldn’t have to write yet, because the version of it I imagined writing was supposed to come after I’d figured something out. I have not figured something out. I’m writing it anyway, because the previous post in this series ended with a promise to write the failure-mode counterpart — what doesn’t work when you build around micropayments, what assumptions about user behavior turn out to be wrong — and the most honest answer to that question, two months into shipping Sats Channel, is that the assumptions about users aren’t the ones that are breaking. The assumption about getting users in the first place is.
The thesis, stated upfront so you can decide whether to keep reading: the belief that quietly shapes most independent product work — if it’s good enough, distribution will follow — is probably the single most expensive false belief in indie software. It’s expensive because it’s almost-true. There are real cases where it works, mostly cases where the product is solving an acute pain in a community that already has a place to talk to itself, and those cases get cited often enough that they form the lore of independent building. The lore is wrong on the median case, and watch-to-earn is one of the categories where the wrongness becomes mathematically inescapable. A product that pays its users from ad revenue does not function without users. The architecture I wrote up in the last post — the Lightning rails, the scraper, the active-attention checks, the 100-sat threshold — all of it works. None of it matters in the absence of traffic. I built the engine and I’m now realizing how much less I built of the on-ramp.
Here’s what I’ve actually tried so far, in roughly the order I tried them, with as much honesty as I can fit in a paragraph. Twitter/X was the obvious first move — short, frequent posts, threads when something interesting shipped, replies into adjacent conversations. The thing nobody tells you about Twitter as a distribution channel for indie work is that the algorithm is calibrated for engagement, not interest, and a thoughtful post about your product gets fewer impressions than a snarky reply to a viral account. I’m not great at being snarky on demand. Farcaster has been more receptive in tone — the community is smaller and skewed toward exactly the audience I want, technical people who are crypto-literate and interested in build-in-public — but smaller-and-skewed cuts both ways, and posts that should land well sometimes get fifteen impressions and a single thoughtful reply, which is great for conversation and bad for traffic. Friends and family I include because it’s honest, not because it’s a strategy; you can lean on this exactly once before it stops being available, and it generates the wrong kind of traffic anyway — people who want to support you, not people who want the product. Dev.to is what you’re reading right now, and I’ll come back to whether it’s working at the end of the post, because the answer is interesting.
The naive belief I walked in with, the one I’m now starting to identify as the actual root cause, was a stack of three smaller wrong assumptions that I held simultaneously without noticing how much weight they were each carrying. The first was that building in public would generate its own audience — that the act of being visibly thoughtful about the work would draw people to the work itself. The second was that the Bitcoin angle would carry the product to the Bitcoin community automatically — that the population of people who care about Lightning and watch-to-earn would, by virtue of caring, find me. The third was that the novelty of the inversion would do the marketing for me — that a product that pays users instead of charging them was strange enough to be self-propagating. All three of these have a kernel of truth, which is what makes them so dangerous. Building in public does generate audience, slowly, after you have an audience to build in front of. The Bitcoin community does find new products, eventually, after they’ve been validated by other people first. Novelty does compound, in environments where novelty is already being amplified. The kernel-of-truth is the trap, because these beliefs aren’t wrong, they’re insufficient, and insufficient beliefs are harder to disprove than wrong ones — every time the strategy underperforms, you can convince yourself you just need more time, more posts, more patience. Two months in, I can already feel the gravitational pull of that reasoning, and I’m writing this post partly to break it before another two months pass with the same shape.
What this is teaching me, and the part of the post I’m hoping might be useful to someone else at the same stage, is that distribution is not a separate phase of product work that follows building. It’s a parallel track that has to start at the same time and that needs the same architectural seriousness as the codebase. My mistake — the mistake I’m watching myself make in real time — was treating the build as the hard part and assuming distribution was a smaller problem I’d solve later with effort. Distribution is, for most independent builders, the bigger problem, and the right time to start solving it was approximately a year before shipping the first app. Audience is a multi-month-to-multi-year lagging asset. By the time you need it, it’s already too late to start building it. The builders I see succeeding in this category are almost always builders who spent two or three years writing publicly, posting consistently, building relationships in specific communities — not because they were strategizing about future products, but because they happened to have an audience already when they shipped. The audience-first builders make it look like the product was the lever. The product-first builders, like me, are discovering that the lever was the audience the whole time.
The honest answer to “what’s working” is early signal is mixed. Dev.to has been the most receptive of the channels I’ve tried, which I think is because the posts in this series are doing real teaching rather than pitching, and dev.to’s culture rewards that specifically. That’s part of why this post exists — the platform that’s been most generous with attention deserves the most honest post I can write, not the most optimistic one. But “most receptive of the channels I’ve tried” is a low bar when none of the channels are converting at scale, and I’d be lying if I said the dev.to posts have moved Sats Channel’s metrics meaningfully. They’ve moved my thinking meaningfully, which is the thing I came here for and the thing I’d recommend other indie builders use writing for, but the conversion from reader to user is brutally low and I don’t have a clever solution to share. If you’re reading this and you’ve solved this problem, the comments are open and I will read every reply.
What I’m trying next, which I’m flagging because the next post in this series will probably be a follow-up to this one with whatever I learn: I’m starting to think the answer isn’t more marketing channels but fewer, deeper ones. I’ve been spreading thin because spreading thin felt safe — every channel was a hedge against the others — but the result is that I’m a marginal voice on five platforms instead of a meaningful voice on one. The next experiment is to pick a single community and become a real participant in it, contributing without an agenda for long enough that when I do mention what I’m building, the people hearing it know me already. Whether that works, I don’t yet know. I’ll write that post when I have an answer.
Closing thought, because every post in this series has had one. The architecture posts I wrote earlier — the Oracle ARM tier, the Base payments rail, the Lightning revenue loop — were easy to write because the technical decisions had clear right answers and I could explain why I made them. The post you just read is harder because there isn’t a right answer yet and I’m in the middle of looking for it. If you’re a builder who’s further along this curve than I am, I’d genuinely value your perspective in the comments. If you’re a builder who’s at the same stage, this is the post I wish someone had written for me eight weeks ago, and I hope it saves you a few of the weeks I’ve already spent. Either way, the catalog is at quackbuilds.com and Sats Channel specifically is at quackbuilds.com/thesatschannel — and yes, I’m aware that the post about distribution failure is itself an attempt at distribution. The recursion is the joke and also the entire problem.
— @itsevilduck / quackbuilds.com