After Software: Collaboration, Production, and How Value Gets Shared

For a long time, making serious software almost required a company first: raise money, hire engineers, designers, sales, and marketing. The company owns the code, pays the salaries, takes the risk, and keeps most of the upside. That model worked. It still shapes nearly the entire industry. SaaS is the familiar case. Tools, protocols, libraries, and clients followed the same path.

AI is taking apart one of the basic premises. One person plus AI can already do what used to take a small team. Push one step further, and more and more AI can understand a task, change code, test, research, design, market, even sell. The hard question is no longer how to hire. It is this:

When productive capacity can sit in the hands of countless people and AIs, how should collaboration, ownership, and value be reorganized?

Making software no longer has to mean making an organization first. That is not a claim that companies suddenly fail. Products that need a strong brand, heavy compliance, or continuous operations will often still be best housed in a company. What I care about is a second path that is starting to look possible: can independent people and AIs temporarily organize around one product and finish the work together?

It looks like a productivity story. Keep pushing, and it reaches a deeper layer of the industry.

It starts with I want this to exist

Many software projects do not begin with technology. They begin with a simple sentence: "If someone built this, I would buy it." That person is especially common when a new technology first appears. They see a real problem, and they can see how the new tool might solve it, but they do not have the time, skill, or risk budget to build it themselves. Some will even say, "If you ship it, I will buy the first copy." Or: "I know ten companies that need this. I can introduce you."

They are not investors in the usual sense, and they are not quite salespeople. They first contribute something extremely important: real demand.

Demand is a paid promise, not a casual idea.

As software gets easier to manufacture, that signal may get more precious, not less. AI can generate endless product ideas. It cannot prove they are worth existing. So software production may not always have to start with idea, raise, hire, build, then hunt for customers. It can start another way:

Demand → commitment → collaboration → product → revenue

A project can begin with a pre-sale. That is not an investment. Someone pays $100 for future software and gets the product plus an early price, not shares and not a claim on future profit. The purchase still creates an important signal: this demand is not an offhand opinion. They were willing to pay.

The project can then grow a group of founding customers: people who actually want the thing to exist. Some of them will go further. Someone knows the industry and can help define the need. Someone can test a prototype. Someone knows future customers. Someone can help sell. And some will put their own AI resources into the work so the product appears sooner.

From crowdfunding to crowd building

The internet already proved that people can fund a project together. That is crowdfunding. AI opens another possibility: people can not only fund together, they can produce together. Call it crowd building.

Suppose someone badly wants a product to exist. Today they can pay a bit more up front and wait for a team. Tomorrow they may do something else: send their own AI workers into the project. They may already subscribe to Claude, Codex, or another service. Those resources plug into their own worker pool through a standard interface. They do not have to hand cash to a founder, and they do not have to become an employee. They only choose: "I will put two workers on this project for the next week." The workers then pick up real tasks: fix bugs, write tests, make pages, study competitors, clean docs, finish localization.

What the project receives is not capital. It is productive capacity.

What gets sent is idle capacity plus judgment, not a transfer of cash.

That is a different economic act from investing. Investing says: I think this project has a future, so I give the team money and hope they do the work. Crowd building says: I think this project has a future, so I put my own productive resources into it and help it succeed. One is capital allocation. The other is productive-capacity allocation. Both involve judgment, opportunity cost, and risk. They are not the same behavior.

Why not just give money? If I already pay $200 a month for Claude, handing the $200 to the project looks more flexible. Capacity is a narrower resource than cash. It still holds for two reasons cash cannot replace.

First, subscriptions leave a lot of idle capacity. The fixed cost is already paid. Sending it out has near-zero marginal cost, and the receiving side gets full productive value. That is the economic basis crowd building has over crowdfunding, and cash does not erase it. Second, what goes in is not just compute. A person is still choosing tasks and accepting results. The contribution is a bundle of judgment plus horsepower. Cash strips the judgment out.

The side effect has to be named: when marginal cost is near zero, spam is near zero too. Sybil attacks and grind-for-credit are economically inevitable, not accidents. That returns when we get to contribution.

A few abstractions, so the rest of the piece does not have to keep defining itself:

Workers have to run somewhere. That somewhere is ARC. The worker pool, DARC, and Darc Factory all grow on top of it. A vision essay does not need a runtime tour. The one thing to keep is this: without ARC, capacity stays scattered across subscriptions and laptops. It cannot be scheduled, and it cannot be accepted together.

A worker is not a particular AI

A worker should not be Claude, Codex, or any named model. The technology moves too fast. Today's best model is ordinary infrastructure in a few years. The cleaner move is a standard worker pool above those resources. A person can plug in anything they own and control: Claude, Codex, Gemini, a local model, GPUs, specialized agents, data and APIs, and systems that do not exist yet.

A project should not have to care which company sits behind a worker. It should care what the worker can do, what permission it has, what task it took, what it produced, and whether the result passed.

A construction site does not need to know who made the engine in the excavator. It does need to know whether the machine and the operator are qualified, and whether the work was accepted. Cubic meters of dirt only suffice when the spec is clear. Software contribution is hard precisely because the spec is often not.

So the AI provider supplies horsepower. ARC turns horsepower into workers that can enter a production system.

DARC: letting independent ARCs work together

Gathering scattered workers is only the first step. The hard part is keeping them from colliding, grinding for credit, or producing unverifiable work. A single agent that can work is not the hard problem. The hard problem is: how do hundreds or thousands of workers, owned by different people, finish one product?

That needs more than a traditional agent harness. Without a stronger coordination layer you quickly get duplicate tasks, conflicting edits to the same code, no way to know which result to keep, workers grinding for credit, people creating bugs so they can fix them, a lot of output that looks finished and is not useful, and outside workers holding permissions they should not have.

So there needs to be a production protocol above the harness. Call it the DARC Protocol, Decentralized Autonomous Resource Coordination: a protocol that lets independently controlled ARCs and their resources work together.

An ARC can work. DARC lets many ARCs work together.

Separate ARCs pointed at the same unfinished product.

On DARC you can run a Darc Factory. The name nods at a dark factory: a highly automated line that can keep running with very little hands-on labor. Future software factories may look a bit like that. The point is not "no humans," and it is not to remove people from production. A Darc Factory is not a pile of AIs generating code. It has to run the whole process: what is the goal, how is work split, which worker fits, how much permission it gets, how to run in parallel, how to test, how to review, what gets accepted, what gets sent back, and who actually contributed.

That is a production system, not an agent launcher. Safety, permission, cheating, and quality control are core engineering, not footnotes.

Contribution cannot be measured by how much AI you burned

If crowd building ever produces revenue, the hardest question arrives quickly: who contributed how much?

The simplest answer is effort. It is almost certainly wrong. A worker that burns a million tokens has not created a million tokens of value. Fifty thousand lines of code may be worth less than one correct product sentence.

Resource ≠ contribution

A better path:

Resource → work → accepted output → downstream value → contribution

Two people each spend $200 running AI. The first person's workers complete fifty tasks; thirty are merged and reach production. The second person's workers generate a lot of code that review rejects. They spent the same money. Their contribution is not the same. Whether code stays in the repo for a long time is only one weak signal. A prototype that later gets deleted may have taught the team the right design. A long-lived layer may have survived only because it was written first.

What we need is proof of useful contribution. The question is not how much compute you burned. It is: how much truly useful residue did you leave in the project?

Burned capacity piles up on the left. Only the accepted piece counts.

Every arrow in that chain is hard. The hardest is accepted. Who accepts? If AI reviews AI, the "create a bug, then fix it" cheat has no floor. If people review, review becomes the bottleneck. Once production is cheap, the scarce thing is often no longer production. It is judgment, taste, and architectural coherence. Maintainers and architects are not honorary titles. Their judgment is high-value labor and also has to be attributed. Without that role, hundreds of independent workers produce a pile of locally optimal, mutually incompatible pieces.

Acceptance itself needs governance: who reviews, by what standard, how grinding is stopped. That is not a detail you can wave past. It is the premise of the whole model.

Contribution is not only code

The industry has a long bias: only writing code counts as building the product. Reality is not like that. A software product succeeds only if supply and demand both hold. An excellent product that nobody knows about can still fail. Someone who never writes a line can still bring the first customers.

Crowd building therefore has at least a few kinds of contribution.

Supply contribution makes the product manufacturable: code, components, design, testing, compute, research, infrastructure.

Demand contribution helps the project know what is worth doing: a real user stating a need, a domain expert defining a workflow, early customers testing price, users trying a prototype and naming the real problem.

Distribution contribution helps the product reach a market: introductions, sales, marketing, content, community, localization, onboarding, retention.

A good salesperson used to tell a founder, "If you build this, I can sell twenty copies, and I want a cut of the customers I bring." If those twenty copies sell, why should that revenue not be attributed to them? They wrote no code and created income. A future system should be able to see that value, instead of treating it as a sales cost after development is "done."

A requirements change that redirects the product, a patch that lands in production, a sale that can be attributed, should all be catchable in the system. The hard part is not listing the categories. It is turning "was adopted" and "had downstream value" into verifiable records, not later recollection.

A pre-sale does not buy contribution

One boundary matters. Buying the product and contributing to the project are different acts.

A pre-sale buys future software and a discount. Contribution creates real value and earns contribution credit. So:

Purchase gives access. Contribution must be earned.

A pre-sale can create no credit at all. It can still be a qualification. Someone who already paid to wait for the product, and someone who walks by and says "you should do X," do not carry the same information. A project can require founding customers for certain definition, prototype, or customer-specific tasks.

That is not "money buys contribution." It is the opposite. Money only proves you are actually a stakeholder in the problem. Real contribution still comes from what happens after. That is how you avoid a problem AI makes inevitable: ideas become extremely cheap, and noise becomes extremely expensive.

From miners to AI miners

The shape has an accidental resemblance to early blockchain miners. A miner bought machines, paid for electricity, joined a network, did work the network needed, and was rewarded. A future AI worker buys AI or compute, joins a worker pool, chooses a project, completes work the project needs, earns contribution credit, and shares in later revenue.

That lets us reread a few kinds of miner.

Resource miner. The old version supplied generic cloud compute. That never needed a decentralized network to recreate AWS. The better definition now is: supply AI productive capacity you control. Not selling servers. Plugging Claude, Codex, GPUs, or agents you already have into a worker pool so they can finish real tasks.

Component miner. The old hope was that independent developers would keep shipping high-quality reusable components. That turned out to be very hard. A good component has to be written, then maintained, tested, kept compatible, documented, and actually usable. Ordinary developers could rarely sustain that. AI may lower the threshold for the first time. A component miner is no longer only a developer. It can be a production unit of human judgment plus AI workers.

Operation miner. The old hope was that someone would do market, sales, and operations. If a component economy never really formed, there were not enough products worth selling. Once the cost of supply falls sharply, the bottleneck may flip: who can actually create demand and distribution? Operation miners may become some of the most important contributors.

Blocklets: technical composition is not enough

Contribution records answer who should receive how much. Software itself still needs economic composition. Today's software is already highly composable. A product may use an open-source library, a cloud API, a database, a payments provider, an AI model, a frontend framework, an authentication service. Technically these combine well. Economically they almost completely break. An npm library can sit under a SaaS with billions in revenue, and the author receives no contractual share. In other words:

Modern software is technically composable and still not economically composable.

There is a hard objection that has to be faced. If AI makes writing code nearly free, any priced component can be cloned into a free one immediately. The reason npm authors do not get paid is not only a missing protocol. Frictionless free copying is itself part of the ecosystem's value.

So economic composability only holds for what is not easily cloned: running state, data, network effects, DID identity, and an accountable maintenance promise or SLA. It does not hold for a stateless, identity-less, ownerless pile of source. Blocklet was meant to stand on that side from the beginning.

A Blocklet is not only a code package. It can have its own DID, owner, state, dependencies, revenue policy, contributors, and economic relationships. If product A uses component B, and B uses C, value can flow down the composition graph after A is paid. A customer pays 100 ABT. A keeps some. B receives some. B splits further to B1 and B2. A sales contributor receives some. A maintenance contributor receives some. That is recursive settlement.

Revenue follows the composition graph, not just a code import.

The principle is simple:

If software can compose, ownership and value must compose too.

Ownership should not be a user id

Traditional software often has one field: owner_user_id = 123. Future ownership is likely more complicated. A Blocklet's owner can be a DID. That DID may not be a person. It may stand for an organization, a project, a multisig, a community, an agent, another Blocklet, or a realm controlled by several DIDs. Ownership itself can be a recursive graph.

More important, "ownership" need not be one indivisible right. A project can have control, revenue, governance, upgrade, usage, and transfer rights, and they need not belong to the same subject. The cleaner direction is programmable ownership: not a single owner column, but a set of machine-readable rights.

Contribution rights and settlement should stay apart

If a project needs to record long-term economic shares, it can use its own contribution token or rights mechanism. Call it a kind of VC token if you want. Here VC is not a payment currency. It says what contribution, revenue, or governance rights a DID has in this project.

Projects can have different rules. Some rights cannot be transferred. Some can, after conditions. Some are only a revenue entitlement. Some include governance. Those rules belong to the project, not to one protocol-wide asset.

At the same time, the wider economy can settle in one asset, for example ABT. Project rights decide who should receive how much. ABT moves the value. Customers can even pay in dollars. The books can stay in dollars. At payout, the then-current ABT price decides how much ABT to send. So:

Fiat defines price.
Project rights determine entitlement.
ABT settles value.

That avoids a common failure of token systems: one token trying to be ownership, governance, payment, incentive, and speculation at once. Those jobs do not have to share one asset.

A real constraint still has to be named. A right to future shared income earned through labor will, in many jurisdictions, run into regulatory and employment questions. Companies, contracts, and liable parties do not vanish because a protocol is elegant. A legal wrapper still has to say who signs, who is liable, and which subject the rights sit on. Avoid that, and the whole essay gets filed under "another token story." That is exactly what I want to avoid.

What a project marketplace would look like

Put the pieces together and a marketplace appears. It is not an AI-agent marketplace, and it is not a freelancer marketplace. The object is the project.

A project page might show 148 committed customers, 36 pre-sales, a prototype 42 percent complete, 23 active workers, a current need for testing and distribution, and $3,800 of first revenue. A participant can pre-order, contribute, deploy workers, or help sell.

Someone who owns twenty AI workers then watches projects the way an investor watches a portfolio. They are not allocating money. They are allocating productive capacity. They may decide project A has strong demand and send eight workers; project B looks promising but sits outside their domain, so they send two; project C is something they themselves need, and they know customers, so they join demand, build, and distribution at once.

That is a different market behavior. Ordinary speculation finds something that might succeed, buys it, and waits. This is: find something that might succeed, join production, and help it succeed. Call it productive speculation. Not because speculation deserves praise, but because human judgment about opportunity is already a powerful allocator. If that judgment can move from buying an asset to putting in capacity, it may produce something more constructive than purely financial bets.

A more concrete picture: someone has complained for a long time that a real workflow has no decent tool. Twelve people pre-order and become the first founding customers. Three people send workers: one on the core path, one on tests and docs, one on sales material. The requirements come from a practitioner among the buyers. The first $3,800 arrives and flows back along accepted output and attributed sales. The numbers can change. The structure does not: demand is proved by payment, production is proved by acceptance, and revenue is the final check.

Software may become its own economic organization

Push far enough, and a Blocklet or a project looks less like "software a company owns." It may itself hold a DID, code, state, customers, workers, a contribution graph, revenue, ownership rights, settlement rules, and dependent components. It can own other Blocklets. Other DIDs can own different rights in it.

Then a question appears on its own: where is the boundary between software and company?

The old answer: the company owns the software. Another structure becomes possible: software itself becomes an economic organization.

That does not mean legal companies disappear. For tax, contracts, liability, and intellectual property, companies remain extremely important. They may no longer be the only container in which digital collaboration can exist. The internet let information move across institutions. AI and blockchain may let productive capacity and economic relations cross organizational borders more easily.

This is not a new token economy

The easiest misreading is to hear all of this as "issue a token and let people trade it." That is not the question I want. The whole model can run with no publicly tradable token.

A pre-sale buys a product. A worker is a productive resource. Contribution credit is a record. Project rights can be non-transferable. ABT is only settlement.

If a mature project later produces stable cash flow, some of its ownership rights may be priced by a market, even financialized. That is almost unavoidable. Any right that keeps producing cash eventually has a price. That should be something that may happen after value is created, not the reason the project exists.

A lot of crypto projects ran: token, speculation, funding, hope the product appears. I am more interested in the reverse:

Demand → contribution → product → revenue → rights → perhaps, eventually, a market.

Production first. Customers first. Revenue first. If a market appears later, let it appear.

Why this might be different from ten years ago

A lot of this sounded like idealism ten years ago. Not because blockchain could not do the accounting. The missing layer was production. Getting hundreds of strangers to write high-quality software together was too expensive to coordinate. The efficient answer stayed: form a company, hire people, appoint managers.

Similar experiments also failed in concrete ways. Gitcoin hit sybil problems. SourceCred and Coordinape often decayed into popularity contests. DAOs kept meeting governance capture. Kickstarter proved pre-orders can exist, and also proved delivery is another matter. Open source is more interesting: Linux produced extremely high-quality software with fairly loose coordination and no contribution token. Why? Because many contributors were paid by companies, and value was captured elsewhere. That supports the earlier claim instead of weakening it. The leftover problem is exactly this: value capture and contribution happen in different places.

AI is lowering coordination cost. One person can already hold something like a small team's productive capacity. If that capacity can plug into a worker pool on ARC, and if a Darc Factory can reliably split, coordinate, and verify work, loosely coordinated production may stop being only a theory.

Blockchain also no longer has to answer "why must software live on a chain." It has a more specific job: when producers are independent and do not share a company, how do they share a credible layer for identity, provenance, ownership, payment, and settlement?

AI makes loose production possible. Blockchain can make loose economic coordination more trustworthy.

What may appear is a new way to make software

The production path we know is founder, company, funding, employees, software, users. Another path may appear:

Someone actually needs a thing. A group proves the need with purchase commitments. People who understand the problem help define it. Independent AI workers join production. Components are composed. More users test and sell. The product starts to earn real revenue. Value flows back along the contribution and composition graphs to the people who made it.

There will still be failures. Most ideas will still not be worth doing. A great deal of AI work will still be worthless. Fair attribution will be very hard. Safety, permission, cheating, and quality control for outside workers will be large challenges. Those problems do not vanish because AI, DIDs, or blockchain are in the stack. They are the real problems to solve.

If they can be solved, the industry may get a new organizational form for the first time: not everyone joining one company before they can create a product, but a product worth existing attracting people, AIs, components, resources, and market capacity to gather for a while.

The product becomes the center of collaboration. Contribution becomes an economic relation. Revenue becomes the final verification. And the organization can grow with the product, instead of having to exist first.

That may be one of the software futures most worth exploring in the AI era.

Find something you want to exist.
Help make it real.
Share in the value you create.