Fixing broken scrapers instead of working on my actual product. So I made it my problem.
I run a small bussiness that pulls social media data. Follower counts, video stats, engagement ect. From the start I handled the scraping myself. Proxies, session management, dealing with platforms changing things every other week.
It worked fine for a while. Then something would break, I'd spend all day fixing it, when I should be focusing on marketing.
I figured, I'm not the only person dealing with this. Anyone building social media tools, analytics dashboards, influencer platforms, content trackers — has this exact same problem. The scraping isn't their business either. It's just a thing that needs to work so they can get on with what actually matters.
So I built Social Fetch. One API, 8 platforms (Instagram, TikTok, YouTube, X, Threads, Pinterest, Snapchat, Reddit), consistent response format. Hit an endpoint, get your data, move on with your life.
2 months in:
- 312 users
- 121K+ requests served
- ~1,500/day right now
- Under 3 second average response time
- Most used: TikTok video data and Instagram posts
The users are pretty much exactly who I expected. People building tools where social data is an input, not the output. Nobody's here because they can't figure out web scraping. They're here because they figured out it's not worth their time.
It's at socialfetch.dev. Would genuinely appreciate feedback from anyone building in this space. What's missing, what would make it more useful, what would get you to switch from whatever you're currently doing.
Interesting. I noticed that when i click on Pricing, it goes nowhere.
It just keeps spinning and spinning and then it turns to "Something went wrong!" network error.
I think id be great to fix that.
This is a strong wedge because you are not selling “scraping” as the product. You are selling reliability for teams where social data is just an input they need to stop thinking about.
The traction also makes the pain feel real: 312 users, 121K+ requests, and people using it because maintaining scrapers is not worth their time. That is a much stronger positioning angle than “one API for 8 platforms.”
The one thing I’d pressure-test early is the name/domain frame. Social Fetch is clear, but it also sounds like a lightweight utility. What you are describing is closer to backend data infrastructure for social analytics, creator tools, influencer platforms, and content intelligence products.
Davoq .com would fit that direction better if you want the product to feel like serious infrastructure, not just a fetcher script. The current product is already doing the hard operational work behind other companies’ tools, so the brand should probably carry more technical trust before bigger users evaluate it.
Especially with a .dev domain and a reliability-heavy API, the first impression matters. The product does not need a different direction, but it may need a stronger infrastructure shell around the same thing.