Building a software product is hard. It always feels like it takes longer than it should, or at least longer than you expected. Why is that? And will AI deliver on the industry’s promises to revolutionize software development? Or is it all hype and the developers will be left holding the bag?
First, some thoughts on why it seems to take so long.
A new software product
Once upon a time, you decided to build a new software product. You knew it would be hard but worth doing. You interviewed a bunch of users, or maybe you put together some ideas you’ve had for years, and you got started. You built a beautiful and responsive user interface, wrote the backend services in C# (so much better than Java), stored the data in Cosmos (no SQL for you!), and tested it all. It was a lot of work.
There were times when you weren’t sure it would come together, but it did. It looked great! It went into private preview with a few friendly customers and they loved it. I mean, let’s be real: they wanted more features, because of course they did. But it covered most of what they needed.
You sat back and reviewed it all, and you were clearly 90 percent done. And it felt good.
Excitement meets reality
The preview broadened and things got harder. The bigger customers needed better security features. The smaller customers wanted a “lite” version. The reporting functionality you were sure was overkill was totally required. And then it went GA – hurray! Turns out your choice of C# was solid, but a third of your potential customers had old Java plugins that they just could not abandon, so you had to build a C#-to-Java bridge.
Cloud-hosted Cosmos also didn’t meet your enterprise customers’ cybersecurity requirements, so you had to learn how to deploy and operate it on-prem too. And those same customers ran their antivirus software at “maximum paranoia”, which broke the system just often enough to make people really mad, but not enough to reliably reproduce when you tried to fix it. You eventually convinced the customer of the right settings and they stopped yelling at you.
Looking back on the first year of production use, you spent as much engineering effort fixing all these issues as you did building the initial product. Frustrating but hardly unusual. And surely now you were 90 percent done.
The lifetime of a product
Since that first year, you expected to spend most of your time building the next big thing, but the product has never stopped needing attention. Customers want new features, bugs crawl out and have to be squashed, and support tickets need answering. And don’t forget all the libraries that need to be patched and updated (and patched, and updated). So many libraries.
If you’re lucky and the product lasts long enough, you will have to replatform it, AI-enable it, replatform it again, and convert it to Rust when C# gets retired. As long as it has customers you will have to support it, if you want to keep getting paid.
By the time the product finally goes end-of-life, you will do at least as much work supporting it as you did in the first two stages, and maybe more. Now you can put your feet up and relax.
The three 90 percents
These are the three 90 percents: building what you think you need, turning it into what you really need, and then keeping that thing going. The pattern shows up time after time, across scales. From huge projects to little helper scripts, when you think you have done 90 percent of the work, you are probably still closer to the start than to the finish.
Back to the topic of expectations and software seeming to take too long. Everyone expects the first part to take a while; it takes time to build something! But then the second part surprises you, because when you started you didn’t know what you didn’t know. You had a plan and you followed it, but your plan had no hope of being complete because you were building something new. The best you can do is to plan that there will be a lot more work to do after you go live. And the third part shouldn’t come as a surprise to anyone, but somehow it gets overlooked in the planning as we rush on to the next thing. Even after things stabilize in production, you still have a lot more to do, unless you abandon the thing entirely.
Side note: if you are part of a startup or otherwise doing something totally new, your second “90 percent” may be much bigger than the first, if your original idea doesn’t pan out and you have to iterate. The point here is that you will have to do at least another 90 percent after that first stage, and maybe more, and then you’re on to support and maintenance.
How this changes with AI (in 2026)
AI in 2026 is very good at coding, and the first 90 percent is substantially about coding, so AI can help a lot here. You can even vibe-code your way through this part without involving a developer, but if you’re building a product it’s not a good idea – more on this below. Much of the hype around AI as a software industry disruptor (“I built a whole product with a team of one!”) is specifically about the first 90 percent, whether the authors realize it or not.
The second 90 percent is much less about coding, and much more about revision, judgment, experience, and troubleshooting. It’s about fixing all the ways your original design didn’t work out. AI in 2026 can help with this, but it can’t lead the effort. It can give you ideas to help troubleshoot that thorny performance issue, but it can’t do the work because that requires making experimental changes to production systems, and you didn’t give AI the keys to your production systems, right? It can build some of a C#-to-Java bridge for you, but it can’t tell you if that’s a good idea or something you will regret forever. You need experienced developers to lead the second 90 percent, drive the design, and do a lot of the work. But using AI here will help you go faster..
The third 90 percent is a similar story. AI can help you answer support tickets, but it won’t get on the phone with an angry customer and talk through the technical issues until a solution presents itself. It can fix a bug, but for now at least, it will work with a narrow focus and miss the three related fixes that should have been made at the same time. It can help you build new features, but it won’t drive the refactoring that keeps those features working as a coherent whole. You need developers and architects for the third 90 percent too.
Where AI poses a risk
Unfortunately AI doesn’t just help software products, it also brings some serious risks. With respect to the three 90 percents, two of the biggest risks are in the connections between the three steps.
Leaning too heavily on AI in the first 90 percent leaves you unprepared to lead the second and third 90 percent. If your initial release is mostly or fully vibe-coded, you won’t understand the code and will struggle to find and fix the problems that come up. You will have to rewrite whole sections of the code that worked fine in private preview but melted under load. Your customers will lose confidence in your product when you are unable to explain why the system failed. You will eventually figure things out, but your time savings from the first 90 percent will be hugely diminished, along with your confidence and reputation. Or you will limp your way through the second and third phases fully dependent on AI, until the wheels come off and it crashes.
Over-reliance on AI in the first 90 percent makes the second and third parts harder in another way as well: lower quality in the first iteration. Your senior developers have lived the second and third 90 percent for a dozen products before this, and from that they have learned how to do a better job up-front. They have gained experience and developed judgment and taste. That experience doesn’t let you skip the second or third parts, but without applying it in the first 90 percent, the later parts will be much harder. AI coding models have some of this knowledge, but far less than your human team does. Some of it is specific to your environment and the model could never know it; much of it just isn’t covered in the training data and isn’t easily guessed from first principles. Either way, if you disregard this experience now you will have a lot more work to do later. So you want human developers closely involved in the first 90 percent, even if they are substantially augmented by AI assistants.
Benefitting from AI and offsetting the risk
From the perspective of the three 90 percents, AI offers big upsides and corresponding risks. One recommendation that seems clear from all this is to keep human developers closely involved in the first 90 percent. That includes creating the initial design, helping to build the code, evaluating the quality of AI-generated tests, and ensuring that the code is readable.
One way this could look:
- Humans create the initial design, consulting with AI on specifics as needed.
- AI writes the first draft, including tests.
- Humans read and improve the code, with optional support from AI, but with real hands-on-keyboard work as well.
- Different humans and AI review the later drafts.
- Move to user testing, preview releases, and then to the second 90 percent.
Step 1 ensures that the judgment and taste of experienced developers is driving the design. Steps 3 and 4 ensure that human developers really understand the code from step 2 and are prepared to lead the work of the second and third 90 percents.
However you do it, find a way to keep your developers closely involved in the first 90 percent, if you intend to keep (and maybe sell) the thing you’re building. As noted above, they will be key to the second and third 90 percent as well, as before.
Summary
Wherever you are as a developer, team, or company, the three 90 percents almost certainly apply to some degree. Thinking about them explicitly helps you understand why work progresses the way it does, and why things take longer than you expected. AI is changing the software world at an incredible pace, but it doesn’t let you skip any of the three steps, and you over-rely on it at your own peril. If you do nothing else, be intentional about your use, and think about how it will affect your work next month and next year. And then use it thoughtfully and according to its strengths.
Acknowledgments
The concept of the three 90 percents originated with Thom Mayer and the Austin Digital business.
misterfoo.com 