My new product has a public kill condition: 20 leads or it dies
Last week I built BreakWatch — it watches the changelogs of the APIs your product depends on (Stripe, OpenAI, Twilio…) and alerts you before a breaking change ships.
Before building the "real" SaaS version (auth, billing, multi-tenant), I gave it a kill condition and made it public: 20 inbound leads, with at least 5% starting a trial — or it dies. Replies like "I just read the vendor's changelog emails" count toward the kill column.
Why so brutal: the MVP was cheap — a scraper, a differ, a classifier, ~500 lines. The next stage isn't. I'd rather bury it in week two than discover in month six that nobody pays.
Things I learned testing the scraper against 10 real changelogs:
- Stripe's changelog page is 3.3 MB
- SendGrid's changelog quietly merged into Twilio's
- PayPal's developer site serves fake 404s to anything that isn't a full browser
Which is accidentally the pitch: if changelogs are this hostile to a scraper, no human is checking them reliably either.
Question for anyone shipping on top of third-party APIs: when a provider deprecates something, how do you actually find out today — vendor email, Twitter, or when production breaks? The answers genuinely decide whether this survives.
The honest answer is vendor email, then production breaking. The gap you are pointing at is real: deprecation notices get announced months ahead, but nobody maps them to the specific endpoints a given product actually calls, so the signal arrives as a 500 instead of a changelog entry. That mapping step is where the value is. How do you plan to keep the classifier current when changelog formats shift? Stripe and Twilio already structure theirs differently, and PayPal is hostile to scrapers entirely.