After 10 years of flops, one exit changed my hit rate. Now on profitable SaaS #4.
For about 10 years I built apps that went nowhere. So many that I can only remember a fraction of them.
My code was mediocre. The UI was meh. I knew nothing about sales or marketing.
Then one of them worked. I sold it for millions. I did that one alone: 0 employees, $0 on ads.
After so much friction in trying to grow all my previous apps, I saw first hand what it looked like to put something into the world that was wanted. Sometimes when we try to put a product into the world it feels like a grind, an uphill battle. Other times, when the stars are aligned, it's like paddling downstream, and the world welcomes it with open arms.
After experience that, and the criteria that allow that to happen, my hit rate changed.
5 years after that exit, I'm on my fourth profitable SaaS.
The failures weren't wasted. They were me learning what to look for.
What changed:
- I stopped guessing. Before we build, we talk to a lot of people about their work and listen for the same complaint over and over.
- I build small and charge early. The SaaS I sold took 4 weeks to build, and I ran a credit card on day 1.
- I only pick problems I see myself. If I don't have the pain, or don't see it in a number of people clearly, it's not worth it.
- I know how to find more people with that same pain before writing any code.
None of that is clever. It just took 10 years of flops to learn.
What we're building now:
DemandBird It's for B2B teams and agencies who post on a lot of platforms. Write the post, adapt it per platform, get your team or client to approve it, schedule it, and see how it did.
This time I'm not doing it alone. My co-founder is Alex.
We both kept hitting the same problem from different sides. I'm not consistent at posting, which is a funny thing to admit while building this. Alex used to run an agency and know these pains inside and out. And between the two of us, we hear the same thing from agencies and teams all day, just bigger: more people, more clients, more approvals.
So we're building the thing we both keep wishing existed.
How it's going:
We now have 51 active paying customers with new signups daily.
Last week we merged 172 pull requests, and I didn't write any of the code. Agents write it, an AI reviewer flags what looks safe, and I decide what gets merged. I'm still the only technical person here, but I'm no longer a developer, I'm a systems builder.
Building used to be about picking what to build first. Now it's hard not to build everything everyone suggests, so a big part of our job is saying no.
If you've had your first win, did your hit rate go up afterward too? I want to know whether that's a real pattern or just my story.
P.S. Want to learn how to grow and exit your SaaS? https://wildfront.co/#newsletter
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?
it's having a customer problem in the first place that separates it
That’s the obvious distinction, but what are you looking for to determine whether a problem is actually strong enough to build around?
CUDI let's build this thing