Viktor.comAn AI coworker that actually does the work
Launching today
Mindcase
Extract data from anywhere on the web within minutes
457 followers
Extract data from anywhere on the web within minutes
457 followers
Mindcase is the infrastructure layer for extracting web data in a structured, usable format. Built for developers and AI teams that need reliable web data without managing scraping infrastructure. Access APIs across popular sources, or get anything across the web built as a custom API for your specific use case.
Mindcase
Hey PH 👋
I'm Kritish, cofounder of Mindcase.
We didn't set out to build a web data platform. We were just trying to get reliable data into the AI products we were building.
But getting data from the web turned out to be a lot harder than we expected. Scrapers would break, proxies would get blocked, parsers needed constant fixes, and before long, we were spending more time maintaining the data infrastructure than building the actual product.
So we started building what we wished we had. And that became Mindcase.
Mindcase is a web data API for AI agents - one API call in, clean structured data out.
You pick an agent, send it your inputs, and Mindcase handles everything in between: collection, rotating infrastructure, anti-bot, retries, scaling, and parsing.
Today, you can choose from 75+ ready-to-use agents across LinkedIn, Amazon, Google, Instagram, TikTok, YouTube and more.
A few things we're particularly excited about:
One API across sources — switch from linkedin/profiles to amazon/products without rebuilding your pipeline
Built for developers — Python & Node.js SDKs
Pay only for what you collect — prepaid wallet, no seats, subscriptions, or minimums
Transparent pricing — $0.06–$20 per 1,000 rows depending on the agent
No scraping infrastructure to manage — that's our problem, not yours
We're two founders from IIM Ahmedabad, building Mindcase with a small team and sweating the reliability details so you don't have to. It's built for teams using web data to power AI agents, lead generation, enrichment, market intelligence, e-commerce, research, data pipelines, and more.
And since we're launching on Product Hunt, we're giving 100% bonus credits on every credit purchase for the next 24 hours.
👉 Get your first call free + claim the 100% bonus on all our pricing plans: https://mindcase.co
We're going to be in the comments all day. Ask us anything, tell us what you think, or tell us which platform you'd like us to build an agent for next.
Really excited to finally share this with PH. 🚀
@kritishpuri Congrats on the launch. The line that stood out "scrapers would break, proxies would get blocked, parsers needed constant fixes" that's the real tax nobody sees until they're in it.
Curious how you handle drift at scale: when LinkedIn or Amazon tweaks their page structure, does that break one agent or does it cascade across others sharing similar parsing logic? And is there a lag between "site changed" and "agent's data goes stale/wrong" that customers might not notice right away?
Mindcase
@farrukh_ahmed8877 Thanks Farrukh. Straight answers to both. A site change hits the agents for that site, not the whole catalogue, since sources do not share parsing across sites.
And yes, there is a lag, there is no version of this where there is not. What we can control is that we are the ones looking for it and that the failure is visible rather than silent, because a wrong row you trust is far more expensive than a run that failed. If you end up using it and you see a case where that is not true, tell us, that is exactly the thing we want to hear about.
@kritishpuri That line between a failed run and a wrong row you believe that's the real dividing line, and most data tools just don’t call it out. A failure? Painful, but at least it’s obvious. A bad value that slips through? It poisons everything after it, and nobody notices until the whole system falls apart.
Which makes me wonder about catching these things early. How do you spot a parser going rogue before a customer does? Automated schema checks? Manual spot-tests? What’s actually checking under the hood? That “we’re the ones hunting for it” line is the one that feels most real—so yeah, what’s the machinery behind it?
Mindcase
@farrukh_ahmed8877 Appreciate you pushing on it, because that line is the part we most want to be held to. We deduplicate the data and we only charge based on the data that is delivered.
@kritishpuri Excited to hunt Mindcase today! :)
I have known @kanupriya_chhabra1 from a couple years on Product Hunt. When she first shared this product, I was excited because I myself connect a lot of APIs to my Claude Code.
The problem it goes after is one most teams meet eventually. Your product needs data that lives on the web, so somebody writes a scraper, then a second one, and before long a chunk of engineering time is going into keeping all of it alive rather than building the thing you actually set out to build.
Mindcase turns that into an API call. 75+ ready agents across the big sources, one consistent request and response shape so adding a source does not ripple through your code, Python and Node SDKs, MCP support, and custom agents built for you when the source you need is not already covered. You pay for rows you collect, prepaid, no subscription or per seat charge.
Give it a try!
answering Saurabh's question directly - we're a B2B SaaS and the source I'd actually pay for is G2/Capterra review pages for our competitors: review text, star rating, and reviewer company size band. Maybe 500-1000 rows a month, nothing crazy. Every competitive intel tool I've tried treats review sites as an afterthought behind the "big" platforms. Also curious about the pricing question Raunak asked above - if I fetch the same post twice in a day, am I paying twice or is there any caching on the backend?
Mindcase
@galdayan Appreciate you answering the question properly Gal. Review text, rating and reviewer size band across G2 and Capterra at around 1,000 rows a month is a well shaped request and we will come back to you in this thread with a straight yes or no on both sites rather than a maybe.
On pricing, you pay per collection, so calling the same page twice bills twice. Whether that matters depends entirely on the source. For reddit or twitter, as I said to Raunak above, the second call is usually the point, since the upvotes and comment counts have moved and you are collecting a second observation rather than the same row. Reviews sit at the other end of that. They accumulate rather than change, so a scheduled pull plus a dedupe on review id at your end is cheaper and gives you the same picture.
@kritishpuri Congratulations on launch, this seems like a great product replacing apify for me,
but i have some questions:
1. How we compare this to composio why this is better?
2. If i fetch a reddit or twitter post and got charged for it today example 1$ then will i be charged for the same exact fetch if i call the same posts twice in a day?
Second question is the one im bent on
Mindcase
@raunaks_99 Let me take that answer.
Since reddit and twitter posts aren't static, a second call is treated as a second collection. The thinking behind it is that when you pull the same post twice in a day you are usually after two points on a timeline rather than the same row again, since the upvotes, comment count and sometimes the text itself have moved between the two calls.
@kanupriya_chhabra1 Understood, also congratulations on ranking top 5 hope this becomes #1
Mindcase
@raunaks_99 thank you Raunak, hoping for the same, fingers crossed
Curious to see how this handles websites that constantly change layouts or add new restrictions. If the reliability holds up, this could become a useful foundation for many data-driven products.
Mindcase
@ryankeller Good thing to be sceptical about Ryan.
The structural advantage is not that we are cleverer about layout changes, it is that when a site changes it breaks for everyone using that agent at once, so we hear about it immediately and fix it once for all of them.
Maintaining it in house means you find out alone, usually late, and fix it alone every time. We are not going to claim we never break. We are claiming you are not the one who has to notice or repair it.
Mindcase
Saurabh here, cofounder at Mindcase.
Straight question for this thread, since you are the people who would actually use it: what should we build next?
We have live library across LinkedIn, Amazon, Google, Instagram, TikTok and YouTube, and almost every one of them exists because somebody asked for it, not because we planned it. So tell me the source you need, the two or three fields you actually care about, and roughly how many rows a month.
I will reply in this thread with whether it is straightforward, hard, or honestly a bad idea. Niche is fine. Some regional marketplace or an industry directory nobody outside that industry has heard of is usually more useful to us than another big platform.
The one API across completely different data sources is what caught my attention. Not having to rebuild the pipeline every time you need a new source is huge.
Mindcase
@jagbir_singh5 Thanks Jagbir, that was the exact pain that started this. Every source has its own auth quirks, pagination, and rate limits, so we normalised all of it behind one call shape. Swapping linkedin/profiles for amazon/products is a one line change, same request, same structured response.
@jagbir_singh5 @kanupriya_chhabra1 I like the idea of keeping the request and response format consistent. It should make switching data sources much simpler.
Mindcase
@oliver_graf1 Thank you Oliver. Keeping it uniform costs us more work internally, which is the point, since it means it costs you none.
Atlaso
Congrats on the launch! Does it have a router based on the scrapping that has to be done or do we have to assign each scrapper different path ? Also is there cli available ?
Mindcase
@ashish_khandelwal11 There is a separate endpoint for each API. There isn't a CLI but you can access Mindcase through the API or an MCP