Far more than a year ago, and the limit is no longer money or time. This article answers one question: if the build ceiling moved, what is actually stopping you now?
The Hook
Last week somebody released working reimplementations of Word, Excel and PowerPoint.
Not mockups. Programs written from scratch in Rust that read and write real DOCX, XLSX and PPTX files, built with heavy help from Claude Opus 5.5, released free and open source on October 7. The Register covered it. Thurrott covered it. Within days the Word replacement had more than 3,500 stars on GitHub.
And here is the detail I cannot stop thinking about. The person who built it published completeness percentages instead of claiming he had beaten Microsoft. His spreadsheet app covers about 89 percent of Excel's ribbon commands and roughly 93 percent of its worksheet functions. The word processor sits around 62 percent. The presentation app around 79.
Sixty-two percent. He said sixty-two percent.
That is the whole story, and almost nobody is telling it that way. The AI is not what made that project credible. The AI made it possible. What made it credible was a human being who knew exactly how incomplete his own work was and said so out loud.
I have spent a long time on the wrong side of that distinction.
Key Takeaways
- The ceiling on what one person can build collapsed this year, and the collapse is in scope rather than in judgment.
- Every impressive solo build in the last week came with a human who knew what good looked like and corrected themselves in public.
- Capacity without taste produces volume, and volume is not the same thing as a product.
- The right place to build is the narrow irritation you already understand, not the large market you have read about.
- Publishing the real number instead of the claim is now a competitive advantage, because almost nobody does it.
The Problem
I used to buy capability and call it progress.
New software, new platform, new system, new approach. I had an endless appetite for the next thing that would finally unlock the result, and I had almost no appetite for the part where I sat with one thing long enough to know whether it was any good. I built a seven-figure agency on energy and instinct and lost it, and the honest postmortem is not that the market shifted. It is that I kept adding capacity to a business whose judgment I had never developed.
Then I went to prison. Then bankruptcy. Then a long stretch of rebuilding where I did not have the money to buy my way around a problem, which turns out to be the most expensive education available and also the most effective.
So when people ask me whether AI is going to help them, my honest answer is that it depends entirely on which of those two things they are short of. If you are short of capacity, AI is a gift. If you are short of judgment, AI is an accelerant on a fire you have not noticed yet.
Here is what makes this moment genuinely strange. For most of my career the constraint was obvious and external. You could not build the thing because you could not afford a developer. You could not test the idea because testing cost money. The gatekeeper was the budget and everybody knew it.
That gate is gone. And when the external constraint disappears, what is left is the internal one, which is much harder to see and nobody sells a tool for it.
But what if the thing you have been calling a lack of resources was always a lack of clarity about what you were trying to make?
The Evidence
Look at what shipped in public over the last few days, because the pattern is consistent enough to be useful.
Somebody posted native desktop builds of StarFox, StarFox 2 and Sonic CD, produced from a one-line prompt that said, essentially, make this run on my PC, the ROM is at this path. It went to 1,300 upvotes. Then the person who built it edited his own post to say he had used the word "decompilation" too loosely, and that what he actually produced was closer to a game-specific emulator plus generated disassembly than a clean reconstruction of the original source. Engineers had pushed back in the comments and he agreed with them in writing.
Somebody else released a free Minecraft mod where you describe what you want and Claude builds it in your world through twenty in-game tools. 932 upvotes. His own description of the division of labor: he decided what to build and he tested it in the game.
And a third person released spelunkr, a round-the-clock fake cable network assembled from Internet Archive footage. 87,000 lines of code. 670 commits. 850 unit tests and 160 browser tests. Eight months of elapsed time and about thirty days of actual work.
Then this morning Superhuman AI led its edition with a startup whose entire pitch is building products that were previously unbuildable. I could not trace that company by name in open search, so treat the phrase as a newsletter headline rather than a verified claim. But the phrase is doing something interesting regardless, because it names the shift without describing it accurately. The products were not unbuildable. They were unaffordable for one person, which is different.
Now notice what every single one of those four examples has in common, and it is not the model.
A human being decided what to build. A human being knew what correct looked like. A human being counted something, tested something, or corrected themselves in public when they got it wrong. The game porter fixed his own vocabulary. The mod builder tested in the game. The spelunkr developer wrote 850 tests for a hobby project nobody was paying him for. The Office developer published 62 percent.
The scope ceiling moved. The judgment ceiling did not move an inch.
What This Changed For Me
I will tell you where this landed for me personally, because it changed what I build and what I refuse to build.
I used to pick projects by opportunity. What is the market, how big is it, where is attention going. That is how you pick when capacity is your constraint, because capacity is expensive and you want to point it at the largest possible return.
Now I pick by irritation. Specifically, by the irritations where I can look at version one and know in about four seconds that it is wrong.
That sounds smaller and it is actually the opposite. If I can spot a bad output instantly, I can iterate at the speed of generation, which is extremely fast. If I cannot, I am just producing volume and hoping, and I have done enough hoping to know how that ends.
This is also why I keep saying out loud that I sell AI education and that I am therefore inside the category selling to people who are afraid of being left behind. Somebody on Reddit put that uncomfortably well a couple of days ago and he was right. The honest version of being in that category is to report the denominator. To say 62 percent. To publish the thing that did not work alongside the thing that did.
Because here is what I believe, and I will state it plainly. AI amplifies skill and experience. It does not substitute for them. For somebody who has spent fifteen years learning what good looks like in their field, this is the most leveraged moment of their working life. For somebody who has not, it is a very fast way to produce a lot of confident nonsense.
You are probably in the first group and do not know it. The thing you take for granted, the thing you cannot believe other people get wrong, the mistake you spot in a document in four seconds, that is not common knowledge. That is fifteen years of pattern recognition that now has a build budget attached to it.
Practical Steps
1. Write down the three things you can judge instantly that other people cannot. Not your skills. Your instant verdicts. The mistake you catch in a proposal, the number that is always wrong in your industry's spreadsheets, the thing clients always misunderstand. That list is your actual advantage and it is probably shorter and more specific than you expect.
2. Pick from irritation rather than opportunity. Find the document, spreadsheet or process that you or everyone in your industry rebuilds from scratch every month. A thing everybody redoes by hand is a product nobody has shipped. You already know the inputs and you already know what wrong looks like.
3. Define done before you start building. No more than seven yes-or-no criteria, including one thing version one is explicitly allowed to fail at. I am not being tidy here. Without this you will keep adding, and a project with no definition of done becomes a hobby and then a regret.
4. Scope version one to one week, then cut it again. Every project I have ever scoped to a quarter died at week three. Write the full list of features, then cross out everything that is not the single job it must do, then start on what is left.
5. Talk to five people before you build anything. Five questions, none of which describe your solution, and decide in advance which answer tells you to stop. You are trying to find out if anyone else has this irritation or if you are building for an audience of one.
6. Publish the number, not the claim. When you ship, say what it does not do, in the first half, in plain language. Say 62 percent. People will trust the project and they will trust you, and both of those compound in ways that a good launch headline does not.
7. Keep a two-minute log every session. What you tried, what worked, what did not. By month five you will not remember why you made the decision you are about to reverse. The spelunkr pattern of thirty working days spread across eight months only works if returning to the project is cheap, and a log is what makes it cheap.
Frequently Asked Questions
Can a non-technical person really build a working product with AI now?
Yes, within limits that are mostly about scope rather than ability. Single-purpose tools, calculators, document generators and internal workflows are well within reach. The thing that decides whether it is any good is whether you can recognize a wrong output, which has nothing to do with coding.
What should I build first with AI if I run a business?
The task you personally redo every month and already know how to judge. Pick where the cost of being wrong is a redo rather than a customer problem, so that you can iterate freely without putting trust at risk while you learn.
Is AI replacing developers and designers?
It is replacing the budget barrier, not the judgment. The solo builds making news all came from people with real domain knowledge who knew what correct looked like and kept going for months. Experienced builders got faster, and inexperienced ones got louder.
How do I avoid overclaiming when I launch something AI helped me build?
Put the limitation in the first half of your announcement and use a real number for completeness. Say what it cannot do and who it is not for, before anybody has to discover it themselves, because expectations set in the headline are the ones you get judged against.
How long does a realistic solo AI build take?
Count in working days rather than calendar weeks, because almost nobody works on these continuously. One of the more impressive projects shipped recently took about thirty days of real work spread across eight months, which is a pattern worth planning for rather than fighting.
The Close
Sixty-two percent.
That is the number a person put on his own work while the internet was calling him a genius, and it is the most valuable thing anybody published last week.
I spent years believing the gate was money. Then I had no money and discovered the gate had always been something else. I could not tell good work from busy work, and no amount of capacity was ever going to fix that, because capacity is not a judgment-delivery mechanism.
The gate is open now. For you, specifically, with whatever fifteen years of knowing-what-wrong-looks-like you are sitting on and discounting because it feels obvious to you.
So go build the narrow irritating thing you understand better than almost anyone. Scope it to a week. Show it to five people. Then tell them exactly what it cannot do yet.
The AI will handle the capacity. The only part that was ever really yours is the part where you look at it and know.
About the author. Jonathan Mast is the founder of White Beard Strategies and the host of a 500,000-member entrepreneur community. He built a seven-figure agency, lost it, served time in prison, went through bankruptcy, and rebuilt from nothing, which is most of the reason he writes about judgment rather than tools. He teaches non-technical business owners to use AI to amplify the skill they already have, and he still keeps a log of every project that did not work.