← All writing

In short. Anyone can now write the software; that part is nearly free. The expensive part was never the writing. It is everything a running system makes you owe: duties to the people in the data, a watch on every connection to another system, an answer when it breaks, a successor when its builder leaves. These are debts with creditors and no final payment, and AI cancels none of them — it only changes who can sign up for them. The system your organisation depends on is software you own owe. The question is whether to hold that debt yourself, or pay someone to hold it for you.

On 8 February 2011 a memo from Nokia's new chief executive leaked to the press. It ran to about thirteen hundred words, and it began with a story.

A man is asleep on an oil platform in the North Sea. An explosion wakes him. He reaches the edge and looks down at freezing water, and he jumps. "We too, are standing on a 'burning platform'," Stephen Elop told his staff, and the fire was their own: they had "poured gasoline" on it themselves. Then he told them where the company was jumping. It was Windows Phone.

Night on the deck of an oil platform: a steel guard rail in the foreground, dark water far below catching faint light, and a warm glow from somewhere off-frame.

Nokia was then still the biggest phone maker on earth, and the burning platform was its own software: Symbian, which ran more phones than any other system, and which Nokia had been building for longer than Apple's and Google's platforms had existed, combined. But they were the wrong years. Writing a Symbian app was notoriously hard, an app had to be adjusted for model after model, and Nokia's app store had opened the year after Apple's. By the month of the memo, Apple's store held more than 300,000 apps and Android's about half that; Nokia's held fewer than 50,000. Developers were spending their years where the users were arriving, and users were arriving where the apps were. Elop named the fire exactly: "The battle of devices has now become a war of ecosystems," and Nokia's competitors weren't taking its market share with devices, but "with an entire ecosystem."

Elop himself had arrived from Microsoft the previous September. Three days after the memo leaked, he announced the jump: Nokia would drop its own software and build its phones on Microsoft's new Windows Phone. He had considered Android, he said, and turned it down: Nokia would have had difficulty standing out in that crowd, and the risk of becoming a commodity was too high. And the platform he chose was not a bad one. When Windows Phone had launched the previous October, the Wall Street Journal's technology critic, Walt Mossberg, had found an interface "novel and attractive" that "stands out from the Apple and Google approaches". The complaints were about what was missing — multitasking, copy and paste, and a store with a few hundred apps in it. That store had since grown to only a few thousand: smaller than the one Nokia was abandoning. Elop knew it, and said what the jump was really for. Nokia and Microsoft would pool what each had — Microsoft's tools, developers and money, Nokia's scale and reach — and build "the third ecosystem". He declared it done on the day — "It is now a three-horse race" — and was still saying it at the industry's annual congress days later.

Most people deciding what software to build or buy this year are standing nearer that edge than they think. The jump has never been cheaper. The landing costs what it always did.

The wrong side of it

The jump did not save Nokia. You are not reading this on a Nokia, and you have probably never held a Windows Phone. Symbian's sales collapsed faster than Windows Phone's could grow, even with Microsoft paying Nokia $250m a quarter in platform support — billions over the life of the agreement — to keep the third horse running. In September 2013 Microsoft agreed to buy Nokia's phone business — by then the maker of nearly all Windows Phones — rather than watch it fail. The purchase completed in April 2014, at about $7.2bn including a licence to Nokia's patents. In July 2015 Microsoft wrote off $7.6bn, more than the headline price, and announced cuts of up to 7,800 jobs. In the first three months of that year Windows Phone had taken 2.5% of the smartphones sold.

Why didn't it work? Part of the answer had been written twelve years earlier. The US government had sued Microsoft for protecting its Windows monopoly, and in November 1999 the judge, Thomas Penfield Jackson, set out his findings of fact — what the trial had established — and one puzzle ran through them. Copying software costs almost nothing. Why did nobody displace Windows?

Writing the code was not the difficulty, the court found, and this was a quarter of a century before coding agents. Once a firm had written it, "it could produce millions of copies of its operating system at relatively low cost." The difficulty came afterwards. "The ability to meet a large demand is useless, however, if the demand for the product is small."

Demand for a new operating system would be small, the court explained, because consumer interest in one "derives primarily from the ability of that system to run applications." People wanted Windows for what ran on it, and developers wrote for Windows because people had it. For a newcomer that was a closed loop, and the court put it in a single line: "What for Microsoft is a positive feedback loop is for would-be competitors a vicious cycle." It called the loop the applications barrier to entry. Anyone who has tried to start a marketplace knows it by a plainer name, the chicken-and-egg problem: buyers won't come without sellers, and sellers won't come without buyers.

The barrier was made of other people's work. A rival could write everything else as cheaply as it liked, and still could not write that. In 1999 the applications barrier had been Microsoft's moat. In 2015 it was the wall on the other side. Microsoft could buy the company, the handsets, the engineers, the IP. It could not buy the applications, because the people who wrote them had little reason to write for a platform few people owned, and few people owned it because the applications weren't there. Same company, same engineers, same skill at writing code. The only difference was whether other people had built on it. Elop had rejected Android because of the crowd. The crowd was where the applications were. And an ecosystem, it turned out, was not a thing two companies could decide to build, with money and a plan. The barrier held against the firm it had once protected.

And nobody had less excuse to believe it would yield. A court had spent a year describing how the applications barrier kept every rival out of Windows, and Microsoft had spent the decade since living behind it. In phones it bet that the wall it knew best would give way to money and skill — that it, of all firms, would be the exception.

One firm and one bad bet, or something more general? An economist at the London School of Economics called John Sutton spent the 1990s on exactly that question.

Three bills

Sutton looks at two costs that a firm pays before it sells anything. The first is the entry fee: what it takes to make the thing at all, which the technology sets. The second is what the firm chooses to spend so that buyers want its version rather than a rival's: research, advertising, polish. Economists call them exogenous and endogenous sunk costs. For our purposes, the entry fee and the cost of being wanted will do. Notice that they are paid in different currencies. The entry fee is paid in money and your own time, and it has just collapsed: work that once needed a contract with a software company is now a deep conversation between you and Claude (other AIs are available). Much, much smaller but not yet zero. The cost of being wanted is paid in years, and they are not yours to spend, nor anyone's to buy: reputation, trust and habit live in other people, and arrive no faster for being cheap to start.

That is the Nokia deal in two lines. The partnership was a way of skipping the entry fee: Microsoft had already built the operating system, and it paid Nokia to use it. Neither was a contender alone — Nokia's platform was burning and Microsoft's was unwanted — and the bet was that two trailing horses, harnessed together, would make one credible third, at almost no cost of entry to either. The second bill never went away. Being wanted — by developers first, then by buyers — could not be paid in Microsoft's currency, and declaring a three-horse race did not make the third horse wanted. The move failed not because it was irrational but because it paid the wrong bill. And AI now makes everyone a version of that offer: the entry fee, mostly paid. It leaves you standing where Nokia stood, with the second bill untouched.

Cheaper tools cut the entry fee and nothing else. What happens next depends on what buyers want.

Take restaurants. Opening one is cheap enough that anyone can, and every diner wants something different: a curry, a pizza, somewhere quiet. Make opening cheaper still and you get more restaurants, and the biggest chain's share keeps shrinking. Call that proliferation: a crowd. Now take aircraft. Every airline wants the same thing, the lowest cost for each passenger for each mile. One ladder, and everyone climbs it. Buyers agree what better means, so a firm can buy a better product by spending more, and if the entry fee falls the prize for outspending everyone only grows. A few makers hold the market however many others try to enter. Call that escalation: an arms race. The difference is nothing about the sellers and everything about the buyers. Wanting different things makes crowds; agreeing on what better means makes arms races.

A narrow British street at dusk, lined with small, different restaurants, each warmly lit in its own way, reflected in wet pavement.

A single unmarked airliner under assembly, nose-on, dwarfed by a vast, dim assembly hall lit by a single light from above.

In both markets the second bill buys the same thing: a reason to be chosen. Every seller tries to carve out ground of its own — the only quiet room in town, the lowest cost per seat-mile — and the buyers decide whether the carving holds. In a crowd it holds almost everywhere: buyers who want different things leave room for every seller to be somebody's first choice. In an arms race it holds only at the top, because buyers who agree on what better means collapse every niche into one ranking. And a market can be full of sellers without being a crowd in this sense. Android had many phone makers, but their buyers wanted the same phone, so the makers were not carving niches; they were underbidding each other on the same thing. There is a name for where that ends — a commodity, chosen on price and nothing else — and it is the one Elop reached for when he turned Android down.

Software that stays in service has a third bill, which Sutton's model leaves out because it arrives after the sale: keeping the thing running, fixing it, and picking up the phone when it breaks. It never stops, and cheaper tools don't touch it either. What tames it is scale: divided across a thousand customers it is a line on an invoice; divided by one, it is a salary.

I haven't found anyone who has applied Sutton to software, so the application is mine, as are the restaurants, the labels and the third bill. The test they give you is two questions. Do your buyers — and your competitors' buyers — want many different things, curry versus pizza, or do they all want the same thing, the efficient airline? And who will still be paying the third bill in year five?

Run the test on the market Nokia died in. Every buyer wanted the same thing, the phone that ran everything, and every developer wanted the same thing, the platform where the users already were. One ladder: an arms race, not a crowd. Windows Phone was Nokia's attempt to carve — to stand apart rather than be one more maker of the same Android — and the carving worked: Mossberg said so. But standing apart only pays where buyers want different things, and smartphone buyers did not. That is why there was no prize for coming third. In a crowd, third place is a living; in an arms race, it is a $7.6bn write-off. Elop's own phrase, the three-horse race, named the shape exactly — he just missed that races of that kind pay only the first two. And where aircraft makers escalate in money, which Microsoft had more of than anyone, platforms escalate in other people's years, the one weapon its money could not buy.

Software for membership organisations and charities — the market I know, and I will come to why — is the opposite case: a crowd, closer to the restaurants than to the aircraft. A professional institute, a sports body and a small charity all "manage members", and each means something different by it, so there is no single ladder to climb, no race to be the number one supplier, and nobody has ever swept the market. Cheaper building brings more builders, not one winner. In a crowd, what separates suppliers is the cost of being wanted and the third bill: who understands you, who is still there — and how many customers they divide that bill by.

Nearly nineteen thousand games

Games let you watch both outcomes in one industry. Unity made its engine — the software a game is built on — free to independent developers in October 2009, and Unreal Engine followed in March 2015. Steam, the shop where most PC games are sold, opened its doors wider with Greenlight in 2012 and wider again with Steam Direct in 2017. Until 2012 roughly 250 to 300 games a year reached Steam. By 2024, per SteamDB, it was nearly 19,000.

Over the same years the top end did the opposite of getting cheaper. Raph Koster, who tracks the cost of big-budget games, finds it rising about tenfold every ten years. Call of Duty: Black Ops Cold War cost more than $700m to develop over its life, according to an Activision court filing — spent defending a franchise that has been accumulating players since 2003. Cheap tools did not make games cheaper. They made them bigger.

At the other end, Sandfall Interactive, a studio with about thirty core staff, said it spent under $10 million on Clair Obscur: Expedition 33, a turn-based role-playing game, not counting marketing. It had sold eight million copies by April 2026. A crowd at one end and an arms race at the other, in the same years. A newcomer can still win in games, because a game asks so little of its buyer: a player risks one evening on an unknown studio, the way a diner risks one meal on a new restaurant.

The engine kept almost nothing: Unity itself lost $402.8m on $1.85bn of revenue in its 2025 financial year. The money pooled at the one thing players had committed years to: the shop — an arms race of its own, and one already won. Steam holds their libraries, their friends and their saved games, and it decides what they see. By the start of September 2026, 17,200 new games had been released on Steam that year. On one estimate built on VG Insights data, the median release earns roughly $1,000 across its lifetime — before the shop takes its cut.

What you can't write

Put the stories side by side. In 1999 the value of an operating system sat in the applications written for it. In games it sits in the players' accumulated stake in one shop. Each time the software was the cheap part. What was not cheap had taken years to build, and had mostly been built by other people: developers' commitment to Windows, players' to a store. You can write the software. You can't write the years behind it.

The years are not calendar time — Symbian had more of that than iOS and Android together. They are other people's commitment, and commitment looks forward: developers write for where the users are going, and users go where the apps will be. The past is the evidence that the loop will keep spinning. A platform with momentum is one whose years other people expect to continue.

That rule answers the question every board has started asking: who is about to build us out of business? People are trying. In February 2026 one Cloudflare engineer, working with AI for under a week, rebuilt Next.js, a popular web framework, for about $1,100 in AI usage, reaching 94% of its interface by Cloudflare's own count. Cloudflare called it experimental, said some customers already ran it, and security researchers have since reported flaws in it.

In October 2026 a developer released PhotoCraft, a Photoshop-style editor with AI doing much of the work. It is in early alpha and calls itself a clean-room reimplementation, meaning built without looking at Adobe's code — a claim no third party has verified, and nobody yet knows whether it would stand up. Whether these are rivals or copies that can be challenged is being argued as I write, and I don't know how it will end. What I can say is what neither copies: the files customers already own, a decade of habit, the plug-ins other people wrote, someone to call.

The confidence has a pedigree. Microsoft knew the barrier was real — it had lived behind it for a decade — and still bet $7.2bn that skill and money made it an exception. A developer with a coding agent makes the same bet at a smaller scale, and for the same reason: the code is the part a builder can see, so the code looks like the whole of the wall.

The other question — why not build it yourself? — Nokia had answered too. Symbian was the build-it-yourself option: a decade of building that counted for nothing in an ecosystem war, which is won by the people building on you, not by the people you employ. I have answered the same question at a much smaller scale, from the inside.

Access in the cloud

A disclosure first. I run sheepCRM, a CRM for charities and membership organisations, and it sells one of the answers to this question, so weigh what follows accordingly. It is also why sheepCRM exists.

In 2011 I was helping a charity called Adventure Plus, which ran on a database that a volunteer had built years earlier in Microsoft Access, the desktop database that came with Office. It had been a good solution. Then the volunteer moved on. The charity kept growing and the software didn't, and nobody could maintain it. The same year Elop was writing his memo, Adventure Plus was standing on a small burning platform of its own: years of its own build, and nobody left behind them.

My first thought was to buy. Salesforce was the world leader, so I tried it. It was built around sales funnels, and a charity is not a sales funnel. The biggest ecosystem in the market lost to a poor fit. So I did what I have since called a classic foolish mistake and wrote my own. That took a summer — already, with the tools of 2011, an order of magnitude less than the same build would have cost a decade earlier; the entry fee was falling long before AI pushed it off a cliff. Word of mouth brought the first paying customers in early 2012. One early contact called it "Access in the cloud", which was accurate and slightly deflating.

The building took a summer. The third bill has run ever since — the updates, the fixes, the watching, the answering — and Adventure Plus has never paid it. We have. What they pay is a subscription: their share of that bill, divided among every organisation that arrived after them. From their side of the table, they bought. From mine, it was a build — one that kept its promises only by becoming a software company.

Fifteen years later Adventure Plus is still a customer, and customers staying for ten years or more is common. The volunteer left. In the United States the median worker has been with their current employer for just 4.1 years (Bureau of Labor Statistics, January 2026), so whoever looks after in-house software is, on average, passing through. A supplier that stays is the opposite.

The database did not die because it was hard to build. It died because the person who understood it left, and nobody was left who understood the charity and was answerable for the software. That third bill needed someone to pay it.

The builder in your office

An "Access" is now available again, and a better one than the volunteer's. The person asking the title's question this year is not a hobbyist with a weekend. She is your head of membership: twenty years in the sector, she knows every rule, every renewal quirk, every reason the last system disappointed — and for the first time, she can build. Describe what the organisation needs, iterate patiently for a few weeks, and a system shaped exactly to it exists. Why would she not?

Run her build through the bills and it clears the first two. The entry fee has fallen from a software company's contract to one person's time; the tokens cost money and the refining takes real hours, but she can pay it. The cost of being wanted she never owes: a build for your own organisation is a market of one, and inside an organisation nothing needs to be wanted when it can be mandated. The website team connects to her system because the website team is told to. Even the integrations mostly fall her way, because connecting outward — to the payment provider, the email service — is exactly the work AI does best.

Everything lands on the third bill — and up close, "maintenance" is four different costs wearing one name. The first is labour: fixing what breaks, adding what's missing. AI is cutting it the way it cut the entry fee. The second is vigilance. Every connection she built is a treaty with a counterparty who changes things on their own schedule — the deprecated payment API, the new data regulation, the security advisory — and treaties need watching. Nobody prompts for a problem they don't know exists. The third is accountability: when members' data leaks, someone answers to the board and the regulator. That was never a labour cost, so no labour-saving touches it. The fourth is continuity, and it is the oldest fact in this essay. She leaves. The median worker is gone within five years, and we have already seen it happen: the volunteer who built that Access database was her — the serious domain expert with the accessible tool of the day. AI has changed who can build. It has not changed who leaves.

Whether AI will cut the vigilance too — agents that patrol the borders and watch the treaties — is genuinely open; nobody has been doing this long enough to know. For now the split is clean: the bills priced in hours are falling fast, and the bills priced in attention, liability and tenure have not moved.

What you would own

You cannot write the years but, it turns out, you can rent them — that is what a subscription is. When an organisation buys from a supplier in a crowd market, the £10,000 a year is not buying code, or even features. It is renting years, and not only the supplier's: two hundred organisations like yours have already hit the edge cases, demanded the awkward fixes, justified the integrations and funded the standing watch. Divided across all of them, the third bill is a line on an invoice; carried alone, it is a salary. The renewal was never priced for the code. It is your share of the people who keep it alive, and of the mistakes already made on somebody else's data.

That is what buying is for, when it is for anything. Clients want to be understood — them, their market, their problem — and they want to be certain that someone will take responsibility and still be there. Fit answers the first, and fit is where buying honestly fails: a bought system is the intersection of your needs and the crowd's, and if what you need most sits outside that intersection, no supplier is coming — Salesforce lost this story's charity in a week for exactly that reason. The second is certainty, and it cannot be inspected at a demo. A new company with new technology could be superb, or gone when its funding runs out: seven in ten of the venture-backed companies that have closed since 2023 simply ran out of money, the research firm CB Insights found. A player risks an evening on an unknown studio and a diner risks a meal on a new restaurant; an organisation that moves its members, its money and its history is risking years, and it knows it. Fifteen years is the one thing a newcomer cannot offer, because it can only be earned by waiting. It is evidence, not a guarantee — a small supplier can vanish too. And AI will shorten some of the years: learning a sector's rules is quicker than it was. It does not shorten the time a customer needs to see whether you stay.

So the honest answer to the title is: sometimes, build. Build anything you could cheerfully delete next quarter. Build the wrong version in a week to find out what you actually need — it is the cheapest requirements document ever written — then buy with sharper questions. Build the edges your supplier's roadmap will never reach. And some of what is sold as software today is throwaway-grade and deserves to be built away; a supplier whose product could be regenerated from a plain description should be worried. But the system your members, money and history live inside is none of those things. Building it is not a purchase avoided. It is an institution founded: a one-customer software company, needing succession, a security policy and someone on watch, for as long as the data lives.

A membership organisation already knows this argument, because it is the argument for its own existence: some things are done better by a standing institution than by capable individuals, however capable. Software you depend on is one of them. What AI has really changed is where the question lives. It used to be a budget question — what does building cost? — and that cost has nearly gone, for everyone at once. What remains is a governance question: how many standing obligations will this system gather — treaties with other systems, colleagues who build on it, duties to the people in the data — and do you want to hold them yourselves, or pay to share them? Software was never expensive to write. It is expensive to owe. Build what you can afford to throw away. Buy what has to outlive its builder.

Where he landed

Elop's man on the platform had no choice about jumping. Everything else depended on what he landed on. Nokia landed on good software that nobody else had built on, and a court had already written down why that would not be enough: people want a platform for what other people have built on it.

You are near an edge like that this year — so is anyone weighing a renewal against a rebuild. What are you jumping to? Who has built on it? Who will still be there when you need them — and if the answer is you, for how long? Writing code settles none of it. So when building gets cheap, don't ask what you can build. Ask what you hold that took years to get, what you would owe if you built it, and what you depend on that someone else holds.


James Webster is the founder of sheepCRM and director of Croftsware. This essay is the second in a series on cheap software that began with New Motor, Old Belts.