When you launch a product, you assume you know what users want. My assumption was that creators wanted faster analysis. I was wrong. They wanted certainty. After a post about my project blew up on Ind
Markdown supported · ⌘↵ to post
The PENDING + /status polling switch is the right call. I hit the same wall with long AI jobs on serverless and ended up with the same shape.
On the SEO side, one thing I'd add to the DR signal: when I research what to build next, the strongest evidence isn't a weak SERP, it's a small site that's already getting real clicks for the query (I use roughly 100+ clicks and 10%+ of the traffic as my bar). "High-DA thin content" says there's a gap; a small site winning clicks proves the gap can actually be won. Also watch out for keyword difficulty numbers in third-party tools. I've found them stale often enough that I stopped trusting them on their own.
Are you pulling actual traffic per ranking page, or only DR + SERP content?
The "confident wrongness" framing is the real lesson here — most rewrites aren't caused by bad architecture, they're caused by architecture optimized for an assumption nobody validated. I went through a similar cycle: built the polished version first, then learned from real users that the boring infrastructure (status polling, honest error states) mattered more than the features. Keeping a tight feedback loop with a community like Indie Hackers is the cheapest form of validation — I also keep a running directory of the free tools that survive my own cuts at mytoolster.com, because the fastest way to kill a side project is a tool bill that arrives before revenue does.
Ahmet Özel
AI Engineer. Computer Vision, RAG and LLM agents.
The PENDING response solves the connection timeout, but it creates a second contract: how does a client distinguish work that is still running from work that was abandoned? A status row that remains pending indefinitely can be more confusing than the original failed request.
I would expose separate queued, running, completed, and failed states, with a last-progress timestamp and a documented expiry outcome. Test by stopping the worker after the initial response and again just before result publication. The poller should reach an honest terminal state in both cases, rather than depending on the browser staying open or treating elapsed time as evidence that the analysis succeeded.