Web scraping as a service is back, and still controversial
Context.dev launched as a YC S26 company offering an API to get structured data from any website. The HN reception is sharp: 'So basically web scraping as a service with an API on top?' One commenter calls it 'wildly expensive' and notes there's no mention of IP rotation or residential proxies on the homepage, making it 'unusable for high value data.' Another says they'll have to block it server-side, comparing it to the old image leech problem when bandwidth was expensive.
This is a recurring launch pattern on HN. Web scraping products get built, get called out for the same set of fundamental problems (blocking, legal exposure, cost at scale, IP infrastructure), and the founders usually have to respond with more specifics than the landing page shows. The criticism here is pointed because the problems are known and the homepage doesn't address them.
The 'history doesn't repeat but rhymes' comment is the most useful framing. Every generation of scraping tools rediscovers the same adversarial dynamic with website operators.
So what?
If you're building a data acquisition product, the technical capability to scrape is table stakes. What customers actually need is reliability against blocking, legal clarity, and pricing that makes sense at volume. Launching without addressing those three things on your homepage tells sophisticated buyers you haven't thought it through. Address the hard parts first.