Hide Your Kids, Hide Your Manual
On why building software is about to be the easy part, why it was arguably always the easy part, and what companies will actually sell once everyone admits it
They are climbing in your knowledge base. They are reading your API reference. They have opinions about the contradiction between chapter seven and appendix C. Hide your kids, hide your manual - although, fair warning, for the manual it is already too late.
An uncomfortable inventory
Let us begin with an audit nobody requested. Take a typical small or mid-sized business - two hundred people, a respectable product, a CFO who sighs in spreadsheets. Its entire digital estate - the CRM, the ERP, the ticketing system, the wiki, the invoicing, the scheduling tool, the dashboard nobody opens, and the eleven subscriptions whose purpose has been lost to history but whose invoices arrive with liturgical punctuality - all of it runs comfortably on a few virtual machines hosting a couple dozen Docker containers. The complete digital nervous system of a real company fits on hardware that would bore a teenager with a gaming PC.
This is the secret the industry guards with pricing pages that require a sales call. Most business software is not hard. It is forms over a database, with a workflow engine and an audit log, sold per seat, per month, forever - the business model formerly known as rent.
The manual was the spec all along
For years the counterargument held. Fine, it is just forms and workflows, but somebody has to build and maintain it, and that somebody bills by the hour. Two things quietly ended that argument.
First, open source finished eating the category map. There is now a serious, free, actively maintained project for practically every box on the org chart - ERP, CRM, analytics, automation, chat, files, identity. I have written about this detonation before in The Open-Source Big Bang - the short version is that when a problem has converged, someone has already open sourced the solution, and the software in those couple dozen containers increasingly costs exactly nothing.
Second, and considerably funnier - for whatever open source does not yet cover, the incumbents helpfully wrote the spec themselves. Every SaaS vendor spent the last decade producing meticulous documentation. Admin guides. Tutorials. API references. Release notes. Certification courses. A complete functional description of their own product - indexed, searchable, and free. Documentation was supposed to reduce support tickets. It turns out it reduces vendors.
Here is the new week. On Monday an agent reads the manual and drafts a detailed specification - every screen, every workflow, every permission rule, minus the four hundred features you were paying for the privilege of ignoring. On Tuesday and Wednesday a second agent walks your actual business users through that spec, clause by clause, asking the one question no vendor ever asked - which of this do you actually use. By Friday there is a working system shaped exactly like your process, running in a container, next to the other containers, on the VM you already own.
Every help center is a requirements document with a search bar. The vendors published the most expensive training data in history and put a chatbot on top of it as a courtesy.
But scale! But security!
At this point the two magic words get deployed - scale and security - pronounced in the tone of a priest naming demons. Some more architecturally inclined will mention the -ilities, although they are rarely on the table for software with small to medium complexity in most cases.
And yes, keeping software alive under hundreds of thousands of concurrent users is genuinely, brutally hard. It is also not your problem. You have two hundred employees and four thousand customers. Your peak traffic event is Monday at nine. You will not be hugged to death by the front page of the internet. Designing your invoicing system for Google's load is buying a fire truck because you own a candle.
Security, then. The researcher James Mickens once observed that every threat model reduces to two cases - Mossad and not-Mossad. If a nation state actually wants into your PTO tracker, it is getting in, and your SaaS vendor is not the shield you imagine - ask the thousands of organizations who installed SolarWinds and discovered that the trusted vendor was the delivery mechanism. For the not-Mossad world, which is your world, the recipe is patched containers, tested backups, multi-factor auth, and sane defaults. Achievable. Boring. Precisely the point.
So if building is cheap, and the famously hard problems do not apply, what remains? One thing. It has always been the same thing, and history keeps immaculate receipts on it.
History keeps receipts
In the year 97, Rome appointed Sextus Julius Frontinus commissioner of its aqueducts. The aqueducts had been built by men long dead - the building was the miracle, and it was done once. Frontinus's actual job, along with his crew of roughly seven hundred, was operations - clearing sediment, maintaining gradient, and hunting the citizens who secretly punctured the pipes to water their gardens. Shadow IT, toga edition. He was so proud of this unglamorous work that he wrote the manual himself.
Around 1450 a monastic scribe needed years to copy a single Bible, and Gutenberg's press produced about a hundred and eighty in one run. The scribes did not survive the century as a profession. Printers, publishers, editors, and librarians did rather well for the next five. When making the thing becomes easy, the value does not evaporate. It migrates - toward choosing, distributing, and keeping the presses running.
Around 1900 every serious factory generated its own electricity, employed a chief engineer to babysit the dynamo, and in some cases a literal vice president of electricity. Samuel Insull's insight in Chicago was not a better generator. It was better operations - load balancing, metering, the economics of shared capacity. Within a generation the private power plant was a museum exhibit, and no company on earth lists "owns a generator" among its competitive advantages.
Elevators once required trained human operators - when New York's operators walked out in 1945, the skyscraper briefly became a walk-up and the city seized. The push button retired the profession. But look at Otis today - the machines are sold at unremarkable margins while decades of service contracts quietly carry the company. The elevator was never really the product. The promise that it keeps moving was.
In 1957 the first FORTRAN compiler shipped and professional programmers scoffed - no machine could match hand-tuned assembly. For a while they were even right, and then it stopped mattering. Every current take insisting that agents cannot write production code is a lovingly restored antique of this argument, right down to the upholstery.
ADP began in 1949 as a few men doing payroll by hand in Paterson, New Jersey. Payroll is arithmetic - multiplication with paperwork - one of the most thoroughly solved problems in mathematics. The company is worth north of a hundred billion dollars anyway, because the product was never the arithmetic. The product is the operation - filings across fifty states, garnishments, deadlines, and someone else's name on the mistake.
In 1962 the jet engine business invented Power by the Hour, and Rolls-Royce turned it into doctrine - airlines stopped buying engines and started buying thrust with a service guarantee. The engine became a line item. The uptime became the product.
In 1993 IBM was dying of commoditized hardware, and Lou Gerstner saved it by pivoting to services. Big Blue survived not by building better machines but by operating everyone else's mess.
Red Hat is the cosmic punchline of software economics. The product is free - legally, permanently, for everyone - and IBM paid thirty-four billion dollars for the company anyway. What did they buy? Not code. You can download the code tonight. They bought the operation - certification, patching, liability, and a phone number that answers.
AWS may be the most profitable operations company ever constructed. It takes software it mostly did not write - Linux, Postgres, MySQL, Redis, Kafka - and charges rent for running it. The honest tagline for RDS is "we do the backups". Entire companies rewrote their licenses in protest, because Amazon operated their software more profitably than they could sell it.
And email, the final exhibit. An open protocol, excellent free servers, four decades of documentation - and virtually nobody self-hosts, because deliverability is a purgatory of blocklists and reputation scores. We do not pay Google for email software. We pay Google to hold email's pager.
Even Kubernetes, the free crown jewel of modern infrastructure, comes with a monthly fee on every major cloud - not for the software, which costs nothing, but for the privilege of someone else running its control plane. We pay it gladly. We have met the alternative.
The business of keeping the lights on
So here is the near future, and it is not subtle.
When agents can read a manual on Monday and ship a validated replacement by Friday, software stops being an asset and becomes exhaust - cattle, not pets, regenerated from spec whenever the spec changes. What does not regenerate from a prompt is everything around it. The monitoring that notices at two in the morning. The backup that has actually been restored, not merely believed in - backups are a theological position right up until you test a restore, after which they become either infrastructure or fiction. The patch cadence. The access reviews. The migration that does not eat a quarter. The runbook. The person, or increasingly the agent, who answers.
The winning pitch stops being "our software does X" and becomes "you will never think about X again". Not software as a service - the software part is table stakes that now writes itself - just service, with an SLA on outcomes. The first S in SaaS was always quieter than the invoices made it sound.
There is a pleasing etymology hiding in here. Before engineer meant someone who designs engines, it meant someone who runs one - the soul in the locomotive cab keeping the fire fed and the wheels on the rail. After a long detour through whiteboards and system design interviews, the industry is returning the word to sender.
The software that refuses to die
Before you short every ticker with "cloud" in the prospectus, the honest footnote.
Some software survives the flood. Real network effects survive - you cannot self-host the fact that your customers are already on the platform. Genuinely hard technology survives - payment rails, frontier models, anything where physics or regulators attend the standup. Deep data gravity survives, for a while, out of sheer inertia. These are the platypuses of the portfolio - too strange, too entangled, too load-bearing to be regenerated from a help center.
What does not survive is the enormous middle - the form-over-a-database apps priced like particle accelerators, defended by a moat that turns out, on inspection, to be a PDF. Per-seat pricing for CRUD is a coastal city, and the sea level is rising by one model release per quarter.
In short
Building was glorious while it was scarce. It is not scarce anymore. The scarce thing - the thing it was in Rome, in Mainz, in Chicago, in every elevator shaft in Manhattan - is keeping it running, keeping it patched, keeping it honest, and picking up when it breaks. That is what companies will sell, because that is what was always being sold underneath the license agreement.
So yes - hide your kids, hide your wife, and by all means hide your manual. Though honestly, it is late for that. The agents already read it. All four hundred pages. They filed a ticket about appendix C, drafted the spec, and validated it with your own operations lead while your account executive was still personalizing the renewal email.
The renewal will not be awkward. It will simply not exist.
The future of software will not be written. It will be operated.