10 Out of 10 Execution on a 2 Out of 10 Opportunity: Three Founder Post-Mortems

A technically sound app built over six months of 70-hour weeks produced no meaningful revenue, because the problem it solved was never painful enough for people to seek out a new tool. Buildable does not mean worth building. One indie builder set out to solve a problem he had personally experienced, wrote code most nights and weekends for half a year, and eventually had a fully functioning product. He then did what most first-time founders do when they need feedback: he sent it to friends. The friends, being friends, were generous. "Oh, if it just had this one thing then I would definitely use it," they told him. So he built that thing. Then another. The feature list grew, built entirely from polite feedback rather than paying demand. The app never found traction. Looking back, the founder's own diagnosis was blunt: the underlying problem was not painful enough. It was not a problem people would go out of their way to seek out and learn a new tool to solve. People will tolerate a mild inconvenience indefinitely rather than change their habits for a stranger's app, no matter how well that app is built. The deeper lesson sits in how the feedback was gathered, not just what it said. Friends will almost never tell a founder that an idea is bad, because saying so risks the friendship. Feature requests that come from people who feel socially obligated to be encouraging are not signal. They are noise dressed up as signal, and they are worse than no feedback at all because they create the illusion of validation while a founder burns another six months chasing it.

One founder spent roughly 300 days building four separate small products and generated only a trivial amount of lifetime revenue across all of them combined. Shipping quickly four times over does not fix a validation problem that was never solved once. This founder took the opposite approach to the first: rather than spending six months perfecting one idea, he moved fast and built several. Four distinct products across roughly ten months, each one shipped, each one put in front of the world. None of them found a real audience. Combined lifetime revenue across all four landed in the single digits to low double digits of dollars, a rounding error against the time invested. His own retrospective pointed to two separate gaps. The first was practical: his front-end skills were still basic, so each build took longer than it should have and left less runway to test demand once something existed. The second was the one that actually mattered. He admitted he did not really know anyone who would want to use the products he was building, and on reflection he realised he did not particularly want to use them himself. This is the more instructive failure of the two, because it proves speed alone is not the fix for weak validation. A founder can iterate through four ideas in the time it takes another founder to finish one, and still land nowhere, if the same untested assumption about demand gets carried into every new build. Moving fast only compounds a good validation process. Carried without one, it just means failing four times instead of once, on the same schedule.

A well-known business commentator has described a case of a founder investing well over a million dollars building software that ultimately failed commercially, undone in part by an ownership and documentation flaw that had nothing to do with the underlying product idea. The scale here is different from the first two stories. This was not a nights-and-weekends solo build, it was a properly funded venture with real engineering behind it. The software got built. The company still failed, and the retelling points to a specific, avoidable cause layered on top of a weak opportunity: the developer relationship never produced a documented, transferable codebase. When that relationship broke down, there was no road map for anyone else to pick up the work. The business could not simply hire a replacement team and continue. It effectively had to start over. This is the story that gives the whole pattern its name: "10 out of 10 execution on a 2 out of 10 opportunity." Even with real capital and a working product, the venture failed. The lesson is not that execution does not matter at all, undocumented code and lost ownership are genuine, fixable problems worth solving on their own terms. The lesson is that execution flaws and opportunity flaws compound each other, and neither one is forgiving of the other. A great team building on a weak opportunity still fails. A weak team building on a strong opportunity often survives anyway, patched together until someone competent takes over. The opportunity is the variable doing most of the work, in both directions.

None of these three failures were caused by bad code, slow shipping, or a lack of technical skill. Every one of them traces back to a problem that was never confirmed to be painful enough, or valuable enough, before serious time and money went into building the solution. Line the three up and the pattern is obvious in hindsight and invisible in the moment, which is exactly why it keeps happening. The six-month builder had working software and glowing informal feedback. The 300-day builder had four shipped products and the discipline to keep moving. The million-dollar venture had capital, a team and a finished product. All three had something to show. None of them had a market that had proven, with its own money and its own time, that it wanted what got built. This is the trap in "people don't really even know what they want." It is genuinely the entrepreneur's job to work out what the core problem actually is and build the simplest possible thing that solves only that problem, rather than accumulating a feature list built from polite encouragement or personal hunches. Technical execution quality is not the variable that predicts whether a product succeeds. Whether the underlying problem was painful and validated before building began is the variable that predicts it, by a wide margin, across all three stories. That is a genuinely uncomfortable conclusion for anyone who takes pride in craft. Being a skilled builder feels like it should count for more than it does. In practice it only counts once the opportunity itself has already been established as real.

Testing willingness to pay before writing any code is one of the cheapest ways to find out whether an idea is worth building at all. A landing page describing the product and a small deposit from real prospective customers replaces months of guessing with a few days of evidence. The instruction, arrived at independently by more than one experienced founder, is straightforward: put together a homepage with a demo or a clear description of what the product will do, then ask people directly, "would you sign up for some small amount of money, a deposit today?" If a reasonable number of real prospects say yes and actually hand over money at a workable scale, that is a genuine signal a business exists underneath the idea. Go build the technology. If almost nobody will commit even a small deposit, that is the answer too, and it is a far cheaper answer than the one the three post-mortems above eventually received. A landing page and an honest ask cost days and a small amount of money. A full build, as all three stories show, can cost months of a person's life or well over a million dollars, and the market delivers the same verdict either way, just later and at a far higher price. The test does not have to be elaborate. It needs three things: a specific description of what the product does and who it is for, a real price attached to it, and a genuine ask for commitment rather than a vague survey question about interest. "Would you use this?" gets a polite yes from almost anyone. "Would you pay $100 today?" gets an honest answer.

Paid discovery exists to run the sell-before-you-build test properly, with a structured process, before a founder commits to months of engineering time on an unvalidated idea. It is the difference between finding out an idea is weak in week two versus month six. A discovery phase forces the questions that polite friends and internal enthusiasm both tend to skip: who exactly has this problem, how painful is it for them right now, what are they currently doing instead of a proper solution, and would they actually pay for the thing being proposed. Those questions get worked through and, where possible, tested against real prospective users, before scope gets fixed and before a build begins. The output is a validated, scoped plan rather than a hunch with a Figma file attached. This matters because none of the three founders above lacked the ability to build. They lacked a structured, disinterested process for stress-testing the opportunity before they committed months or, in the third case, a fortune to it. A friend saying "that would be nice" is not that process. A founder's own optimism about their idea is not that process either. A deliberate discovery phase, run by someone with no stake in telling a founder what they want to hear, is built specifically to be that process. At 13Labs, buildAgency starts every engagement with exactly this kind of paid discovery. Before any code gets written, the work is to pressure-test the problem, confirm there is a real audience willing to pay, and turn the result into a scoped, fixed-price plan. It costs a fraction of a full build and it exists for precisely the reason these three post-mortems illustrate: it is far cheaper to find out an opportunity is weak during discovery than to find out during month six, or after a million dollars is gone. If you have an idea and want to know whether it is worth building before you commit real time or money to it, buildAgency's paid discovery turns your idea into a scoped, validated plan before any code is written. See what that looks like at 13labs.au/buildAgency.

Does good execution ever matter if the opportunity is weak? It matters less than most founders assume. All three post-mortems here show technically capable people producing working software that still failed commercially, because the underlying problem was never painful or valuable enough to sustain a business, regardless of build quality. How do I know if my problem is painful enough to build for? Ask whether people are already spending money, time, or serious effort trying to solve it badly with what exists today. A problem people casually mention but tolerate indefinitely is rarely painful enough to justify a new tool, no matter how well that tool is built. Why is feedback from friends unreliable? Friends have a social incentive to be encouraging rather than honest, so their feedback tends to describe what would make them feel supportive rather than what would make them pay. Feedback from people with money on the table is far more reliable than feedback from people who like you. What does a sell-before-you-build test actually look like in practice? A simple page describing the product with a real price attached, and a direct ask for a small deposit from genuine prospective customers. If people will not commit even a modest amount of money today, that is a strong signal the opportunity needs more validation before a build starts. How is paid discovery different from just building an MVP and seeing what happens? An MVP still costs weeks or months of engineering time before you learn anything. Paid discovery is a shorter, cheaper, structured process specifically designed to test the opportunity itself, the audience, the willingness to pay, and the scope, before that engineering time gets committed at all.