The Distribution Problem: Why Shipping Was Never the Hard Part

Here is the uncomfortable thing nobody warns you about when you go independent: building is now the easy part. Applied AI collapsed the cost of getting from idea to working software — I can stand up retrieval, evals and a real product in the time it used to take to write a design doc. But the same forces that made me faster made everyone else faster too. The result is that the bottleneck moved. It used to be "can you build it?" Now it's "will anyone ever find it?" That is the distribution problem, and it's the one I underestimated most.

For thirteen years my job was to make things work. Distribution was someone else's column on the org chart. When you're a one-person company, there is no such column. You are the engineer and the only person responsible for the fact that a perfect product with no audience is indistinguishable from a product that doesn't exist.

The 20% that ships, the 80% that's seen

I now assume shipping is the first 20% of the work, not the last. The remaining 80% is the slow, unglamorous business of being found by the specific people whose workflow your product actually fixes. That reframe changes what I build. A feature isn't done when it works; it's done when someone who needed it could plausibly stumble into it. If I can't answer "how would the right person hear about this?" the build isn't finished — it's just compiled.

This is humbling for an engineer, because code rewards effort fairly predictably and distribution doesn't. You can write the cleanest module of your life and ship it into total silence. The market is not grading your craft; it's grading whether you showed up where its attention already was.

Distribution is a feature, not a phase

The mistake I made early was treating distribution as a phase that starts after launch — build the thing, then go tell people. It doesn't work, because the product and the way people discover it are the same object. On VoltExam, the verticals that grow are the ones where the product itself does the talking: a learner who passes tells the next learner, because the result is legible and worth repeating. On CapitalGains, the calculator that's correct to the dollar is its own marketing — people share a tool that just answered their question better than an afternoon of searching did.

So I've started designing for distribution the same way I design for reliability: as a property baked into the thing, not a campaign bolted on afterward. What makes this shareable? What makes a satisfied user mention it without being asked? Those aren't growth-hacking questions. They're product questions, and they belong in the spec.

A product with no distribution isn't a quiet success. It's a private hobby that happens to compile.

The honest version of marketing

I don't have a megaphone, a budget, or any appetite for pretending to be louder than I am. What I have is the same thing I bring to code: I'd rather be true than impressive. The honest version of marketing, for me, is just doing the work in public and explaining it plainly — these essays are part of that. Not because writing is a clever funnel, but because the people I want to reach are the kind who trust a real explanation over a polished claim. Distribution earned that way is slow, but it's also the only kind that compounds instead of evaporating the moment you stop paying for it.

There's a version of this that's pure cynicism — optimize the headline, chase the algorithm, manufacture urgency. I've watched it work and I've watched it rot the thing it was selling. The trouble with borrowed attention is that it leaves the way it came. So I'd rather build an audience the way I build a product: narrower than I'd like, but real, and durable enough that I'm not starting from zero every Monday.

Why this is the right problem to have

It would be easy to read all this as a complaint. It isn't. The distribution problem is a luxury problem — it only exists because building stopped being the wall. A solo founder in 2026 gets to spend their scarce attention on whether the thing deserves to be found, instead of on whether it can be made at all. That's an extraordinary place to be standing. The work now is to be as disciplined about earning attention as I am about earning trust in the code: slowly, honestly, and in public — and to remember that a thing worth building is only finished when it's also a thing the right person can find.

Arun Jalota is a Technical Director in Toronto leading a 12-engineer mobile team and driving AI tooling adoption. Reach him at arun@arunjalota.com · LinkedIn · GitHub.