How to Reverse Enshittification

The Ratchet

You have probably heard the word. Cory Doctorow popularised enshittification for what happens to consumer apps: an app arrives and is genuinely good, then the experience turns against the people using it, and by the end it is a machine for extracting money from people who have nowhere else to go. Facebook when it was just your friends, Twitter when it was just a timeline, Google when it was just the fastest way to a page — each one was on your side while it needed you. Doctorow's fuller account has three stages; the part that matters here is the direction. Every move is away from the user and toward whoever owns the app.

The word is funny. The pattern is not — and it is not confined to one company. It is the whole recent history of consumer software. The lesson is not that some particular firm went bad. The lesson is that the slide happens again and again, in every category, under every management team, decade after decade.

So the moral explanation — greed, bad leadership, short-term thinking — is not a useful one. It describes the people and misses the machine. If enshittification were a matter of character, better people would fix it. It would not keep happening.

Southwest Airlines is the proof that this is not a story about software, or about character. For fifty years it was the counter-example — employees first, customers second; two bags flying free; open seating since 1971; never a mass layoff. Then, in June 2024, the activist fund Elliott Management bought a $1.9 billion stake and argued publicly that Southwest had “failed to evolve.” Within a year, free checked bags and open seating were gone, and 1,750 people had lost their jobs — the first mass layoffs in the airline's 53-year history.

The people did not get worse. The incentives were always there, waiting. The passengers did not own or control Southwest, so when profits could grow by making the product worse, enshittification won.

Enshittification is not a moral failure. It is the behaviour of a system under a constraint.

The real explanation is mechanical, not moral. Owners are not villains; they are trying to give their investors the best returns possible. It's hard to argue that people who are trying to be good at their jobs have bad character. What allows enshittification is the cost of leaving — call it the exit cost. When leaving is expensive — because you cannot get that functionality anywhere else — the owners can make the app worse and capture more of the surplus it produces, and never be punished for it. The owner's aim is to maximise the surplus they keep for their investors: degrade the product just enough that the extra extraction is worth more than the users it loses, and never enough to make the exit worth taking. When leaving is cheap, that line is near, and the app has to keep earning you. A company that cannot lose you does not have to earn you.

What is actually at stake is the surplus: the value the users create, and who gets to keep it. Enshittification is what happens when the owners can keep taking it without the users leaving. Lower the cost of leaving and the taking gets harder — but it does not change who the surplus belongs to. And here is the catch that shapes everything that follows: making software cheap to build does not, on its own, move the surplus either. A cheap competitor owned by someone else will extract in exactly the same way. Cheap building is the opening, not the victory.

Which changes the question. The useful question is not why do companies do this? Companies do what their incentives reward. The useful question is why do users tolerate it? And the answer is not better people. To understand a system like this — to see why it behaves the way it does — you have to understand the constraints it operates under. That is what the next section is about.

The Binding Constraint

Every system — a lake, a reaction, a factory, a market — is governed by its scarcest input.

In ecology this is Liebig's law of the minimum (Justus von Liebig, 1840). Plant growth is not limited by total nutrients. It is limited by the nutrient in shortest supply. Add water and light and nitrogen to a field that is short on phosphorus, and nothing happens. Add phosphorus, and the whole system reorganises around a new bottleneck. The minimum factor sets the pace of everything else.

Two words carry the rest of this argument:

Multiple fields have identified the same law and given it different names. Two of them gave the idea its vocabulary.

Chemistry: the rate-determining step. Billions of people depend on industrial fertiliser to grow their food, and ammonia is its most common form. Most of the world's ammonia is made the same way — nitrogen and hydrogen over an iron catalyst. The reaction is slow in exactly one place: splitting the nitrogen molecule. Speed up anything else and the plant makes no more ammonia. Chemistry calls the slow place the rate-determining step, and the whole reaction runs at its pace. The idea is as old as the study of reaction rates itself.

Management: the theory of constraints. Eliyahu Goldratt put the same law at the centre of his 1984 book The Goal, and management gave it a name: the theory of constraints. Throughput is set by the bottleneck. Effort spent anywhere else is wasted.

The same law, worked three ways:

Further reading. The same constraint logic has been applied well beyond any one field. Ron Davison's The Fourth Economy: Inventing Western Civilization (2011) turns it on history itself. Worth it if the law here interests you more than the software does.

Next: how Big Tech won — the same law applied twice, and the lock-in that followed.

How Big Tech Won

The market is the fourth field, and it is the one this argument turns on. The winners of the last tech generation took both sides of it — the customers and the code — and then made the exit expensive. This is how they did it.

The capture

For most of the twentieth century, the scarce input in media and retail was distribution — printing presses, shelves, trucks, cable. It was capital-intensive, owned by few, and nothing reached a customer except through it. The internet drove its cost to roughly zero.

That should have been good news for the suppliers. It was not, because the thing users needed did not disappear; it changed. When anyone can publish, what people need stops being access and becomes discovery: helping people find what they want in an ocean of noise. Someone has to filter, rank, and present it. The firms that did it best — the aggregators — became the place users actually stood, and the customer relationship moved to them.

Discovery has a property the physical layer never had: it improves the more people use it. Every additional user supplies a signal about what deserves attention, which sharpens the results, which draws more users. Economists call this increasing returns; the everyday name is network effects. They are why an aggregator's position, once taken, is so hard to take back. The product is not really the software. It is the crowd.

That is the first place in this argument where network effects matter, and it is worth being precise about what they do. They do not make the aggregator better at building software — that is the next beat of this section. They make its position self-reinforcing. The moat is on the demand side, not the supply side.

The constraint was code; the aggregators positioned themselves to leverage it to capture the market. Discovery — the feed, the ranking, the search — was the function the code bought.

The old constraint

In 2011, Marc Andreessen published “Why Software Is Eating the World.” Read closely, it was an announcement: every industry on earth was about to need code, and whoever could supply that code fastest would take the ground.

The constraint was people who could write code — and there were never enough of them. The numbers are on the record. In May 2010, American employers counted 499,280 applications software developers and paid them a median of $87,790 a year. Four years later the count was 686,470 and the median was $95,510 (BLS, May 2010; May 2014). The number of people who could write the code grew by more than a third, and the price of each one kept rising anyway.

Put a round number on it. A fully-loaded engineer-month — salary, benefits, overhead — call it roughly $20,000. A five-person team for three months is fifteen engineer-months, about $300,000, and none of it is a machine. The expensive part of software was never the computers. It was the people.

That one fact set the pace of everything else. Marketing could not ship a feature. Capital could not ship a feature. Only code could, because functionality is improved by writing code — and code came out of a slow, expensive, people-shaped funnel.

So for more than a quarter century, the game was simple: accumulate function. Whoever could put more capabilities into more places, faster than the next company, won. Roadmaps were feature checklists; feature quality was the whole fight. Again, software is eating the world. And the prize went to the place that met the constraint: Silicon Valley came to dominate Wall Street. Five technology companies alone — Amazon, Apple, Alphabet, Microsoft, Meta — are now worth about a quarter of the S&P 500 (Big Tech).

The market never saw the constraint. Nobody chose the company with the most engineers; they chose the best performing app. What users experience of a scarcity is its output, and the output of the code constraint was software — above all the discovery machine, which the winners could build because they had the most coders. That is why the two looked like one position: the crowd on one side, and the capacity to keep building on the other. It is also why either one was easy to mistake for the thing that would last.

The lock-in

By the 2010s the winners held both sides: the demand, through discovery and the network effects that fed it, and the supply, through code. What remained was to make the position unassailable — and the way to do that is to make leaving expensive.

Economists call a market you can freely enter and leave a contestable market. The theory, associated with William Baumol in 1982, is that even a market served by very few firms can behave competitively — not because the incumbents are nice, but because potential entrants are waiting and can move the moment an incumbent misbehaves. The discipline comes from the threat of entry, not the number of firms. A monopolist who can be undercut tomorrow prices today.

Contestability has two free things, and for most of software's history we had neither. Entry was expensive because code was the constraint. Exit was expensive for the same reason entry was — the functionality you wanted limited your choices — and because of the crowd: the people you cared about were already inside. Both of the winners' advantages raised the cost of walking away.

Here is an example that shows why enshittification happens. Take a service with a million users paying $10 a month: $120 million a year. Now raise the price to $15 and watch what the cost of leaving does to the arithmetic.

If users cannot leave, the rise is pure profit: $60 million more, overnight. That is enshittification, and it is rational — the company is doing exactly what the constraint permits. If users can leave at near-zero cost, the incumbent has to survive the churn. At 33% it is back where it started; past that it is destroying its own revenue. The same price rise that was free money becomes a gamble. Nothing about the company changed. Only the cost of leaving changed. That is the whole calibration: degrade the product just enough that the extra extraction beats the users lost, and never enough to make the exit worth taking.

A market you can leave is a market that has to earn you.

That is how the machine was built. It was never a moral failure; it was a position that made extraction safe. And it held for as long as entry and exit stayed dear: entry was dear because code was scarce, and exit was dear because neither the functionality nor the crowd could be carried with you.

The Collapse

The internet made distribution free — that was section 3's first move. Now AI is making code cheap. Same event, one layer down, same shock.

The evidence is not anecdotal. In a 2023 controlled experiment, developers given an AI pair programmer finished their task 55.8% faster than the control group. In a 2024 randomized trial inside Google, 96 full-time engineers completed a complex, enterprise-grade task roughly 21% faster with AI assistance — with a wide confidence interval, so treat the exact number as a range, not a promise.

Predictions run ahead of the measurements. In March 2025, Dario Amodei, Anthropic's chief executive, said at the Council on Foreign Relations: “we're not far from the world — I think we'll be there in three to six months — where AI is writing 90 percent of the code. And then in twelve months, we may be in a world where AI is writing essentially all of the code.” That is a bet about direction, not a result; the controlled trials above are the evidence, and the timeline belongs to the person making it. What matters is that the people building the tools expect the constraint itself to disappear.

So the honest statement is not “AI writes your software.” It is narrower and larger at once: the price of producing a working line of code fell, by a lot, and it is still falling. A task that took a week takes a few days. Run the earlier estimate again and fifteen engineer-months becomes nine, or six, or three. The exact number is not the point. The shape is.

What is collapsing is the commodity layer of software — the plumbing, the forms, the integrations, the tests that everyone writes and nobody differentiates on. That layer is falling toward the marginal cost of asking. Which is precisely what distribution did the last time this pattern ran.

Note what is not collapsing. Judgment. Taste. Trust. Distribution. And ownership — the subject of the rest of this essay. AI is very good at producing the part of software that was always the same. It is not producing the part that decides who gets to keep the value.

Here is the asymmetry. Section 3's machine rested on two things: entry was expensive because code was scarce, and exit was expensive because the functionality and the crowd were not portable. AI breaks the first one — anyone can now build the alternative. It does not break the second: the functionality gets cheaper as code does, but the crowd does not move because of AI. Contestability is a condition, not a guarantee. It holds only while entry stays cheap and exit stays free. Entry is now cheap. The other half — what exit costs — is section 10's first prescription.

When anyone can build it, building it stops being the question. Ownership becomes the question.

Last time, the constraint was code, and the position held because users could not build the functionality themselves — and because network effects supplied the rest: the platform's features arrived with the crowd. Now the functionality can simply be asked for. Which leaves the one question the code constraint cannot answer: What is left to compete on?

What's Left to Compete On

When the constraint moves, what competitors compete on moves with it. The old constraint was code; the new one is the user's capture of the surplus. App functionality was the old access, and adding functionality is now effectively free.

The feature that took a quarter takes a weekend, so features stop being a moat and become table stakes. Every “unique” capability is copied within a release cycle — often within a demo cycle. A feature checklist is no longer a strategy. It is a to-do list your competitor already has.

The move is not instant, and it is not automatic. The first effect of a cost collapse is not a new axis; it is cheap entrants attacking the incumbents on the old one. When distribution went to zero, anyone could publish, and for a while that looked like individuals competing with newsrooms. It was rough on the newsrooms. American newspaper advertising revenue fell from about $49.4 billion in 2005 to about $9.8 billion in 2022 — roughly four-fifths of it gone. And newsroom employment across the news industries fell from roughly 114,000 in 2008 to about 85,000 in 2020 (Pew Research Center, newspapers fact sheet; newsroom employment). The newcomers hollowed out the commodity layer of news — opinion, rewrites, aggregation — while the part that was actually expensive, original reporting, did not become cheap. And the bloggers did not win. What won was a different move entirely: organising the abundance. Ranking, filtering, curation. The value went to whoever found and owned that axis, not to whoever produced the old thing more cheaply.

The same applies here. Cheap code lets a small team attack an incumbent on function — the old axis — and that will be rough on the software incumbents. It does not follow that the attackers win. The value flows to whoever owns whatever becomes scarce next, and the default is that someone else claims it. The axis has to be found and claimed, not waited for.

So how do you choose between two apps that can do the same things? Function is no longer the answer — everyone has it. Function was the old access: the thing you had to have to be in the game, not the thing you chose between. What is left to compare is not what the app does. It is who gets the surplus — the value the users create, and who gets to keep it. That is the fight the incumbents have been winning for a quarter century, and network effects are how they win it: the crowd is the moat. But a network effect is not a wall. It is a crowd, and a crowd is made of people who can leave. Sharing the surplus is what pulls them away, and every member who leaves makes the crowd that stayed a weaker reason to stay. Enshittification is what happens when the users of an app are not its owners. The other question is the interesting one: what happens when the users are the owners?

When the users own the app:

• The users are not the product by default — their data is theirs to sell, or not, and on their terms.
• Features that serve advertisers and hurt users never make it onto the roadmap.
• Value generated by the user base is returned to the user base.
• There is no extraction, because there is no incentive to extract: the owners are the users, and they want an app that works, not a return on invested capital.

Two products can now do the same thing for the same price and still not be equivalent — because one of them can profit from making your life worse and the other cannot. That difference is what is left to compete on.

Ownership

Section 3 told the story: distribution fell to zero; discovery became the function; the aggregator that built the best of it took the customer relationship and held it with lock-in. That was the last generation's story. It is also a warning, because the move that did it is available again.

But this time is different in the one way that matters. The thing that made capture profitable — the cost of building — has collapsed. A cooperative no longer needs a venture round to build a credible alternative. It needs its members. Which means the people who use the app can be the people who own the app.

It is fair to object that cheap building helps an incumbent just as much as a co-op; two free things help everyone. But the collapse does not help both sides evenly, because it removes the reason investor ownership was necessary. Building a software business used to require a large cheque up front — servers, engineers, years of runway — and whoever wrote that cheque owned the surplus. Capital was the lever to the constraint, and the lever decided the ownership form. Shrink the cheque to the cost of a few members' subscriptions and the form becomes a free choice. That is the asymmetry: cheap building does not make a co-op better, it makes investor ownership optional. And when the form is optional, the form with no extraction incentive is the one that wins.

And when the owners and the users are the same people, the ratchet breaks at the source. There is no outside owner demanding a return, so there is no pressure to extract. No features that serve advertisers at the users' expense, because the users are the ones deciding. Value generated by the user base goes back to the user base, because there is nowhere else for it to go. There is no incentive to enshittify when the owners and the users are the same people.

That is the opportunity the collapse of code creates — and it is worth naming plainly: not just cheaper software, but a different answer to the ownership question. For the first time, the ownership form that has no reason to extract is also the form that can afford to compete.

What the Surplus Is For

Stopping the extraction is only half of what ownership buys. The other half is this: ownership decides what the surplus is for.

An investor-owned company has one objective it cannot escape — a return on the capital it raised. The reason a corporation exists is to return money to its investors. Sometimes it is a dividend or a buyback; sometimes it is a bet. Meta has billions of users dealing with its enshittified products. Almost none of them wanted the Metaverse, and yet $80 billion of the surplus they generated was directed toward it. The users watch money from a surplus they created get spent on things they do not want. The spending is not the scandal; the allocation is. With corporate ownership, the owner of the app decides how the surplus is spent, not the people who generated the surplus.

A member-owned service answers to a different objective: the welfare of its members, which is not a single number and does not have to grow. That freedom shows up, concretely, in what the members do with the money.

There is a prior choice, before any of that: the co-op can run at cost or above cost. At cost, the benefit is the extraction that never happens — the price is the cost of the service, full stop. Above cost, the benefit is a surplus the members get to allocate. Neither is the “real” co-op model. It is a decision, and it is theirs.

Run the arithmetic on a small one. Ten thousand members pay $5 a month, and the service costs $300,000 a year to run — compute, moderation, support, compliance. That leaves a surplus of $300,000 a year, and the members decide what it is for:

That is one piece of software and three different organisations, each with a different answer to “what is this for?”

The levers run longer than the table: lower the price, hold a reserve, reinvest in the service, pay the people who do the work (content, moderation, development), return a dividend, or fund something the members care about. As the member base grows, the fixed cost is spread thinner and the surplus — or the price cut — grows with it. It does not fall to zero: serving people has real continuing costs, and AI features can add a per-use cost of their own. The surplus is real, and bounded, and the members get to argue about it.

Data is the same choice in its sharpest form. Where the users are the product, their data is sold to advertisers, and they get nothing but the service. Where the users own the product, that data is theirs: they can vote to sell it at an agreed price — and split the proceeds or cut what the service costs to run — or refuse to sell it at all. The objection to surveillance was never that a transaction happened. It is that the transaction happened without consent, quietly, and the money went somewhere else.

Which is why there will not be one co-op model but a community of them. Co-op models will speciate to fit their users. Patron-owned, worker-owned, platform co-ops, small communities, and a few that grow to scale — each settling its own answers on price, surplus, data, and governance. Most will be small, because governance is easiest where everyone can see each other. The ones that grow will be the ones that design against the same capture pressures that took the last generation — and they will have to, because scale is still where the attention lives.

The Closing Window

The hard part is not building it. It is being seen. The threat is not that someone re-fences the portability layer — it is closer and simpler than that: whoever owns attention decides what gets seen.

The login, the feed, the app store — that is where demand actually lives, and it is owned by the same incumbents section 3 described. A member-owned app that cannot be found does not compete. Building is cheap; being seen is not. That is the honest weakness in the co-op case, and it is better stated than waved away.

So the fight is over distribution one layer up: not who hosts the code, but who is allowed to be found. There are three answers, and none of them is guaranteed:

• Open protocols. If the way you reach people is a protocol anyone can implement — email, the web, RSS — then no single owner controls discovery, and a member-owned app can be reached without asking permission. An open rail is somewhere a co-op can stand.
• Owning the demand layer. A co-op that also owns its discovery — its own front door, its own list, its own members' attention — does not depend on an aggregator's algorithm. This is harder, but it is the same move the aggregators made, run in the other direction.
• Word of mouth. Slow, unglamorous, and the one channel no incumbent can tax. It is how most things that are genuinely good actually spread.

The window is open because two things are true at once: the constraint is down, and the ownership form is still unclaimed. The incumbents are entrenching network effects and habit in the meantime — every default, every login people do not want to leave, every app-store placement is another wall around attention. That is the case for acting while building is cheap: the opportunity is real, but it is not permanent.

Counterarguments

Three objections are worth taking seriously, because the honest case for member ownership has to survive them.

“Co-ops atrophy.” The historical record is not flattering. Member-owned organisations drift: decisions get slow, committees capture the agenda, the members stop paying attention, and the thing ossifies. That failure mode is real. But it is a failure of governance, not of the form — and the relevant comparison is not a co-op against an ideal company. It is a co-op against a company that will enshittify as soon as it can. An ossified co-op is disappointing; an ossified platform is extractive. The structural advantage — nobody outside is owed a return — does not disappear because governance is hard. It means governance is the work.

“Co-ops are inefficient.” Investor ownership concentrates decision rights and points everyone at growth, which can be fast. That speed was worth a great deal when building was the constraint. Now that building is cheap, the scarce things are attention and trust, and both of them punish the ownership form that betrays its users. Speed in the service of extraction is not efficiency; it is just a faster route to the same ratchet.

“It only works because it is subsidised.” The objection says a member-owned app exists only because it rides on open source, donated infrastructure, or someone else's generosity — that the real costs are being paid elsewhere, and the co-op is living on them. But that is the essay's own premise turned around. Those costs are falling, and the falling is the event the whole argument is about. Calling the collapse a subsidy is a way of insisting the old constraint still binds. It does not.

One thing runs through all three objections: each assumes that governance is expensive. Historically it was — running a large member-owned organisation meant meetings, minutes, newsletters and a bureaucracy to hold it together, and that overhead is what kept co-ops slow and small. That cost is falling with everything else. AI can document what the organisation does, gather and summarise member feedback, translate decisions for a distributed membership, and keep everyone informed without a standing staff. The same collapse that makes a member-owned app affordable to build makes it affordable to run. If governance was ever the reason a co-op could not scale, it is a weaker reason every year.

None of this makes member ownership inevitable. It makes it available — which is new, and which is what the last section is for.

The Prescription

The argument has been long, so let it end with a short list. None of this is a prediction. The point is that the outcome depends on what people do with a constraint that has, for the first time, come loose.

• Make leaving cheap. The exit cost is the mechanism that decides whether owners can take the surplus. Prefer products that let you take your data, your identity, and your relationships with you. Build that exit into anything you make. Support portability and interoperability — every rule that lowers the exit makes extraction harder.
• Choose ownership when you build. If you are starting something now, the old reason to hand it to investors — the size of the cheque — has shrunk. You can keep it, share it, or run it as a co-op, and still compete. The form is a choice in a way it was not five years ago. Make it deliberately, because the default will be chosen for you.
• Own the demand, not just the supply. A better product that cannot be found is not competition. If you build something member-owned, spend as much imagination on being found as on being good: your own front door, your own list, open protocols, word of mouth.
• Pay for what you use, or own it. Free is a business model, and the business is you. The member-owned alternative usually costs money and gives it back. That is not a worse deal; it is the whole difference. A customer is not a product.
• Do not wait for the window to close. Incumbents are wiring habit and network effects into place right now. The moment to claim the ownership form is while the constraint is down — which is now.

Sources

Every claim above is linked inline at the point of use. This is the same list, collected for re-checking, with the licence last. The agent verified each link before publish; the reader verifies each again at the publish gate.

• Cory Doctorow, “The ‘Enshittification’ of TikTok,” Wired, 2022.
• Elliott Investment Management — Wikipedia.
• Liebig's law of the minimum (Justus von Liebig, 1840) — Wikipedia.
• R* rule — Wikipedia.
• Rate-determining step — Wikipedia.
• Theory of constraints — Wikipedia.
• Eliyahu Goldratt, The Goal (1984) — Wikipedia.
• Ben Thompson, “Aggregation Theory,” Stratechery, 2015.
• Marc Andreessen, “Why Software Is Eating the World,” 2011.
• U.S. Bureau of Labor Statistics, Occupational Employment Statistics, May 2010 — applications software developers.
• U.S. Bureau of Labor Statistics, Occupational Employment Statistics, May 2014.
• Big Tech — Wikipedia.
• Peng et al., “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot,” 2023.
• “How much does AI impact development speed? An enterprise-based randomized controlled trial,” 2024.
• Dario Amodei, CEO Speaker Series, Council on Foreign Relations, 10 March 2025.
• Pew Research Center, Newspapers Fact Sheet.
• Pew Research Center, “U.S. newsroom employment has fallen 26% since 2008,” 2021.
• Contestable market — Wikipedia.
• Vendor lock-in — Wikipedia.
• Reality Labs — Wikipedia.
• Ron Davison, The Fourth Economy: Inventing Western Civilization (2011) — Internet Archive.
• Cory Doctorow, “The Reverse-Centaur’s Guide to Criticizing AI,” Pluralistic, 2025.
• This essay's licence, CC BY-SA 4.0.