The 90% Threshold
Most software doesn’t need five nines. The new question is: is it useful enough, fast enough?
There’s a class of problems that traditional software development was never designed to solve. Not because the problems were hard, but because the economics didn’t make sense.
Building software used to be expensive. So we planned carefully, reviewed thoroughly, committed reluctantly. We designed for scale, for durability, for the long term. We built systems that needed to be right because rebuilding was prohibitive.
That constraint shaped everything: how we staff teams, how we run projects, how we think about “production ready.”
But the constraint has changed.
The New Class of Problems
LLMs open up problems that aren’t pass/fail.
When you download a file from a server, there’s one right answer: did you get the exact file, bit-for-bit? That’s the software we’re used to building.
When you write an email to a customer, there are thousands of right answers. There are bad ones too. But there’s no single correct email — there’s a range of acceptable outputs that get the job done.
This is the new class: problems where 90% accuracy is genuinely good enough, where human review is part of the design, where speed of iteration matters more than perfection of execution.
The goal isn’t to remove humans. It’s to make humans faster, more informed, more responsive.
Capabilities, Not Systems
The instinct when someone has a problem is to build a system that solves it completely. A “platform.” A comprehensive solution.
This is usually wrong.
Systems are expensive, brittle, and take forever. They encode assumptions that become outdated. By the time they ship, the problem has evolved.
The better question: what capabilities would make your people faster and better at what they’re already doing?
A capability is a small thing that makes someone better at their job. It doesn’t replace what they do — it amplifies it. It doesn’t require a complete workflow redesign — it slots into how they already work.
The Math of Marginal Gains
If you want to double your output, don’t look for one thing that makes you twice as good. Find a hundred things that each make you 1% better.
Easier to find. Easier to implement. Less risk you’ll get it wrong. And they compound.
1.01^100 = 2.7x
A hundred 1% improvements nearly triples your output. And each one is useful on its own, from day one.
Every workflow has a hundred small frictions. “Where’s that file?” “What were the requirements on the last one?” “Did we do something like this before?”
Each friction costs minutes. Some cost hours. Many happen multiple times a day.
You don’t need to build a system that eliminates all of them. You need to start eliminating them, one by one, continuously. Remove a hundred small frictions and you’ve transformed how work gets done.
Bottom-Up, Not Top-Down
Here’s what’s already happening: savvy teams are building their own tools.
A UX designer at a major scooter company is responsible for software used by warehouse operations teams. Corporate tries to build software for them, but it takes forever. Berlin and New York have different operational patterns. Different needs, different constraints, different workflows.
The Berlin hub — staffed with people who know how to use Claude Code — started building their own dashboards. Not because they wanted to go rogue, but because they needed tools and couldn’t wait.
This is bottom-up software development. It’s happening now, in companies that don’t even know it’s happening.
The question for leadership isn’t “how do we stop this?” It’s “how do we enable it?”
The Responsiveness Gap
Traditional software development optimizes for reliability at the cost of responsiveness.
The promise: if you wait long enough and go through enough review cycles, you’ll get something stable that works for everyone.
The reality: by the time it ships, requirements have changed, the team that requested it has moved on, and the people who actually use it find workarounds anyway.
We would rather have responsiveness than a promise of stability with a week-and-a-half turnaround.
This is a genuine trade-off. Not every system can be built this way. But far more can than we currently acknowledge.
If a tool is useful to a team in isolation, and there’s a backup plan if it breaks, that’s good enough. That’s the 90% threshold.
A Different Organizational Model
Imagine a team of one UX designer and one product engineer that travels to the Berlins of the world and just builds solutions.
Not requirements gathering. Not design review meetings. Not alignment sessions with management. Just: understand the problem, build something, see if it works.
The learnings from doing this feed back to the product teams. Instead of product teams trying to anticipate needs from a distance, they receive validated solutions from the field. Instead of spending months on specifications, they see working software and decide what to scale.
This inverts the usual flow:
- Traditional: Corporate defines → Teams implement → Users adapt
- New: Users need → Small team builds → Corporate decides what to scale
The small team isn’t building production infrastructure. They’re building 90% solutions that prove what’s worth investing in.
What This Requires
Different expectations. Not every tool needs to be maintained for five years. Some tools are disposable by design — they exist to solve a problem right now, and if that problem changes, we build something new.
Different staffing. Small teams with end-to-end capability. People who can understand a problem, design a solution, and build it without handoffs.
Different metrics. Not uptime and defect rates. Responsiveness. Time to first useful version. Number of problems solved.
Different relationship with failure. If a 90% solution breaks, you don’t page someone at 3am. You rebuild it in the morning. The cost of failure is low because the cost of rebuilding is low.
The Trade-Off Is Real
This doesn’t work for everything.
If you’re building identity and access management for Boeing, you need five nines. If you’re building payment processing, you need five nines. If downtime means planes don’t fly or people don’t get paid, the 90% threshold doesn’t apply.
But most software isn’t that.
Most software is: help this team understand their data faster. Help this process run with less friction. Help these people make better decisions.
For that software, the question isn’t “is it production ready?” The question is “is it useful enough that people want to use it?”
The Enablement Opportunity
Companies that figure this out will move faster than companies that don’t.
Not because they have better AI tools — everyone has access to the same models. But because they’ve changed how they think about what software is for.
Instead of software as capital investment (expensive to build, expensive to maintain, must last forever), software as operational tool (cheap to build, cheap to rebuild, exists to solve problems right now).
The Berlin warehouse team building their own dashboards isn’t a problem to be solved. It’s a signal to be amplified. They’re showing you what they need by building it themselves.
The smart response: send a team to learn from them, build better versions, and roll that pattern out everywhere.
The default response: tell them to stop and wait for the official solution.
One of these responses creates operational leverage. The other creates frustration.
Implication
The 90% threshold isn’t about lowering standards. It’s about applying the right standards to the right problems.
Some software needs to be bulletproof. Most software needs to be useful.
The companies that internalize this will build more, learn faster, and respond to their people’s actual needs. The companies that don’t will keep losing to teams with Claude Code and a weekend.