My waitlist wasn't converting — so I deleted it and built the actual product
A few weeks ago I put up a waitlist for BreakWatch — a tool that watches the changelogs and docs of the third-party APIs your product depends on and warns you before a breaking change hits prod.
The waitlist barely moved. I kept blaming distribution — cold accounts, wrong channels. Some of that was real. But the honest read was simpler: devs don't sign up to wait for a tool they can't touch. They want to try it now and see if it catches something real. A waitlist asks for commitment before trust exists.
So I stopped collecting emails and built the thing instead. It's live: you paste the changelog/docs URL of an API you depend on (Stripe, OpenAI, whatever), and it checks daily, diffs it, and flags anything breaking. Free to start, no card.
No traction to report — I literally just shipped it. This is me betting that a working trial validates demand better than a waitlist ever could.
For anyone who's run a waitlist for a dev tool: did it actually convert, or did you hit the same wall? Genuinely trying to figure out if "devs won't wait, they want to try" is a real pattern or just my excuse.
breakwatch.dev
I wouldn't conclude that devs won't join waitlists from this yet.
What you've changed is more useful than that: BreakWatch can now produce evidence of its value before asking for much trust. If someone adds a dependency and later sees a change they would've missed, that's a much stronger validation event than collecting an email.
Fair, and you're right that I can't separate the two. The waitlist was up on brand-new accounts that half these communities were auto-filtering anyway, so the sample was never big enough to conclude anything about devs and waitlists in general. What I can honestly say is it wasn't working for me, and building the thing turned out to be more useful than debugging why.
Your framing is better than mine though. "Produce evidence before asking for trust" is the actual thing that changed, and it gives me a metric I didn't have: not signups, but how many people saw a change they'd have missed.
The awkward part is it's a lagging signal — there's nothing to show until a vendor actually ships something. Which is a decent argument for making the detected changes public, so the evidence exists before anyone signs up at all. I'd been sitting on that idea. You just moved it up the list.
I appreciate you sharing that. The lagging-signal problem is actually the part that caught my attention too.
I'd be interested in continuing the conversation by email if you're open to it. What's the best email to reach you on?
support@breakwatch.dev reaches me — happy to keep talking. What did you have in mind?
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.