24 new users. 108 people still on the waitlist. 11 bugs fixed on launch day. And still zero pounds spent on ads.
A couple of months ago I wrote about why I was building PainMap and why I'd decided to do it in public. The waitlist was growing. The product wasn't live yet. There was still a real chance none of it was going to work.
It's live now. And a few things have happened that I think are worth writing down honestly, because the launch-day version of events isn't always the version that actually matches what happened.
The waitlist paid off
Before launch I gave beta access to 10 people from the waitlist. That decision shaped everything that happened next.
Those 10 people found more problems in one day than I'd found in weeks of testing the product myself. Not because I hadn't tested it. Because I was testing it like someone who built it. They were testing it like someone trying to use it for the first time to solve a real problem.
That's the part you can't fake. You can QA your own product for a month and still miss the thing that breaks the moment a real user touches it.
Building the waitlist in public wasn't just a growth play. It turned out to be the single best decision I made on this entire project. The people who signed up early actually cared. They wanted the product to work. So when it didn't, they told me exactly what broke, where, and what they were trying to do when it happened. That's worth more than any analytics dashboard. The bugs we didn't see coming
Launch day turned up 11 bugs. Some small. Some not.
The worst ones:
None of this is fun to write about. But pretending launch day went smoothly when it didn't is exactly the kind of marketing gloss I wanted to avoid when I started building this in public.
The useful bit: everything on that list is fixed. Most were fixed the same day they were reported. The rest within 24 hours.
What got better because of the feedback
Beta testers didn't just find bugs. They told me where the product was confusing, where it wasn't obvious what to click, and where the output wasn't pulling its weight.
A few of the changes that came out of that:
These sound like small things on their own. Together they're the difference between a product that works and a product that feels like it works.
Why I'm being this specific about all this
Because this is the bit most founders skip when they talk about launch.
You usually see the celebration post. "We launched. It went great. Thanks for the support." You don't see the bug list. You don't see the 2am redeploy. You don't see the honest conversation with a beta tester who tells you the thing you were most proud of doesn't work the way you think it does.
I'd rather show the real version. Partly because I think it's more useful to other builders. Partly because PainMap is built for founders who are already tired of being sold to, and the last thing they need is another launch post that treats them like they've never seen software break before.
Why this matters to the people using it
PainMap is built for indie hackers, founders, and developers who want to build something people will pay for. That's it. That's the whole user base.
Those people don't have venture money. They don't have research teams. They've got evenings and weekends and a day job or three other projects running in parallel. The cost of building the wrong thing for that person isn't just wasted time. It's confidence, money, and the willingness to try again.
The job of PainMap is to compress weeks of manual research into something you can actually make a decision from. You type in a niche. In under two minutes you walk away with validated pain points, real willingness-to-pay signals from actual users, the specific reasons existing tools are failing, and a brief you can start building from.
Not a list of Reddit threads. Not a summary of summaries. Real evidence.
Every founder I know who's launched something that didn't land will tell you the same thing. They knew, somewhere in the research stage, that the signals weren't strong enough. They just didn't have a way to prove it to themselves before writing the code. This is that proof.
The pricing (because I know people will ask)
The free plan is actually free. Two research runs a month. Three pain point cards per run with real evidence and willingness-to-pay signals. Competitor complaints included. No card required. It stays free.
The Founder plan is $49 a month. 20 runs. Full output. Full MVP briefs. Landing page copy. If you're actively trying to find a product to build, you'll know by the end of your first paid run whether that's worth it.
The Studio plan is $99 a month for teams and agencies running research across multiple clients.
And for the first 200 waitlist signups: $29 a month, locked for life. That was the promise when people signed up and I'm keeping it. Those slots are filling.
I want to be clear about the pricing because I know the pattern. Indie SaaS launches, starts cheap, hits a few hundred users, then quietly ratchets the price up and grandfathers the early adopters onto a plan that gets phased out six months later. That's not what this is.
$29 for the first 200 is the thank-you for backing the product before it existed. $49 is the public price. It's priced that way because it needs to pay for the infrastructure and my time, not because I'm trying to hit some revenue multiple before a Series A. PainMap doesn't work if it's priced out of reach of the people it was built for.
If a founder pays $49 once and it stops them from spending three months building the wrong thing, the product paid for itself ten times over before the end of week one. That's the bar. Anything else would be a cash grab and there's already enough of those.
Where we are now
24 active users since (4 days at point of writing). 108 people still on the waitlist who haven't converted yet. Mailchimp sequences are running to move waitlisters onto free accounts and free users onto paid.
Still zero pounds spent on advertising. All growth is still organic from Reddit, Indie Hackers, and people hearing about it from someone else.
If you're on the waitlist and haven't checked it out yet, the free plan is waiting for you. Two runs a month, real output, no card. If you want to lock in the $29 price before the slots run out, now's the window.
https://painmap.io
I'll keep writing these honestly as we go.
Good build — but this is exactly the stage where the name quietly becomes a ceiling.
“PainMap” explains the feature, not the company. It’s hard to build long-term brand equity or trust on something that sounds like a tool vs a product.
Early users tolerate it. Later users judge it.
If you’re serious about scaling this beyond early adopters, the naming layer will matter more than most of what you’re fixing right now.
I work with short, brandable .coms built for products like this — can share a couple if you're open.