After the Software Is Built, There Is Still Distribution

Build a piece of software, make an app, sell it to other people — for a long time this was the standard picture of the software business. That picture needs to be re-examined today: with the barrier to creation so low, “making something” is increasingly hard to count as value in itself, and how the work enters users’ lives — distribution — has become the real bottleneck.

This is not a mindset problem; it is a structural one. The friction of creating has all but vanished — writing a tool, cutting a video, generating a short drama now cost nothing but time and a small fee. But not a single bit of the friction in distribution has gone away: finding people willing to look, choosing the right venue, timing it well, building trust — every one of these still needs a human to do it.

Supply is growing; attention is not

The change is most visible on the content side. New AI-made short dramas break out almost every week, top titles rack up view counts in the tens of millions, and the quality has risen to the point where they can no longer be dismissed as “low-capacity filler.” On the other side, the observation is: among these AI dramas, the ones with the healthiest numbers are not the batch that went viral overnight, but the ones whose viewership has stayed steady over the long run with people always watching — only stability makes monetization possible, provided it really is stable.

A clear asymmetry has opened up between supply and demand: the volume of creation is multiplying, while attention, spending power, and the number of consumers have not expanded in step. The same holds in business at large — capital is concentrated in a handful of validated tracks, leaving little room for “build it first and figure it out later.”

This asymmetry decides one thing: finishing the work is only half the job. The other half — getting it seen — will not happen automatically just because the work is good.

Distribution is becoming a process you can break down

Does distribution have to rest on talent and luck alone? One secondhand case offers a different picture.

As retold, an independent developer set up a resident agent on a separate computer to visit niche forums in Europe and America on a schedule. The model first sizes up each forum’s temperament — some forums like indie developers telling their story, others prefer substantive, knowledge-driven posts — and then times its posts around when people actually browse. The developer only supplies the content itself; what is being promoted is his own software, Mole, and the vehicle doing the executing is a resident agent such as Grok Bot.

Before anything else, the nature of this case must be stated: its presentation on this show is itself a retelling, relayed after an in-person meeting. The original promotional results, whether the forums’ rules even permit this, and how those communities feel about machine participation in their content — none of it can be verified. So you cannot infer from it that “automated posting drives growth” — there is no evidence supporting that, and platform rules and community norms could impose hard constraints at any time.

What makes it worth noting lies elsewhere: distribution was broken down into executable steps. Read the context, choose the timing, place the content, wait for feedback — every step has a clear input and output. This kind of work used to depend on a marketing firm’s experience and headcount; now at least some of the steps can be handed to a program that follows a process. Being process-driven is not the same as being effective, but only once something is process-driven can its effects be measured and improved.

Users buy outcomes, not software

Back to the opening judgment: build an app and sell it — that arbitrage no longer holds up well today. One reason is that tool-shaped needs are being solved by users themselves with models: if they can put it together on their own, why would they buy your software?

From there comes a distinction: a tool, a service, and an actual outcome are three different things. A tool is software the user has to operate. A service is a process done on the user’s behalf. The actual outcome is what the user ultimately cares about — the problem solved, the content seen, the thing done. Distribution is precisely part of the service and the outcome, not an afterthought tacked on once the software is delivered. The AI-drama example makes the same point: what actually accumulates value is not any single viral episode but the continuous supply and the stable viewing relationship.

Distribution therefore deserves to be designed as part of the product, not treated as a one-time action on launch day. It comes with its own constraints: platform rules, community culture, and the scarcity of attention will not loosen automatically just because technology advances.

Distribution will not disappear; it will only change form. The genuinely open question is: in an environment of supply overload, what kind of distribution can be process-driven without exhausting the audience’s trust? No one has that answer yet, and it is worth anyone who has just finished a work thinking about it further.