I Built 35 Web Scrapers in 90 Days — Here's What I Learned About Making Money with Data

Building is the easy part. Distribution is where most developers fail.

It was a Tuesday morning when I opened my Apify dashboard and actually counted.

Thirty-five actors. 1,448 total runs. Scrapers for Twitter profiles, Google SERPs, Amazon products, LinkedIn pages, Reddit threads, job boards, e-commerce sites. A whole catalog of tools I'd spent three months building, debugging, and shipping.

Revenue: $0.

Not "not much." Not "a little disappointing." Zero. I had built a small data infrastructure company's worth of tooling, and precisely zero people had paid me for any of it.

That morning was uncomfortable. Not because I'd failed — I hadn't, not really — but because I'd been so busy building that I'd mistaken motion for progress. The dashboard looked impressive. The bank account told a different story.

This is that story. What I built, what I got wrong, what I'm doing differently, and the three things I'd tell anyone who wants to actually make money building data tools.

What I Actually Built (And Why)

The 90-day sprint started with a simple observation: data is everywhere, but structured data is surprisingly hard to get. Most APIs are either paywalled, rate-limited into uselessness, or just don't exist for the sites you actually need.

I'd been using Apify — a cloud platform for running web scrapers — for side projects, and I noticed their Store had a marketplace model. Developers could publish actors (containerized scrapers) and users could run them. Some actors had thousands of users. That looked like a distribution channel worth betting on.

So I built. A lot.

The workhorses ended up being the expected ones:

• twitter-profile-scraper — 192 runs. People want social data desperately. Follower counts, bio text, engagement metrics. Growth hackers, researchers, journalists. Twitter's own API became increasingly hostile after the 2023 changes, so demand for alternatives went up.

• google-serp-scraper — 136 runs. SEO professionals live and die by ranking data. This one ran itself once I got it into the Store. People found it, ran it, moved on.

• amazon-product-scraper — 70 runs. E-commerce competitor monitoring. This use case is genuinely evergreen — someone somewhere always needs to track what a competitor is charging for a product.

Beyond the top three, I had scrapers for LinkedIn company pages, Hacker News job posts, Glassdoor reviews, GitHub repository stats, YouTube channel data, and a handful of niche retail sites. Most of them got 5–30 runs. A few got none at all.

The technical work was satisfying. Playwright for the JavaScript-heavy sites, Cheerio for the simpler ones. Rate limiting, proxy rotation, schema design, error handling. Real engineering problems with real solutions. I got better at all of it.

What I didn't get better at — not until much later — was thinking about who was going to use any of this, or why they'd care.

The Mistake I Made (And It's Not What You Think)

The obvious post-mortem story would be: "I built the wrong things." But that's not quite right.

Twitter data, SERP data, Amazon product data — these have real, proven demand. People pay for this stuff. Companies are built on it. I wasn't off on the market need.

The mistake was subtler: I built for myself as a user, not for someone finding me cold.

When you build a tool you personally need, you understand the full context. You know what problem it solves, what the input should look like, what "good output" means. That knowledge lives entirely in your head. And when someone lands on your Apify actor page with zero context, all that implicit knowledge is invisible to them.

My actor descriptions were sparse. "Scrapes Twitter profiles." Cool. What fields? What rate? What does the output JSON look like? Does it handle private accounts? What's a realistic run time for 500 profiles?

I'd skipped the documentation because I knew how it worked. Classic curse of knowledge.

The deeper mistake was about distribution sequencing. I had this mental model where I'd build → list on Apify Store → people would discover it → money would follow. That chain has a broken link right in the middle. Apify Store has SEO, yes, and it does drive organic traffic over time. But "over time" is doing a lot of work in that sentence. You don't just list a tool and watch users appear. You have to push.

I was building in a vacuum, then listing into a vacuum, and wondering why it felt empty.

What Actually Moves the Needle

Here's what changed once I stopped adding new scrapers and started actually paying attention to distribution.

Apify Store SEO is real, but it rewards specificity.

Generic actor names ("web scraper," "data extractor") perform worse than specific ones. "twitter-profile-scraper" ranks for people searching Twitter scraping tools. The description needs to front-load keywords that match actual search intent: what site, what data, what format. I went back and rewrote descriptions for my top actors. Runs picked up. Not dramatically — but measurably.

Dev.to and Hashnode articles drive targeted traffic.

Writing a tutorial like "How to scrape Google search results with Node.js" and linking to the actor as the "skip the setup" option works. The readers are developers who already understand the problem. They're pre-qualified. A 1,000-word tutorial on dev.to that ranks for a scraping query is worth more than a month of hoping Apify's internal search does the work for you.

I haven't done enough of this yet. It's on the list. (More on that in a minute.)

The actors that get usage get more usage.

This one stung a bit when I noticed it. Apify's Store surfaces actors with more runs more prominently. The rich get richer. My top three actors — Twitter, SERP, Amazon — got there partly because I seeded them with my own test runs early on, partly because the use cases are genuinely high-demand. The long tail of scrapers with 0–5 runs are nearly invisible. Getting a new actor past the "cold start" problem requires external traffic, not patience.

The Turning Point: Bundling and Gumroad

The shift in my thinking came from a conversation with another indie hacker who sold Notion templates. He made the point that people don't buy tools, they buy solutions to problems they have right now. A single scraper is a tool. A bundle of scrapers organized around a use case is closer to a solution.

That reframe changed how I looked at everything I'd built.

I had scrapers for Twitter, LinkedIn, Reddit, and YouTube. Individually, each one is a tool. Together, they're a social media intelligence kit. I had scrapers for Google SERPs, competitor product pages, and review sites. Together: a competitive research toolkit.

So I built a Gumroad bundle — 30 ready-to-use web scrapers packaged together with documentation that explains the use cases, sample outputs, and a quick-start guide. Not just "here are the actors," but "here's how to use these together to monitor your competitors' pricing" or "here's a workflow for tracking brand mentions across platforms."

The Gumroad page is live. Sales are still at zero — I'm not going to pretend otherwise. But the product is actually a product now in a way that a list of actor links never was. It has a landing page, a narrative, a price point that signals value without being a barrier. That's a meaningfully different thing than what I had before.

And frankly, the act of building the bundle forced me to audit what I'd made. Some actors weren't good enough to include. I fixed them. Others I'd underrated. The curation process was its own form of quality control.

3 Lessons for Anyone Building Data Tools

I want to be concrete here, because "build things people want" is advice that sounds obvious and means nothing.

1. Solve for the first five minutes, not the first five runs.

The most common reason a developer abandons a new tool is friction in the first session. For Apify actors, that means: your README needs a working example input you can paste directly into the actor and get output within 60 seconds. No configuration headaches. No "it depends." One concrete example that works. Everything else can be complex — the first experience needs to be frictionless.

2. Build the distribution asset before (or alongside) the tool.

A scraper with a companion blog post that ranks for "[site] scraper API" will outperform a better scraper with no content, almost every time. The content is the moat, not the code. Code gets copied. A tutorial, a case study, a guide — those are harder to replicate and they compound over time through search.

If I were starting over, I'd write one 800-word tutorial per actor before shipping the actor. Not after. Before. It forces you to think about how someone would actually use the thing, which usually surfaces design problems you'd otherwise only discover after people are confused.

3. Price signals matter more than you think.

I had some actors listed for free and others at the minimum Apify pay-per-result pricing. Free things feel low-value, even when they're technically better. When I restructured some of the paid actors and made the pricing more explicit — and explained what you got for the money — perceived quality went up. This is true for the Gumroad bundle too. $29 for 10+ professional scrapers with documentation is not expensive. But it has to not be free, or the implicit message is "this is the kind of thing people give away."

Where Things Stand, Honestly

Thirty-five actors, 1,448 runs, $0 in direct revenue from external users. That's the current scoreboard.

But here's what I also have: a portfolio of tools that actually work, a better understanding of what Apify's distribution actually rewards, a Gumroad product that's a real product (not a wishlist), and — writing this — a clearer sense of what the next 90 days need to look like.

The next phase isn't building more scrapers. It's content, SEO, and making the existing tools easier to discover and understand. A few targeted articles. Better documentation. More deliberate use of the bundle as a conversion point for people who land on individual actor pages.

If you're a developer thinking about building on Apify — or any marketplace-based platform — the thing I most want you to take away is this: the marketplace is a distribution assist, not a distribution strategy. It gets you a non-zero baseline. The actual numbers come from what you do outside the platform.

If any of this is relevant to what you're working on:

You can see all 35 actors (and the use cases they cover) on my Apify profile. Most are free or pay-per-result — you can run them directly in the browser without writing any code.

If you want the bundled version with documentation and workflows, the Apify Scrapers Bundle on Gumroad is live and includes 30 ready-to-use actors with a quick-start guide. It's built for people who want the data without spending hours figuring out actor configuration.

And if you're building something similar and want to compare notes — I'm genuinely interested. The intersection of developer tools, data infrastructure, and indie distribution is still being figured out. The more people share what's actually working, the better.

This article is part of an ongoing series about building and distributing developer tools as an indie project. Follow for future updates.