Small products die of silence, not of bugs

Published August 7, 2026 · 6 min read

Ask an operator what killed their last project and they will usually describe a technical struggle. Look at the project itself and you almost always find something different: a product that worked fine and that nobody ever arrived at. Silence, not failure, is the default ending for small internet businesses — and it is worth understanding why builders keep preparing for the wrong death.

The failure mode nobody logs

Error trackers catch crashes. Uptime monitors catch outages. Nothing in a standard stack catches the thing that actually ends most small products: a week of zero visitors, followed by another, followed by the operator quietly moving on. The product did not break. It was simply never found.

This failure mode is invisible precisely because nothing goes wrong. There is no stack trace to read and no incident to write up, so it never gets studied the way outages do. An operator can run a project into silence and walk away believing the product was not good enough, when the honest diagnosis is that the product was never tested against a single stranger — because no stranger ever arrived to test it.

Once you have watched this happen across a few projects, the pattern becomes hard to unsee. The graveyard of small internet businesses is not full of products that collapsed under load. It is full of products that worked exactly as designed, for an audience of one.

Why builders default to product work

Product work gives feedback in seconds. The code compiles or it does not; the page renders or it does not. Distribution work gives feedback in months, and most of that feedback is ambiguous. Given the choice between a task that rewards you tonight and a task that might reward you next quarter, most people choose tonight — every night.

There is also a comfort asymmetry. Building is private; distribution is public. Shipping a feature risks nothing socially. Publishing an essay, asking for a link, or emailing a stranger risks a tiny rejection every time. So the builder adds one more feature, tells themselves it is what the launch was missing, and stays in the workshop where it is warm.

Neither instinct is irrational. They are just optimizations for the wrong variable. The scarce resource of a small product is not polish — it is attention, and attention never shows up as a task in the issue tracker.

Distribution is a stock, not a spurt

The word launch does a lot of damage here. It suggests distribution is an event: one push, one announcement, one spike. But spikes decay, usually within days, and what remains afterwards is whatever durable channel you built before the spike — often nothing.

Useful distribution behaves like a stock that accumulates: pages that rank for questions people keep asking, an email list that grows a little every week, a name that a niche slowly learns to recognize. Each unit of work adds to the pile, and the pile keeps working while you sleep. A launch, by contrast, is a flow — it stops the moment you stop pushing.

This is why old media properties are quietly valuable out of proportion to their size. A site that has answered a niche's questions for years has an accumulated position that no launch can replicate, because the input was time, and time cannot be compressed with money.

What a channel you own looks like

Not every channel is worth owning, and not every audience is a channel. The test is whether the asset keeps delivering attention without a platform's permission and without continuous spend. In practice, the channels that pass the test for a solo operator look like this:

• A blog on your own domain that answers the questions your buyers actually type, written to be cited by search and answer engines
• An email list, however small, that you can reach on your own schedule with no algorithm in between
• A brand name that a niche recognizes and types directly into the address bar
• An adjacent property you also own that can send genuinely relevant readers — a media site feeding a tool, a tool citing a media site

What is deliberately missing from that list: social accounts on platforms that can change the rules tomorrow, and paid acquisition that stops working the day the budget does. Both can amplify a channel you own. Neither is a substitute for one.

The portfolio angle

Running several small properties makes the product-versus-distribution lesson impossible to avoid, because you get to watch both failure modes side by side. A media property is distribution-first by nature — its product is the audience. A software property is product-first by nature — and it is always the one starving for attention. Owning both types teaches you faster than either would alone.

The portfolio structure also changes the economics of distribution work. A lesson learned promoting one property transfers to the next at no cost, and an audience built by one property can be pointed, honestly and occasionally, at a sibling. A single-product company has to buy every one of those advantages; a portfolio accumulates them.

Sell the problem before you finish the product

The most reliable way to avoid dying of silence is to start the conversation before there is anything to sell. Write about the problem you intend to solve, on a domain you own, while the product is still half-built. If the writing finds no readers, you have learned — cheaply, early — that the product will find no users either. That is the single most valuable piece of feedback a small product can get, and it costs a few essays.

This inverts the usual sequence, and the inversion is the point. Product-first says: build it, then find out if anyone cares. Distribution-first says: find out if anyone cares, then build it. For a funded team, the first sequence is survivable. For a solo operator paying with their own time, it rarely is.

An honest test before you write more code

Before the next feature, answer one question in writing: where do the first hundred visitors come from, specifically? Not a category of channel — a named, concrete path. Which queries, which list, which referring site, which niche community. If the answer is a shrug dressed up as a marketing plan, stop building. The product does not need another feature. It needs a reason anyone will ever see the features it already has.

Silence is not a mysterious fate that befalls unlucky products. It is the predictable result of spending every available hour on the half of the business that gives comfortable feedback. The operators who escape it are not better builders. They are the ones who accepted, earlier than the rest, which half of the work actually decides the ending.

Common questions