Uberization of Software Development

What four hundred years of getting a ride can teach us about buying engineering.

In 1937, a young economist named Ronald Coase asked a trivial question that turned out to be foundational: if markets are so efficient, why do firms exist at all? Why employ anyone when you could buy every hour of work on the open market? His answer was that using the market is not free. You have to find the right person, agree on what "done" means, vet their work, and argue when things go wrong. Those are transaction costs, and a firm keeps growing until the cost of organizing one more transaction inside it equals the cost of buying that transaction outside.

Put plainly, you outsource when

$$\begin{array}{r} \textsf{market price} \\ \textsf{+ transaction costs} \\ \hline \textsf{\textbf{cost to outsource}} \end{array} \quad \textsf{<} \quad \begin{array}{r} \textsf{employee cost} \\ \textsf{+ coordination costs} \\ \hline \textsf{\textbf{cost to hire}} \end{array}$$

and you hire when the inequality flips.

Every debate about freelancers versus full-time, offshore versus in-house, build versus buy, is this inequality in disguise. What makes the equation interesting is that its terms are not fixed. Technology moves them. And every so often a technology moves the transaction-cost term so far that an entire category of work jumps across the firm boundary.

We have watched this happen before, in slow motion, in how we get from one place to another in a city.

The hackney coach: paying by argument

In 1634, a retired sea captain named John Bailey parked four coaches beside the Maypole in the Strand in London and kept a fixed table of fares for a list of destinations. Driver and passenger agreed on a destination and a price up front, shook hands, and set off. Much like hiring a freelancer today.

The trouble began the moment reality diverged from the agreement. A street closed, a detour taken, a journey that felt longer than it should have. Ending the trip with both parties upset. Driver thinks the trip was unprofitable, the passenger felt extorted, and one too many of those disagreements ended before a magistrate. The handshake never worked. Within twenty years, Parliament was regulating hackney fares, and it kept amending those rules for two centuries.

This would feel familiar if you've bought software from an outside party. A fixed-scope, fixed-price engagement is a hackney coach. Reality diverges from the scope on the first day, a dependency turns out to be undocumented, a "small" integration doubles the timeline, and the engagement ends in scope change requests and withheld invoices.

The root problem was never dishonesty. It was that nobody could measure the output.

The taximeter: paying by measurement

In 1891, a German inventor named Wilhelm Bruhn built a device that mechanically counted the distance a cab had travelled and converted it into a fare. The taximeter made the output legible to both sides - but fell short on solving variables.

IT consulting, staff augmentation, outsourcing contracts, rate cards, story points, and billable hours: all of these are meters. They replace an argument about scope with a measurement of effort. Like the taximeter, they come with elaborate frameworks for how the price changes when circumstances change, which is why every large outsourcing deal has a change-control annex thicker than the statement of work.

The meter was a real advance. It solved effort (distance/hours), but not outcomes (arrival/closed-tickets). A metered cab still can't won't tell you how much the trip will cost or when you will arrive, and a contract still can't tell you what the feature will cost or when it'll ship. The meter made the dispute smaller, but did not make it go away. This is because the dispute was never really about the number on the meter.

Uber: paying for the outcome

What a passenger actually wants is two numbers before the journey begins: what will this cost, and when will I arrive. Everything else is implementation detail.

That is what Uber sold. Not cars, not drivers, not even convenience, but certainty. The price is quoted up front and expectations are managed through the ETA is drawn on a map. A whole machine of mechanics exists behind the screen to make those two promises keepable: a two-sided market that balances supply and demand in real time, surge pricing that pulls drivers toward unmet demand instead of leaving the passenger stranded, payment held by the platform so neither side has to trust the other, ratings that replace the magistrate, and a dispatch algorithm that absorbs the detour, traffic conditions, weather conditions so the driver is protected, and the customer never sees it. Uber turned the trip into a true output-based transaction, and in doing so it moved the Coase inequality. For a great deal of urban mobility the market became cheaper than the firm, and the firm, meaning the taxi company with its salaried fleet, shrank.

Software never got its Uber moment. We got stuck at the meter, and Coase tells us exactly why: for most engineering work the cost to outsource stayed higher than the cost to hire. Three transaction costs in particular refused to come down.

The three walls

1. Context. A driver can pick up any passenger in any city after a few minutes with a map. An engineer cannot pick up any ticket in any codebase. Every system carries years of accumulated decisions, conventions, and unwritten reasons why the obvious approach was tried and abandoned, and a new contributor has to load that context before producing a single useful line. In most organizations that takes weeks, which is precisely why the firm keeps engineers on payroll: the context investment only pays off if the person stays.
2. Verification. Distance is an output and the meter settles it. There is still no shared, cheap way to agree whether a change is truly satisfactory. Specifications are a continuous discovery process in most teams, tests are often incomplete, and "it works" means different things to the person who wrote the ticket and the person who closed it. Without an agreed definition of done, output-based pricing collapses back into arguments and overages.
3. Access. To do real work on a codebase you have to see it, and most companies will not open their repositories to a stranger on a marketplace. Intellectual property, security, compliance, and the simple fact that a repository is a map of every mistake a company has ever made all push in the same direction. So fractional contribution stayed confined to the edges: bug bounties, open source, the occasional contract that arrived with a thick NDA.

Those three walls are why, decades into the internet era, we're still buying engineering the way Londoners bought coach rides in the 1630s: by the handshake, by the meter, and mostly by hiring. Not because nobody tried to build the marketplace, but because the economics did not allow it. Until the walls move, no amount of product cleverness changes the inequality.

The walls are moving

I've been running independent research and talking to teams across the spectrum: solo founders, SMBs, late-stage startups, big tech, enterprises, and the way software ship has dramatically changed. Product managers draft specifications with AI. QA teams are using AI to expand the scenario coverages. Coding agents produce the implementation, and pull requests are reviewed by agents before a human ever opens them. This no longer sits as an experiment and is the Tuesday-afternoon workflow of an ordinary team shipping to production.

What matters for the economics is not the productivity gain. It is that each of these changes happens to knock down one of the walls.

Context loading is becoming a retrieval problem rather than a tenure problem. Companies that run agents are forced to write their context down, because an agent cannot absorb tribal knowledge over lunch, and once it is written down an agent can fetch exactly the slice relevant to a task through protocols like MCP. Weeks of onboarding compress into seconds of retrieval. An engineer, or an engineer's agent, can arrive, perform from day one, and leave, and the firm loses nothing when they go because the context never lived in their head.

The spec-verify gap is closing from both ends as well. The gap between the coding agent output and specification are tightening, and the question if an output is delivered according to spec are getting more and more definitive. This is the taximeter for outcomes that would change how we look at the value of engineering hours.

Lastly, access to a private repository. I envision that a zero-trust environment is theoretically possible where companies could prepare a public repository with minimal code exposure just enough for what the task requires: the declarations with their bodies stripped out, the transitive closure of types the change touches, the inward-facing interfaces the new code must call, a diagram of the components involved. This is how coding agents today operates anyway, though grepping, ast, queryable knowledge graph that is essentially a slice of your repository. By building this as a public repository, alongside with applying obfuscation techniques, a contributor can build a feature against that slice without ever holding the whole map. The company could exposes a keyhole, and not the house.

Each wall is still partly standing. But the Coase inequality does not need them to fall completely. It only needs the cost to outsource to drop below the cost to hire, and for a growing class of well-specified, well-bounded engineering work, that crossover is now in sight.

The economics on the other side

Picture the transaction once the walls are low. A company posts a task with a scoped context slice, a specification, and an executable verifier. The task carries a price and a deadline, both fixed. The market clears it the way a ride-hailing market clears a trip: supply and demand set the going rate for that kind of work, surge pricing pulls capacity toward tasks nobody is picking up, escrow holds the funds until the verifier passes, and reputation replaces the magistrate.

For the buyer, this is the Uber promise applied to engineering: certainty of cost and certainty of delivery, quoted up front, for work that today requires either a hire or a hackney-coach contract. For a product manager it means a roadmap item can be priced like a line item. For an engineering manager it means capacity that expands elastically without the fixed cost of headcount, or the memory you lose when people leave. For a founder it means the company can stay small far longer, because Coase's boundary has shifted outward.

For the person on the supply side, the job changes shape entirely, and this is the part most forecasts miss. The freelancer of this world is not a contractor who types code faster. Their craft is the harness: the carefully assembled environment of models, tools, context, prompts, and verification loops that makes an agent reliable in one specific, narrow domain. One specialist might run the best harness in the world for high-concurrency C# services that interface with a stock exchange; another for data migrations in legacy ERP systems; another for accessibility fixes in React front ends. They pre-fund their agents with tokens or subscriptions, point them at the market, and let them pick up matching tasks in the background while the human sleeps, trains, or builds the next harness.

Look at the incentives this creates. Revenue is earned per verified task and cost is paid per token, so the specialist earns the most by solving tasks correctly, quickly, and cheaply. Every improvement to the harness drops straight to their margin. The market becomes a competition in engineering judgment about how to make machines reliable, rather than in hourly throughput. That is a better game than the one time-and-materials rewards, where the incentive runs quietly in the opposite direction.

What this asks of us now

Taxis did not become Uber because someone invented an app. They became Uber because the meter had already made output legible, GPS had already made position legible, smartphones had already put a dispatch terminal in every pocket, and then someone noticed that the transaction costs had collapsed and built a market on top. The infrastructure preceded the business model by years.

Software is at that moment. The models exist. The protocols for context exist. The verification loops are being built in each organisation, often by accident, by teams that just wanted their agents to stop breaking the build. The question for anyone who leads a product, a team, or a company is not whether this market arrives but which side of the inequality you want to be standing on when it does.

If you run a company: write your context down, and treat the ability to slice a task cleanly out of your system as a capability worth investing in rather than an inconvenience. If you lead engineering: start pricing work in verifiable outcomes, even internally, because the teams that can specify and verify will be the first able to buy capacity from the market. If you are an engineer: the harness is the new craft. The scarce skill is no longer writing code; it is knowing a domain well enough to make a machine trustworthy inside it.

Coase would recognize all of this immediately. The firm exists because the market is expensive to use. We are about to make it very, very cheap.

This is what we are building at Lunox: we connect teams to contributors who ship coding tasks at a fixed cost and timeline, with payment only when tested code gets merged.