After 10 years of flops, one exit changed my hit rate. Now on profitable SaaS #4.

Really valuable insights, especially the importance of validating a repeated problem before building. I’m working in AI engineering and exploring practical ways to solve real business problems with AI. Your point about building small and charging early is particularly useful.

10 years is the number that doesn't show up in the headline but does all the real work.

Most success stories compress the timeline. The exit itself changes things, but not for the reason people usually say. It's not the capital or the credibility. It's that you finally have a complete data set on what "finished" looks like — what it took, where the real leverage was, what would've killed it if you'd done it differently.

The pattern recognition that builds post-exit is different from anything you can read about. You've closed the loop once. That changes how you approach the next thing at a level below conscious strategy.

SaaS #4 being profitable is a result of everything that broke in #1, #2 and #3. The flops aren't a cost, they're the curriculum.

What was the biggest behaviour shift you noticed in yourself between the exit and starting the next one?

I have backed 50+ companies and the pattern holds, but not for the reason most second-time founders think. Your hit rate did not go up because you got better at picking winners, it went up because you got faster at killing losers, and you now have a reference point for what real pull feels like so you stop calling a flat week a marketing problem. The thing I would watch is that an exit also hands you money and warm intros, which quietly removes the constraint that made you run a credit card on day one, and that constraint is what produced the win.

To answer your question: yes, the pattern is real. Once you know what 'paddling downstream' actually feels like, your brain stops trying to force the upstream battles. It completely changes how you evaluate ideas.

The most fascinating part of your post is merging 172 PRs where agents write the code and an AI reviews it. That is a massive shift from being a solo dev to a system builder.

Out of curiosity, how much time are you actually spending reviewing those AI PRs compared to just writing the core logic yourself? Does the AI reviewer reliably catch edge cases, or do you still have to dig deep into the code before hitting merge?

The first win probably improves judgment, but I suspect charging early is the more transferable skill. Complaints and compliments can be polite; payment exposes urgency. For DemandBird, what user behavior makes you say yes to a feature request—frequency across accounts, retention risk, or willingness to pay?

On your closing question — I'd say yes, it's a real pattern, but the win itself isn't what changes the hit rate. The win forces you to learn the difference between pull and push, and you can't unlearn it.

Before a real win, every idea feels plausible because you're evaluating on imagination: could someone want this? Afterward, you evaluate on evidence: is anyone already pulling this out of me — asking when they can pay, complaining about their workaround, trying to bend the landing page into doing the thing. Pull has a texture that's hard to describe and impossible to miss once you've felt it.

Your bullet about knowing how to find more people with the same pain before writing any code is the operational version of the same thing. The flops weren't 10 years of learning to build; they were 10 years of learning to recognize pull.

The part I'd watch, though: pattern recognition can also become a filter that's too narrow. The win teaches you what pull looks like in one domain, and there's a risk of only recognizing pulls that resemble the last one. Congrats on #4 — the fact that this one pulled from a different side (you and your co-founder hitting the same problem independently) suggests you're avoiding that trap.

I can offer the inverse of your pattern, from fundraising rather than product. We took 40 first meetings with U.S. VCs as a non-U.S. deep-tech company and got 0 term sheets. For a long time I logged each one as a different failure: weak deck, no U.S. entity, valuation gap, and so on. The turning point was noticing that 37 of the 40 ended at the same question (how does the investor's money actually come back), and only the 3 that got past it ever surfaced the next problem. So my guess is a first win changes the hit rate because it hands you the order in which problems appear, and that order is invisible until you've been through it once. Your list (stop guessing, only pick pain you see yourself, charge on day 1) reads like exactly that: a sequence, not a checklist.

I reckon the win probably changes the hit rate because it changes what you trust.

Before a real success, it is easy to treat every idea with equal seriousness if you can imagine the product clearly enough. After one works, you have a body-feel for the difference between “people are being polite” and “people are already trying to solve this without you.”

The line about it being hard not to build everything everyone suggests is interesting too. That feels like the next version of the problem: once demand is real, restraint becomes the skill. How are you deciding which customer requests deserve to become product direction, and which ones stay as noise?

51 paying customers makes the new hit rate more than a theory. What customer/problem pattern now separates the SaaS ideas that work from the ones that still fail?

CUDI let's build this thing