Karlo Perčinić

I build products solo. Every single one of them sits on top of somebody else's API — Stripe for payments, OpenAI and Anthropic for AI features, Meta for ads, print-on-demand APIs, map APIs. My code is maybe half of what actually runs in production. The other half belongs to vendors, and it changes whenever they decide it changes.

Twice this year the first notice I got about a breaking change was a production error. Not an email, not a warning. An error, and then me digging through the vendor's changelog trying to figure out what they changed and when. The information was public the whole time. It was sitting in a changelog page I never visit, because nobody visits changelog pages until something is on fire.

So I'm building the thing I wanted to exist

BreakWatch is simple: you tell it which APIs your product depends on, and it reads their public changelogs for you.

  • It fetches each changelog page once a day
  • Diffs it against yesterday's snapshot
  • Classifies the real changes: breaking (endpoint removed, field deprecated, "migrate by September") vs. informational (new feature, docs clarification — stuff you can ignore)
  • Alerts you only when something looks like it will break an existing integration
  • Keeps everything in a searchable timeline, so six months later "what changed on their side right before this broke" takes ten seconds instead of an afternoon

No SDK, no credentials, nothing installed in your codebase. It only reads public pages.

What I tested this week

I ran it against the real changelogs of the ten APIs I'm watching first: Stripe, Twilio, OpenAI, Anthropic, Shopify, GitHub, Slack, Cloudflare, Google Maps and Plaid.

Some honest findings:

  • 10/10 scrape cleanly now, but it took fixes. Stripe's changelog page alone is 3.3 MB. SendGrid's standalone changelog doesn't exist anymore (it merged into Twilio's). PayPal's developer site serves a JavaScript shell with an HTTP 404 to anything that isn't a full browser, so it's out until I add rendering.
  • The thing I was most afraid of didn't happen: re-fetching the same pages later produced zero false diffs. The pages are stable enough to diff. If they weren't, this whole idea would be dead.
  • The classifier is a keyword heuristic first (deprecated, removed, sunset, end of life...), with an optional LLM pass for ambiguous wording. The heuristic alone correctly separated real breaking changes from additive noise in my tests.

Where it's at, honestly

It's not open for signups yet. There's a waitlist at breakwatch.dev, a live demo timeline, and a working pipeline — but no accounts and no billing, on purpose.

I'm at the validation stage and I've set myself a kill condition: if the people who see this mostly say "I just subscribe to the vendor's changelog emails and that's enough," I stop building. That answer, said enough times, kills the product — and I'd rather hear it now than after building auth and billing.

So I'll ask directly:

  1. Which API has burned you the worst with a breaking change you didn't see coming?
  2. Do vendor changelog emails actually cover you, or do things still slip through?
  3. Would a daily diff of the changelogs you depend on be worth $29/month to your team?

Brutal honesty is the most useful thing you can leave in the comments.