I couldn't afford SerpApi ($10/1k) for my side project, so I built a $0.56 alternative.

100% agree. Not to drift too much from the subject of the post, but I think this detail (as many other details that are not core to any one app) matters. Call it trust building, call it one more way to get the prospect closer to pulling the trigger, whatever the case I feel there are so many patterns we repeat blindly on the side of our products without realizing the world has changed and maybe one should explore innovation. This is especially true with subscription fatigue, IMO

Exactly! To be honest, I haven't treated SearchCans as a profit-driven business so far. Maybe someday in the future things might change—as I’m considering hiring staff to help manage the SaaS, which will bring extra costs. But for now, my priority is to stay true to my original vision: keeping it the most cost-effective and reliable tool for the developer community.

Thanks for the support! You hit the nail on the head—context tokens are where the real costs hide, and that’s exactly why I focused on the Markdown output.

To answer your questions:

1. JS Rendering & Latency: You're right. For heavy SPAs, some pages can take 10+ seconds to fully hydrate. In my view, reliability is far more important than raw speed in these cases. I’d rather wait a few extra seconds for a successful, clean render than get a fast "403" or a blank page. We use optimized Puppeteer clusters to handle this, though the target site's complexity is the main variable.

2. Rate Limiting: Currently, I don't have strict rate limits—it's purely usage-based. My current client base consists of 3 large companies, some RAG developers, and SEOers, so we manage the load fine. While I don't have the massive server farms of giants like SerpApi or BrightData yet, I’ve built the infra to be highly scalable. I'm adding new nodes as the user base grows to stay ahead of demand.

The $0.56 pricing is my way of making this sustainable for fellow indie devs. Would love to hear your feedback once you've put it through its paces!

Thanks—honestly, that "itch" was getting way too expensive to scratch with the existing tools! 😅

Thank you for the encouragement! You're 100% right—iterating based on real-world use cases is my top priority.

The idea for SearchCans actually came from my own struggles as an engineer back in 2025, and seeing others find value in it now is incredibly motivating. I’m already taking notes from the feedback in this thread (especially regarding infrastructure scaling and JS rendering) to make the tool even more robust.

More refinements are coming soon. Thanks for having my back!

That’s a great question. For me, it was actually a mix of both, but mostly about "sustainable experimentation."

While I was testing demand in early 2025, the $0.01/request cost made every bug and every failed agent loop feel like a personal financial loss. It creates a "fear of failure" that actually slows down the development and discovery process. You stop experimenting because you're constantly watching the meter run.

By building SearchCans and bringing the cost down by 90%+, I removed that mental barrier. Now I (and other devs) can run thousands of tests to truly refine the product without worrying about a massive bill at the end of the month. It's about giving indie hackers the freedom to fail fast and iterate until they find that "aha!" moment.

That’s a very practical question! To be completely transparent: currently, I don’t impose a hard per-account QPS limit, but the system architecture incorporates circuit breakers and queuing mechanisms based on the available worker clusters.

Right now, since I'm a solo founder, the physical cluster size is relatively small (typically supporting around 3-8 concurrent requests smoothly). However, the entire backend is built for infinite horizontal scaling. I can spin up additional clusters almost instantly as user demand grows. 

My philosophy is to provide a rock-solid, reliable connection rather than over-promising on throughput I can't guarantee yet. If your specific workflow requires higher concurrency, just let me know—I can easily scale up the infrastructure to accommodate your needs!

I totally get why it looks cheaper at first glance—I used to think the same way until I looked at the actual "cost per action" for my specific use cases.

Let's do the actual math for an AI Agent workflow:

1. The "Hidden" Multiplier:

* Google SERP: They charge 20 credits per request.

* JS Rendering: They charge 5 credits per request. (And let's be honest, in 2026, pure HTML pages are rare. Almost everything needs JS).

2. The Real Cost (assuming their $49/100k credits plan):

* SERP: 100k credits / 20 = 5,000 requests. Cost = ~$9.80 / 1k requests.

* JS/Reader: 100k credits / 5 = 20,000 requests. Cost = ~$2.45 / 1k requests.

* SearchCans: Flat rate of ~$0.56 / 1k requests for both.

3. The "Use it or Lose it" Trap:

* Their credits expire at the end of the month. If you don't use them, you lose money.

SearchCans credits valid for *6 months**.

So, if you are just scraping static Wikipedia pages, they are great. But for SERP and modern JS-heavy sites, SearchCans is mathematically ~4x to 15x cheaper.

...Actually, now that I write this math out loud, I realize I might have priced it TOO low. 😅 I might need to raise the prices sooner than I planned. Better grab the credits while they last!

I have conducted a comprehensive analysis of the two platforms, and in fact, their pricing calculation models differ significantly. ScrapingBee has a starting price of $49 per month – this fee is mandatory even if you only use the platform a few times in a given month. In contrast, Searchcans features a 6-month validity period for its credits. Given that many AI developers are individual users, this point-based model is far more user-friendly for this group; furthermore, this model is also gradually replacing the traditional subscription model.

To be honest, comparing a solo-developer project to a giant like SerpApi on day one is tough! 

Full transparency: We had a massive traffic spike last night that actually tested our limits and caused some availability issues. It was a wake-up call. 

The main difference right now is that SerpApi has years of infrastructure behind them, while SearchCans is currently in its "rapid scaling" phase. I’m currently adding more nodes and optimizing our Puppeteer clusters to ensure we can handle this new level of demand. 

Our goal isn't to be a "SerpApi clone," but to be the most reliable, RAG-optimized alternative at 1/20th of the cost. If you can tolerate the occasional "growing pains" of a new tool, the cost savings and clean Markdown output are where we really shine.

Thank you, Sonu! Coming from a positioning expert, that means a lot. 

You’re absolutely right—as a developer, I realized that "feature volume" doesn't matter if the core data is too expensive or too messy to use. My goal with SearchCans was to strip away the noise and provide the "buyer clarity" I wished I had: a predictable cost and a format (Markdown) that LLMs actually understand without extra processing. 

I’m still navigating the "growing pains" of scaling (had a wild traffic spike last day!), but hearing that the positioning resonates with a pro like you gives me a lot of confidence. Thanks for the encouragement!

Man, tell me about it. Being able to diff the raw HTML vs the Markdown saved my sanity so many times while debugging.

On the technical bits:

For CSR, honestly, the standard Puppeteer networkidle is a lie. I stopped trusting it months ago. I had to build custom listeners for DOM mutations to actually catch when the content drops, which solves most of those "infinite loading" issues.

For Paywalls, I don't touch server-side blocks (not worth the legal trouble), but for those annoying JS overlays or "sign up to read" popups? Yeah, the engine is pretty aggressive about nuking those to get to the text.

And regarding stability, that's the whole point. I try to strip 99% of the noise (navs, footers, sidebars). So even if a site redesigns their layout, your embeddings shouldn't break because the core text usually stays the same.

Shoot me a DM if you have any specific URLs that are breaking it, I'm always looking for new edge cases to fix.

That’s a great coincidence!

I actually used these exact APIs for a Deep Research project I built for a team recently, and they performed quite well. Please give them a try for your thesis. If you run into any issues or need specific optimizations for your research, just let me know. I’ll get back to you as soon as I see your message!

Thank you so much for the detailed review! It means a lot to see these features being appreciated by a fellow engineer. My main goal is simply to keep the service stable and cost-effective so everyone can focus on building their agents without the extra headache. Glad it's helping with your workflow!

Thank you so much! Honestly, with the pseudonym, I might not be able to guess exactly who you are, but I want to thank you from the bottom of my heart. 

Knowing that you stuck with me and the project during the most difficult early days means the world to me. It’s users like you who kept me going. Cheers to more updates ahead! 🥂