NotebookBloom: A reliability lesson from building on a product with no API — make your failures loud
Quick lesson from building NotebookBloom (https://notebookbloom.com), a Chrome extension for NotebookLM.
One of my features imports a full YouTube playlist. The internal endpoint I hit is stable — but the JSON shape drifts constantly. And the scary part isn't a crash. It's the silent half-import: 200 OK, parser runs, the user gets 15 of 30 videos and never knows.
For a solo founder, silent failures are the worst kind. You don't see them in a log. You see them in a one-star review three weeks later.
So instead of trying to make the parser bulletproof, I made it loud. Narrow read, and if a field moved, the whole import stops and yells. I'd rather a user retry than quietly trust broken data.
It's a mindset thing: when you build on rented land, you don't defend against every change. You just make sure you notice the second it happens.
NotebookBloom's on the Chrome Web Store if you want a look: https://chromewebstore.google.com/detail/fmnhogknjhlaicceielblddajjabjlha
This is the exact failure mode that used to bite us at Henson Group on integrations built against undocumented endpoints, a silent partial sync is far more expensive than a hard crash because nobody notices until a client escalates weeks later. The rule we landed on was the same as yours: any schema drift halts the job and alerts, it never degrades gracefully and pretends it worked.
"degrades gracefully and pretends it worked" — that's the whole trap in six words, i'm stealing that. and the client-escalates-weeks-later part is exactly why it's so expensive: by the time anyone notices, you can't even trust which runs were clean, so you're re-verifying everything, not just the broken window. good to hear a team that had real clients on the line landed in the same place — i half wondered if i was being paranoid solo. turns out "graceful" is just a nicer word for "hides the bug."