A friend of mine lost two years of his life and several million pounds of his own money on software that worked perfectly. The features were brilliant, genuinely ahead of anything AutoTrader had at the time. Then the users arrived, the traffic grew faster than the system could scale, and it fell over. The business never recovered. He will tell you himself: the architecture was wrong, and the launch was rushed, with no real load testing.
Here is the uncomfortable truth that story illustrates. There are two kinds of software quality. The kind you can see, and the kind you can't.
The kind you can see is the one everyone talks about: does it work, does it look good, is it a pleasure to use. The kind you can't see is the one that decides whether your company survives: does it stay up under load, does it resist attack, can it be changed without falling apart, will it still cope when you have ten times the users. The second kind is invisible right up until the moment it isn't, and that moment usually arrives at the worst possible time. During scale-up. During a fundraise. During an exit.
Three companies that learned it the hard way
My friend's car-trading site is the first. Visionary features, no competitor close, and none of it mattered once the user base outgrew the architecture.
The second: a major university website that went offline for most of a day during clearing, the single day in the year when it receives the flood of new applications. Estimates of the lost revenue run between £8 and £21 million. The site worked fine every other day of the year. It just couldn't take the one day that mattered.
The third one is mine. At my previous company, GeoVS, we lost our first sale of a £300,000 system because the back end of our distributed sensor platform could not perform under real conditions. That one hurt. We learned, re-architected, and the same platform now runs at national scale in several countries, monitoring critical infrastructure worth hundreds of billions of dollars, and it is known for never going down. There is a sting in the tail. Years later, when we sold GeoVS, one of the reasons the buyer went ahead was a testimonial from that very first client, the one who had refused us. They said it was the first and only system they had ever used that never crashed. We won them back. But the early failure cost us ground we never fully recovered, and a better exit.
None of these failures were about features. Every one of them was about the quality nobody could see until it was too late.
Why it keeps happening
So why does it keep happening? Because software quality means different things to different people, as Gerald Weinberg put it. The business side owns the visible quality: the features, the experience, the thing the customer is sold. The engineers own the invisible quality: the load tests, the security, the architecture that has to hold. And the two halves too often don't talk. Each assumes the other has it covered. Neither does.
I once worked with an engineer who told me, with a straight face, that users expect bugs. He was the reason we lost a first sale. That attitude, the quiet belief that the invisible quality is someone else's problem, is more expensive than any feature you will ever cut.
The fix is not complicated, but it takes intent. Treat the invisible quality as a first-class business concern, not an engineering detail. Load test before launch, not after the outage. Make security and scalability someone's explicit responsibility, with a name attached. And get the two halves of the team in the same room early, because business requirements are better when they are technically honest, and architecture is better when it understands what the business is actually betting on.
Why this is suddenly more urgent
AI now writes a large share of the code in many companies, and it is very good at the quality you can see. It produces working features, clean-looking functions, plausible output, fast. What it is weakest at is exactly the quality you can't see: the architecture that holds under load, the security that assumes someone hostile is on the other end, the maintainability that a human will have to live with in two years.
The volume of code is going up, and the share of it that any human has truly examined is going down. That is why the percentage of AI-generated code is a vanity metric: it counts the quality you can see and tells you nothing about the quality that kills you. The invisible quality has never been easier to neglect, or more dangerous to ignore.
Tom DeMarco offered the definition of quality I keep coming back to: a product's quality is a function of how much it changes the world for the better. A clumsy product nobody trusts, or one that falls over on the day that matters, never gets the chance. The visible quality earns you the user. The invisible quality is what lets you keep them.
If you are scaling, raising, or heading toward an exit and you are not sure how much invisible quality your product is carrying, that is exactly the thing worth checking before someone else checks it for you. Let's talk.
Related: 75% of Google's new code is AI-generated. So what? · You're not a 10x engineer. You're an orchestrator · How to unlock AI ROI: what the 20% do differently
