2
1 Comment

PainMap is Live. Here's What the First Week Actually Looked Like.

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:

  • Saved searches were rerunning the research instead of loading the cached results. That meant a user clicking on a previous run was burning one of their monthly credits. Not acceptable.
  • The Generate MVP Brief button was silently failing for some paid users. Null check issue and a field name mismatch. The button was there. The click was there. Nothing happened.
  • On Chrome on Windows 11, pain point cards were going blank while scrolling. GPU compositing issue. Intermittent. Horrible to reproduce.
  • The research engine was throwing 401 and 502 errors at points. Redeployed twice that day, v26 then v27, before the route was stable.
    T- he plan display was showing "2 runs free" to every user regardless of what plan they were actually on.

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:

  • Stripe checkout is fully live. Built the create-checkout-session edge function, sorted JWT and environment variable issues, deployed it. Upgrades now work cleanly end to end.
  • Account dropdown shows your current plan and an upgrade link. Before that, you had to hunt to find out what tier you were on. Now it's right there.
    Search page has an upgrade CTA for non-Studio users. If you're hitting the limits of your plan, it tells you what's next instead of leaving you to work it out.
  • Support button is in. Because users asked for one, and they were right to.
  • MVP brief one-liners now describe the product, not the pain point. Small wording change. Big difference in how the output actually reads.
  • Source badges cleaned up. Community sources in one place. Competitor tools in another. No more Reddit and Capterra sitting next to random product URLs like they're the same thing.

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.

on April 21, 2026
  1. 1

    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.

Trending on Indie Hackers
The most underrated distribution channel in SaaS is hiding in your browser toolbar User Avatar 185 comments I launched on Product Hunt today with 0 followers, 0 network, and 0 users. Here's what I learned in 12 hours. User Avatar 156 comments I gave 7 AI agents $100 each to build a startup. Here's what happened on Day 1. User Avatar 98 comments How are you handling memory and context across AI tools? User Avatar 56 comments Do you actually own what you build? User Avatar 42 comments Show IH: RetryFix - Automatically recover failed Stripe payments and earn 10% on everything we win back User Avatar 34 comments