Distribution for Solo Builders: Your Readers Can't Be Copied

I wasted years on this one sentence

“If the product is good enough, people will come.”

I believed that line for years. It fits the engineer’s worldview: code is verifiable, performance is measurable, and there’s an objective difference between good and bad. If the difference is objective, then the good thing winning is just a matter of time — the market is efficient, it just needs a while.

That was my logic through my open-source years. Write the project well, keep test coverage high, take the docs seriously, and then wait. Wait for stars, wait for issues, wait for someone to mention it in a blog post somewhere. Sometimes the wait paid off. More often it didn’t. And every time it didn’t, my first reaction was the same one: the thing isn’t good enough yet, go back and keep improving it.

That’s an extremely comfortable attribution. It collapses every problem into the one layer I’m best at — writing code. It lets me keep doing, with a clear conscience, the thing I wanted to do anyway, while dodging the thing I didn’t want to do: going out and telling people what I built.

It took me a long time to see that the attribution structure itself was the problem. It isn’t diligence. It’s a sophisticated way of using what you’re good at to avoid what you’re not.

And what makes it lethal is that the line really did hold some truth in the past — which is why it’s so hard to falsify.

The conditions under which that line used to hold

“If the product is good, people will come” isn’t pure self-deception; there was an era when it worked. The condition it worked under is a hidden premise: good products themselves were scarce.

When many software products required more time, coordination, and capital, the number of things that got built — and built well — was limited. That limit itself was doing some filtering. A genuinely useful tool showing up on GitHub often had fewer near-identical alternatives around it and could carry more attention of its own.

In that era, “making the thing good” was both a product move and a distribution move. They were fused into one act, so you never had to think about distribution separately.

That premise has weakened.

For many software products, AI-assisted development and managed infrastructure have made prototypes cheaper to produce. That does not make good products abundant in every market, and it certainly does not make reliable operation, security, support, or domain knowledge free. It does mean that a working demo is less distinctive than it used to be. Someone else can often reach the same visible feature set with similar tools.

Scarcity did not disappear. More of it moved from implementation toward attention, relevance, and trust.

That’s the bounded version of the line from the series overview : in many software categories, a working product is less scarce than it used to be, and discovery can become the tighter constraint.

Let me put it more harshly: a good product with no path to discovery can look, from the market’s side, like a product that does not exist. The code is real; the value may be real; the consequence is still near zero if the people with the problem never encounter it.

Why distribution can become an asset

The overview gave a test, and let’s run distribution through it once more:

When this layer of gear improves, does it help only me, or does it help all my competitors at the same time?

The production layer often struggles with this test. A broadly available model upgrade can lift many builders at once, so the durable advantage usually lies in workflow, domain context, or judgment rather than access alone. The judgment layer half-passes — part of it can be externalized into rules, part of it can only grow inside your head.

The distribution layer passes more cleanly than the production layer, but only if I am careful about what I call an asset.

No model upgrade, ever, will backfill for someone else the readers you spent three years accumulating.

That’s the most essential property of this layer. Tools can accelerate research, editing, syndication, and paid reach. They cannot retroactively create a history in which the same person repeatedly made useful claims and was later proved right. Audience and trust are partly functions of time and verification.

Tools can compress the work around that process. They cannot remove the need for the process.

Imagine posting the same article from a fresh account and from an account with three years of useful work behind it. The response will probably differ, but the size of that gap depends on the platform, topic, timing, and whether the older audience is still relevant. I should not pretend there is a universal multiplier.

What accounts for the gap? Not content quality — the content is the same. The gap is earned familiarity. The three-year account’s readers already know “what this person writes is usually worth finishing,” so they’re willing to spend the first minute of attention. The new account has no such history; every post has to prove from zero that it deserves to be read, and in an environment of information overload, most content never gets that first minute at all.

That prior is built through time, consistency, and evidence. Exposure can be bought; an audience can sometimes be acquired; neither automatically transfers belief. This is why I distinguish rented reach from an owned relationship. A follower count belongs partly to a platform. A useful archive, direct subscribers, repeat visitors, and a reputation that travels with your name are closer to durable assets.

Cheap production changes the distribution problem

Now for what I consider the most important mechanism in this essay. Most people see AI’s first-order effect on content: some kinds of production got cheaper. A plausible second-order effect is more competition for finite attention. It is a mechanism to test, not a law of nature.

The marginal cost of drafting text, rough graphics, and basic edits fell sharply for people who use these tools well. Research, judgment, verification, permissions, and taste did not fall to zero.

Because many people can publish more material, the supply of plausible content can grow quickly. Reader time remains limited.

When supply grows faster than a reader’s available time, the cost of earning sustained attention can rise. The “price” here is not a universal CPM; it is the work required to get the right person to notice, continue, and act.

     Some production costs ↓            Reader time stays limited
   (models accelerate drafts)           (only so many hours in a day)
            │                                   │
            ▼                                   │
     ┌───────────────────┐                      │
     │ Plausible content  │                     │
     │ supply grows       │                     │
     └──────┬────────────┘                      │
            │                                   │
            ▼                                   ▼
     ┌────────────────────────────────────────────────┐
     │  Qualified attention may become harder to earn   │
     └──────┬─────────────────────────────────────────┘
            │
            ├──► Cold starts get harder: new content struggles for the first minute
            │
            ├──► Existing assets appreciate: accumulated trust becomes the scarce good
            │
            └──► Hypothesis: discovery and proof matter more

The most interesting possibility in this diagram is the lower-right one: as generic production gets cheaper, credible provenance may become more useful.

Because when everyone can produce content, the question “who produced this” gains weight. Readers can’t read everything; they have to filter, and the lowest-effort filter is provenance — I know this person, I’ve read their stuff before, so I’ll read them first.

That does not prove AI always reinforces incumbents. Recommendation systems can also introduce unknown creators, and a new account can still earn attention with exceptional relevance. My narrower claim is this: when readers face too much plausible-looking material, a history they can inspect becomes a useful filter.

I don’t think that’s a good thing. What I can control is narrower: leave a useful, inspectable record and make it easy for the right reader to find.

The fly.pieter.com story is useful precisely because its popular summary is too clean. In Levels’ retrospective and archived launch posts , he says he started the game on February 22, 2025, built it mostly in public, and reached a $1 million annual run rate after 17 days. Launch snapshots also reported a prototype built in roughly three hours, 320,000 players, and about $87,000 in monthly revenue. These are founder-reported figures, not audited accounts.

The distinction matters: an annual run rate is not a million dollars collected in 17 days, and a short launch window does not establish durable recurring revenue. Sponsorship inventory and in-game placements also do not behave like a conventional subscription. A dramatic number is not improved by removing its denominator.

The defensible lesson is narrower than the legend: Levels launched in front of an audience that had watched him build products in public for years. That existing reach plausibly helped the game escape a cold start. It does not prove that distribution caused all of the revenue; novelty, product quality, timing, social sharing, and sponsor demand also mattered.

The three-hour prototype shows production leverage. The launch shows production leverage interacting with accumulated reach.

I used to describe his many prior projects as if every failed attempt automatically became an audience deposit. That is too romantic. A public failure becomes an asset only when its record is useful, honest, and retrievable. Publishing noise does not compound merely because it is public.

The failed project can go to zero. A good record of what failed, why, and what changed can retain value.

Revenue data cannot tell us why a product failed

One old dataset is still useful, as long as I do not ask it to answer a question it never measured. In July 2022, ScrapingFish published an analysis of 937 Indie Hackers products with Stripe-verified revenue . More than 54% reported no revenue, while about 5% exceeded roughly $8,333 in monthly revenue.

This was a platform snapshot, not a representative census of solo software businesses. It included founders who chose to list products and connect revenue, mixed categories and business ages, and measured revenue rather than product quality, audience size, or cause of failure. Projects abandoned before listing were absent, but that does not tell us how adding them would change every relevant rate.

This number usually gets used to talk people out of trying, and I think that’s the least interesting reading. The question I care about is a different one: of that 54%, how many failed because the product was bad, and how many because nobody knew it existed?

The dataset cannot give that split. My experience says discovery is often the neglected variable, but that is a working diagnosis, not the study’s conclusion. Product usefulness, pricing, timing, retention, sales, and distribution are entangled.

So I now ask a falsifiable question: can I reach 100 people who plausibly have this problem, and can I observe what they do next? If I cannot reach them, I have a distribution problem. If they arrive and do not activate, I probably have a product or message problem. If they activate and leave, I have a retention problem. Calling every failure “distribution” is just the mirror image of calling every failure “the code.”

Why I treat “AI slop” as a distribution tax

As more polished material appears, I have changed how I filter it. When an article is well-structured, logically clean, and perfectly inoffensive, polish alone tells me little about who did the work, checked the claim, or will stand behind the conclusion.

My low-effort heuristic is: does this passage read like it came from a specific person, and does it give me something concrete enough to inspect?

That is not a reliable AI detector. Human prose can be generic; generated prose can imitate a voice. It is simply a reading decision: if the opening says everything correctly and nothing specifically, I close the tab.

So I treat “AI slop” primarily as a distribution problem, with aesthetics as the surface symptom. Content carrying that flavor has to work harder to earn my attention. Whether the same heuristic holds for a wider audience is a hypothesis, not a measured fact here.

Word substitution is a common response, but it misses the real problem. “Empower” becomes “help,” “deep dive” becomes “let’s talk about,” and the model gets told “no parallel constructions.” Those are surface edits. The result can still be an article with no author, just wearing a different skin.

A durable response is to publish the part you can support with your own evidence.

Concretely:

• First-hand failure details. Not “this approach has some gotchas,” but “I was stuck here for two days because I assumed X was Y, and it wasn’t.” A model can fabricate either sentence; a commit, issue, benchmark, or dated note can support the second.
• Concrete numbers, especially the ugly ones. How many people actually use your project, how much money you spent, how much time, what you gave up. Numbers are easy to invent, so attach a method, date, denominator, or artifact when the claim matters.
• The hesitation you felt at the time. What you agonized over between two options, why you picked the one you did, whether in hindsight you picked wrong. Generated drafts often sound “already figured out” because they arrive as finished prose. Human thinking leaves traces, and the traces themselves are the ID card.
• The detours. Especially the ones that look stupid to you now. Vulnerability can make a piece human, but it is not proof by itself. The value is the decision trail another builder can inspect and reuse.

A more honest self-check is to mark every paragraph that contains an inspectable source, a concrete decision from your own work, or a trace another reader could verify. If removing those paragraphs leaves the argument almost unchanged, the draft still needs more grounded material.

None of this means don’t use AI for writing. I use it heavily. The difference is the division of labor: let the model handle structure, grammar, pacing, translation, expansion — but the specificity only you have must be placed in by your own hand. The model is the editor, not the author. It can make your material read better; it cannot live your experience for you.

Turn the act of building the product into content

This is a structural distribution advantage a solo builder often has, and I think it is badly underrated. A good team can design the same proximity between builders and writers; an individual gets it by default.

In many teams, “the person who builds” and “the person who writes” are separate people. That handoff can create information loss and delay: the engineer finishes, marketing asks what happened, the engineer explains, the write-up comes back for review, and several rounds later two weeks are gone. What finally ships can become abstract, correct, and boring because concrete, flavorful, slightly awkward details get sanded off in transit.

An individual loses less to this particular handoff. The builder and the writer are the same person, so details can still be fresh and unpolished by a relay.

This structural advantage doesn’t cash itself in automatically. You have to deliberately design a pipeline for it, or the details simply decay in your head.

The overview said the four layers have a direction: the output of layer four should settle downward into assets for layers two and one. At the distribution layer, that pipeline looks like this:

   Layer 4 · one delivery from the production layer
   (a feature / a refactor / a pitfall / an abandonment)
            │
            ├──► Leave traces on the spot (the step easiest to lose)
            │      · Decisions: why A and not B
            │      · Blockers: where, for how long, how you got out
            │      · Numbers: time spent, cost, before/after performance
            │      · Detours: the ones that look stupid in hindsight
            │
            ▼
    ┌────────────────────────┐
    │  A rough pile of raw    │  ← readable only to you; don't aim for prose
    │  material               │
    └─────────┬──────────────┘
              │
              ├──► One deep long-form piece (the source; your home turf; retrievable long-term)
              │        │
              │        ├──► Short form: conclusion + one diagram (social platforms)
              │        ├──► Long form: add background + data (technical communities)
              │        └──► Dialogue form: break it into concrete questions (Q&A venues)
              │
              └──► Layer 1 · reputation layer: the consistent public output itself
                        │
                        └──► Feedback: the next product's cold start costs less

The key is the first step: leave traces on the spot.

Every step requires judgment, but this one is most easily skipped. In the moment of building, these details feel too trivial to record — and you’re certain you’ll remember them.

You won’t. Three weeks later all you’ll remember is “it got solved eventually.” The specificity that made the content valuable — what exactly you assumed at the time, what you tried, why the attempt was wrong — is all gone. What’s left is the abstract, correct, boring version a lossy handoff can produce. Your structural advantage is lost right at this step.

My method is crude: one plain-text file, and while working I toss sentences into it as they come — no fluency, no completeness, only the specificity of the moment. The file is legible only to me. When it’s time to write, it’s the raw material — and raw material nobody else could possibly have.

Once you have the raw material, AI can accelerate many downstream steps. Without evidence-rich material, it mostly makes generic output arrive faster.

Repurposing saves friction, not expression

Turning one source piece into different shapes for different platforms genuinely got much easier after AI. That’s a real efficiency gain, worth taking.

But I want to draw an honest boundary here, because this thing has been oversold.

Cross-platform repurposing lowers friction. It does not replace platform-native expression.

Every platform has its own grammar — not just length limits, but rhythm, how you open, the reader’s state of mind on arrival, what sounds natural here and affected elsewhere. A passage that unfolds beautifully in a long essay, chopped into short lines on a fast-scroll platform, reads as verbose; a judgment that lands sharp on a short-form platform, dropped into a long essay, reads as glib and unargued.

The part that genuinely automates is repackaging information: extracting conclusions, changing length, adjusting format, translating. Hand those to the model, no problem.

The part least safe to automate blindly is how this should be said in this context. That takes felt experience of the platform — spending time there, reading how people talk, and noticing what gets ignored.

So my verdict: repurposing is a labor-saving tool, not a distribution strategy. It lets you spend less time on channels you’ve already chosen; it won’t choose channels for you, and it won’t build presence for you in a place you don’t know at all.

For an individual, the more realistic setup is: one home turf only — the place you fully control, where content persists long-term and stays retrievable (for me, this blog); every other channel is a tributary, each speaking its own language, all pointing back home.

Choose channels by function, not fashion

“Be everywhere” is advice for a company with a media team. A solo builder needs a portfolio small enough to maintain when the product is on fire.

A useful first step is to separate channels by function:

A reasonable default for a solo builder is one owned home, one owned relationship, and one discovery or community channel. Add another only when the first three have a repeatable cadence. The platform name is deliberately absent from the rule; platform features and policies change faster than the underlying function.

The choice can be scored with five one-to-five ratings: audience fit, content half-life, control, feedback speed, and weekly maintenance cost. The first four are benefits; maintenance is a cost. A channel with enormous theoretical reach and no audience fit is still a bad channel.

Build a minimum attribution loop

Distribution without measurement becomes superstition. Perfect attribution is unavailable — dark social, copied links, privacy controls, multiple devices, and model-mediated discovery all break the chain — but a modest loop is enough to improve decisions.

For each source article or launch, record:

1. Baseline: the previous four comparable pieces, not the best piece I ever published.
2. Exposure: qualified impressions or community views, where the platform exposes them.
3. Visit: sessions to a dedicated canonical URL, using restrained UTM parameters for channels I control.
4. Owned relationship: RSS follows, confirmed email subscriptions, or returning readers.
5. Activation: the first product event that demonstrates value, defined before launch.
6. Outcome: retention, a useful reply, a contribution, or revenue — whichever the work was meant to create.

Review at 7, 30, and 90 days. Seven days catches message and channel fit. Thirty days catches search, referrals, and delayed reading. Ninety days tests whether the piece became a durable entry point.

A compact record is enough:

source_id:
hypothesis:
audience:
channel + variant:
published_at:
7d / 30d / 90d: visit, owned relationship, activation, outcome
what changed next:

UTM tags are not permission to follow a person everywhere. Prefer aggregated analytics, short retention windows, and first-party events tied to a declared purpose. When a reader says “I found this through an AI answer” or a private share, record it as self-reported evidence, not as precise causal attribution.

The endpoint of distribution now includes a context window

In 2026, some discovery journeys include a generated answer between the reader and the source. A model may retrieve a page, summarize it, cite it, cite the wrong page, or omit sources entirely. That is a real surface, but it is not a stable funnel.

The MCP ecosystem itself expanded substantially. On December 9, 2025, the official MCP project reported more than 10,000 active servers and first-class support across major AI platforms . The same announcement says MCP joined goose and AGENTS.md as founding projects of the Linux Foundation’s Agentic AI Foundation. Those facts establish broad protocol adoption. They do not measure generated-answer discovery, establish that every model reads the open web, prove citations are reliable, or show that a citation creates trust or conversion.

So I treat model visibility as an unattributed discovery signal:

• A citation may create an impression without a click, but I cannot infer what the user believed.
• A click from an AI product is measurable when a referrer survives, but referrer data is incomplete.
• Citation presence varies by model, prompt, location, date, and retrieval index.
• A citation can misrepresent the source. It is not an endorsement from a neutral third party.

I won’t unpack the mechanics here — I have an entire GEO column for that. At the distribution layer, three practices remain useful even when no model is involved:

Write sections with explicit scope. A paragraph should say what population, date, version, or conditions a claim applies to. That helps a human reader and reduces damage when a passage is excerpted.

Put evidence beside the claim. Link the primary source, describe the method, and distinguish observation from inference. A confident sentence without boundaries is easier to repeat and easier to repeat wrongly.

Preserve a canonical source. Give the page a stable URL, visible date, author, and update history. Republished variants should point back to it. If an answer engine surfaces the work, I can monitor samples manually, but I do not call the result a conversion until a person takes an observable step.

This is less romantic than “citations produce trust.” It is also more useful. The objective is not to charm a model. It is to make the truth survive one more intermediary.

Distribution has ethical and security boundaries

Reach does not excuse abuse. Before turning product work into content, remove secrets, credentials, private URLs, customer data, internal prompts, exploit details that would create immediate harm, and metadata that can identify someone unintentionally. Screenshots deserve the same review as prose.

Also ask whether the story is yours to tell. A customer incident, private message, user quote, or teammate’s mistake needs permission or meaningful anonymization. “Building in public” is not a waiver signed by everyone who touched the build.

On external platforms, follow the community’s disclosure and self-promotion rules, label sponsorships and affiliate relationships, and avoid automated posting that manufactures engagement. Repurposing should adapt a source to a context; it should not flood five communities with the same payload. If a platform prohibits scraping, bulk messaging, or synthetic engagement, a clever automation does not make the behavior legitimate.

The safety test is simple: would I still publish this if the person described, the platform moderator, and a future security reviewer read it together? If not, the distribution plan is borrowing reach against a debt I will eventually pay.

Now for the part that doesn’t sound nice

I don’t want this essay to read like motivation, so the hardest part of the distribution layer has to be stated plainly.

Distribution can compound, but its ramp-up is often long, noisy, and short on decisive feedback.

That’s its most counterintuitive property. We tell exponential-growth stories after the curve is visible; from inside the early period, a compounding system and a dead end can both look flat.

Compare the production layer: a new coding workflow can produce visible feedback within hours or days, and that relative immediacy makes the next investment easier to justify.

The distribution layer is the exact opposite. You write your first post; maybe three people read it. By the tenth, maybe a dozen. Months have passed, serious time has gone in, and the signal you’re getting is almost identical to the signal you’d get from not doing it at all.

Causality is blurred. Even if things pick up six months later, one piece rarely deserves all the credit. Content quality, accumulated familiarity, search demand, referrals, and luck overlap. That is why the 7/30/90-day record matters: it does not create certainty, but it keeps memory from rewriting the experiment.

The sketch below is a conceptual contrast, not a measured growth law or a promise that an inflection point will arrive:

   Perceived payoff
        ▲
        │                                    ╱  Distribution layer
        │                                  ╱   (steep after the inflection,
        │      Production layer          ╱      nearly flat before it)
        │    ┌──────────────────       ╱
        │   ╱  (earlier feedback,  ╲   ╱
        │  ╱    then diminishing)   ╲ ╱
        │ ╱                        ╳
        │╱_____________________╱    ╲___________
        └────────────────────────────────────────► Time
         ↑                    ↑
     Two weeks         A tempting point to quit
                    (long since invested, signal still ≈ zero)

Some people quit on the flat stretch before a useful archive has time to accumulate. Others quit correctly because the audience, channel, or proposition is wrong. Persistence is not evidence that an inflection point must exist.

I have no way to make this sound nicer. A durable archive asks for repeated work before the return is legible. The answer is neither blind persistence nor weekly panic; it is a fixed review horizon and an explicit condition for changing the channel or stopping.

The discomfort is part of why so few archives survive long enough to become genuinely useful.

If I have to give one piece of operational advice, it’s this: during the ramp-up, evaluate both the artifact and the signal. Did I turn three pitfalls into three retrievable records this month? Did qualified readers arrive, subscribe, activate, or reply? The first protects the asset; the second prevents persistence from becoming avoidance.

Being seen, and being trusted

Writing to this point, I realize the distribution layer needs one more boundary drawn, or it gets pushed too far.

Distribution solves “being seen.” It does not solve “being trusted.”

The two get conflated constantly, but their mechanisms differ. Being seen is an exposure problem — it can be optimized, accelerated, and to some degree purchased. Trust can be influenced, but not purchased on the same terms: it depends on consistency, evidence, and whether claims survive contact with reality.

The gap between reach and influence may widen as the marginal cost of plausible content falls. When polished phrasing becomes easier to produce, “says it well” carries less signal on its own, while “does what they said” carries more.

Distribution is therefore necessary but not sufficient for reputation. It decides how many people hear you speak; reputation decides whether they believe you once they have listened.

Back to the opening line.

“If the product is good enough, people will come” — my view now is that the most harmful thing about this sentence isn’t that it’s wrong. It’s that it disguises an action you must actively take as a process that happens on its own.

It makes you feel like you’re awaiting the market’s verdict, when you’re really avoiding something that makes you uncomfortable. It took me years to see through it. Some of those projects may have failed for product, timing, or retention reasons; what I can say is that I rarely gave discovery a fair test.

Work that never got recorded is much harder for the market — and for my future self — to discover or reuse. That’s the most expensive lesson this layer taught me.

The next essay is the last in this series, on Layer 1 · the reputation layer : once the work is seen, why should anyone believe it, and how can verifiable history and open-source contributions connect the four layers into one system?

The previous essay covered the judgment layer — as execution gets cheaper, more of the cost moves into judgment. If you entered through this piece, the two together make the complete picture.