Selling digital products: what actually has to be true

The technical side of selling something digital is genuinely easy now. A payment processor, a file, an automated delivery email — an afternoon’s work, and the platform takes a small cut and handles the tax.

That isn’t the hard part, and the fact that it’s easy is why so much of the advice about it is worthless. Anybody can describe how to set up a checkout page. Almost nobody wants to talk about the four things that determine whether anyone buys.

The product has to be downstream of something you already do

The failure pattern is picking a product because a market looks profitable and then trying to become qualified to make it.

What works is inverting that — noticing what you’ve already built or learned for your own reasons, then asking whether the artefact of that work is worth something to somebody else. The difference isn’t motivational. It’s that the second route means the expensive part is already paid for, because you’re packaging work you did anyway.

It also solves the credibility problem, which is otherwise unsolvable. “I made this because I needed it and here is what it does” is a position. “I researched this niche” isn’t.

The test I’d apply is whether, if the product disappeared tomorrow and nobody had bought it, you’d still have wanted the thing it was made from. If yes, the downside is capped at your time and you’ve got something to show regardless.

Specific beats good

A comprehensive product for a broad audience competes with everything. A narrow product for a specific person competes with nothing, because nobody else has bothered.

“A guide to networking” is unsellable. “A change-control template pack for network teams running Cisco estates” is a thing a particular person recognises themselves in, and recognition is what makes somebody read past the first line.

Narrowing feels like shrinking the market, and in fairness it does shrink the addressable one — but it raises the conversion rate by more, because you’ve stopped competing on volume and started competing on fit. It also makes every downstream decision easier: what to write, where to post it, what to leave out.

Distribution is the other half, and it takes longer to build

This is the one that gets skipped, and it’s the one that decides the outcome.

Something with no audience sells approximately nothing no matter how good it is, because nobody encounters it. And an audience isn’t a thing you acquire in the week before launch — it’s accumulated slowly by being useful in public for long enough that people recognise your name.

Which means the order is backwards from how it feels. You build the audience first by publishing things that are useful and free, and the product comes out of and to that audience, rather than the reverse.

The uncomfortable implication is that the timeline is months to years rather than weeks, and anybody promising otherwise is either selling you the promise or got lucky and generalised from a sample of one. The mildly cheering implication is that the free work isn’t a cost, because writing publicly is how you find out what people actually ask, which is how you find out what to build. The audience and the specification arrive together.

Support is the real cost

The seductive thing about a digital product is the marginal cost of a copy, which is zero. Sell one, sell a thousand, the file is the same file.

The marginal cost of a customer isn’t zero. Every buyer can email you. Some will want a refund, some will have a question the documentation answers, some will want a feature, and a few will want a conversation you didn’t sign up for.

That’s fine and manageable, but it wants to be a decision rather than a surprise. What I’d suggest is writing the documentation as though support doesn’t exist, because every question you pre-empt is one you don’t answer a hundred times. Decide the refund policy before the first sale, publish it, and then be generous within it — arguing over small sums costs more than the sum. And be explicit about what isn’t included, because “this does not include customisation” prevents a whole category of disappointment.

A product that generates constant support isn’t passive income. It’s a job with an unusual billing model.

What I’d actually do first

I’d publish consistently for six months on one specific thing, with no product at all, because the goal at that stage is finding out what people ask you about. Then I’d make the smallest possible version of the answer to whatever came up most and give it away, and watch whether anybody used it. Only then would I charge for something, and ideally for the fuller version of the thing that had already proved people wanted it.

The other one would be to use a platform that handles tax. Digital goods VAT and sales-tax rules across jurisdictions are genuinely unpleasant, and the platforms that act as merchant of record are worth their cut on that basis alone.

The honest summary

Selling digital products isn’t passive, it isn’t fast, and the technical part is the easy part. It’s a distribution problem wearing a product costume.

The economics once distribution exists are genuinely unusual, though — the thing you made once keeps being worth something, and that’s rare enough to be worth the slow start.

I’ll link anything I actually build here as and when it exists. Nothing yet: this is the reasoning, not the receipt.