2
15 Comments

From 0 to $80 in 9 Days: What I Learned Building Korean Data APIs on Apify

6,658 API calls. 75 users. ~$80-90 in revenue. 9 days.

Those are the real numbers from my Korean data scraping side project. Not life-changing money, but it's the first dollar I've ever earned from code I built — and it taught me more about indie hacking than any course ever could.

The Idea: Why Korean Data?

I live in Seoul and noticed something: there's almost no structured data tooling for Korean platforms. Naver (Korea's Google), Melon (Korea's Spotify), Musinsa (Korea's biggest fashion marketplace) — all have data that businesses desperately need, but no easy way to get it.

So I built scrapers for all of them. 13 in total, over about a month.

The Stack

  • Platform: Apify (handles hosting, scaling, billing)
  • Languages: Node.js + Python
  • Monetization: Apify's Pay-Per-Event (PPE) model
  • Cost to build: $0 (Apify's free tier covered development)
  • Time: ~4 weeks of nights and weekends

The PPE model was the key decision. Instead of charging monthly subscriptions, users pay per API call — typically $0.005-0.05 per result. This means zero friction to try, revenue scales with usage, and I don't need to build payment infrastructure.

The Numbers (Day 9)

  • Scrapers deployed: 13
  • Total runs: 6,658
  • Unique users: 75 (~20 external)
  • Estimated revenue: $80-90
  • Revenue per day (avg): ~$10
  • Top scraper by volume: naver-news (3,700+ runs)
  • Most users: naver-place-search (17 users)

Revenue kicked in on March 13 when Apify activated PPE billing. My last scraper (Musinsa, Korean fashion) goes live March 25.

What I Got Right

  1. Niche selection. Korean data is underserved. Most of my scrapers have zero direct competitors on Apify. When someone searches "naver scraper," they find me.

  2. Platform leverage. Apify's marketplace brings organic traffic. I didn't do any marketing in the first week — users found me through search. 60% of early traffic was organic.

  3. Volume over perfection. I shipped 13 scrapers instead of perfecting one. Some get 3 runs a day. Others get 400+. By casting a wide net, I found the winners: naver-news and naver-place account for 72% of all runs.

What I Got Wrong

  1. Marketing is harder than building. I spent 95% of my time coding vs 5% on distribution. That ratio should have been flipped sooner.

  2. Not all scrapers are equal. My Korean webtoon and book scrapers get almost no usage. I should have validated demand before building all 13.

  3. Documentation > features. The scrapers that take off aren't the most sophisticated — they're the ones with the best README and examples.

What's Next

  • Multi-channel: RapidAPI (Cloudflare Worker proxies live), MCP server for AI agents, n8n community nodes
  • Content: Dev.to series (19 posts), Reddit, IH
  • Goal: $500/month by end of Q2 2026

The Honest Take

$80 in 9 days isn't quit-your-job money. But: it runs itself (no code changes since launch), it compounds (each new channel expands the audience), and the niche is defensible (Korean language + platform knowledge is a real moat).

The hardest part wasn't building 13 scrapers. It was accepting that the builder's work was done, and the marketer's work had just begun.

All 13 scrapers: apify.com/oxygenated_quagmire | MCP Server: github.com/leadbrain/korean-data-mcp

on March 22, 2026
  1. 1

    The marketplace discovery was the part that surprised me most too - I expected to find a gap in the data ecosystem but didn't expect an active buyer base already searching for the exact thing I was building. If you do start on Apify, the thing worth knowing upfront is that run volume and user count tell completely different stories about demand. High runs with few users means people are using it heavily for one workflow. Many users with low runs means broad but shallow interest. Both are useful but they want different follow-up products.

  2. 1

    RapidAPI is a great shout actually — hadn't thought about it that way but you're right, the built-in discovery changes everything. gumroad is basically a storefront with no foot traffic.

    going to look into listing the SEO API there this week. we've got 4 endpoints (seo analysis, speed check, tech detection, link scanning) that would map well to a per-call pricing model like your PPE setup on apify.

    the content angle you mentioned is interesting too — writing tutorials around specific use cases rather than just "here's a tool" probably converts way better. your naver-news docs being the top scraper proves that.

    thanks for actually checking out vemtrac, appreciate the honest feedback.

    1. 1

      Good luck with the listing — if you have 4 endpoints live and working, the RapidAPI submission moves fast once you get the OpenAPI definition set. The tutorial-per-use-case approach really does compound. Each one (e.g. "how to audit Core Web Vitals before a product launch") becomes a separate search entry point that's harder to replicate than the API itself. Let me know how the SEO API performs once it's up.

  3. 1

    That's the best kind of validation — organic search demand that already exists. You didn't have to create the market, just show up in it. Did you build naver-news first because you had a hypothesis about Korean data being underserved, or was it more of a random starting point that happened to work?

    1. 1

      Bit of both. The hypothesis was "Korean platforms have no structured data access" — that was intentional. But naver-news specifically wasn't a carefully tested first choice. I built it early because Naver News is the most fundamental data source in the Korean web stack. That naver-news became the volume leader (8,400+ runs, 6 users) while naver-place-search became the user leader (22 users, 1,100 runs) was emergent — I didn't predict which would dominate. The market told me after the fact.

  4. 1

    apify market is somthing i will checkout for sure
    love the post many great tips and love all things that are being written on here are really relatable

    1. 1

      Thanks! Hope you find something useful — the marketplace discovery alone made Apify worth starting with. Good luck with whatever you're building.

  5. 1

    this is the most honest first-revenue post i've seen on here. the "95% coding / 5% distribution" ratio hit hard because we're living that exact mistake right now. we built an api with 4 endpoints (seo analysis, speed checking, tech detection, link scanning) and like 21 gumroad products and have made exactly $0 because we spent all our time building and none of it getting in front of people.

    the documentation > features point is huge too. we noticed the same thing — our api technically works great but nobody finds it because the docs are buried and there's zero content pointing to it. meanwhile some random "10 free seo tools" listicle outranks everything.

    your niche moat is legit though. korean platform data with zero competitors on apify is way more defensible than what we're doing in the crowded seo/dev tools space (search vemtrac on gumroad to see what i mean). congrats on the first dollar, thats a real milestone.

    1. 1

      Good luck with the listing — if you have 4 endpoints live and working, the RapidAPI submission moves fast once you get the OpenAPI definition set. The tutorial-per-use-case approach really does compound. Each one (e.g. "how to audit Core Web Vitals before a product launch") becomes a separate search entry point that's harder to replicate than the API itself. Let me know how the SEO API performs once it's up.

    2. 1

      Thanks, really appreciate the honest comparison. 21 Gumroad products at $0 is actually a useful data point — it means your build velocity is solid, but the distribution channel might be the bottleneck rather than the products themselves.

      One thing that helped me was picking a platform where discovery is built in. Apify's marketplace works like an app store — people search for specific scrapers and find mine organically. If your SEO tools are good, the question might be less about building more and more about getting them in front of the right audience. Content that ranks for "[your tool category] free API" or tutorials showing real workflows could flip the ratio faster than you'd expect.

      I checked out vemtrac — the tech stack looks solid. Have you considered listing on a marketplace with built-in traffic (like RapidAPI for APIs) instead of relying on Gumroad's relatively limited discovery?

  6. 1

    The documentation insight is the one that stood out most here. It seems obvious in retrospect but most builders miss it: the README is your sales page. Someone lands on your Apify listing and decides in 30 seconds whether to trust the tool. Documentation isn't a nice-to-have. It's the product.

    The 95% coding / 5% distribution ratio is the trap nearly everyone falls into, me included. The fix isn't necessarily spending less time building. It's making the marketing happen in parallel. Logging the build as content, answering questions in the communities where your users already are, being visible in the niche before you have something to sell.

    Before you built scrapers 2 through 13, was there any signal from scraper 1 that made you confident the model worked? Or did you batch-build the full set before seeing any real traction?

    1. 1

      Bit of both. The hypothesis was "Korean platforms have no structured data access" — that was intentional. But naver-news specifically wasn't a carefully tested first choice. I built it early because Naver News is the most fundamental data source in the Korean web stack. That naver-news became the volume leader (8,400+ runs, 6 users) while naver-place-search became the user leader (22 users, 1,100 runs) was emergent — I didn't predict which would dominate. The market told me after the fact.

    2. 1

      Great question. Honestly, it was a mix of both. I built naver-news first and saw organic runs within the first few days — people were searching for "naver scraper" on Apify and finding it because there was literally nothing else. That signal gave me confidence the niche was real.

      But I didn't wait for full validation before building the rest. I batched scrapers 2-8 in the next two weeks, partly because the Korean platforms share similar structures so the marginal cost of each new scraper dropped fast. The first one took a week, the last few took a day each.

      In hindsight, I should have paused after 5-6 and measured which categories had real demand. My webtoon and book scrapers still get almost zero usage. If I'd validated first, I would have skipped those and spent the time on marketing the winners earlier.

      1. 1

        The "pause after 5-6 and measure" insight is the real takeaway here. Most builders I know (myself included) would have just kept shipping all 13 because it feels productive. But building scrapers nobody uses is just productive-feeling procrastination.

        The fact that organic Apify searches were your validation signal is interesting too. That's basically the market telling you what to build next instead of guessing. Did you ever consider building scrapers for non-Korean platforms where the same gap exists, or is the Korean niche defensibility too valuable to leave?

        1. 1

          Yes, the same gap exists for Japanese, Vietnamese, Thai platforms — same story: large platforms, no English scraper ecosystem, no official APIs.

          But the moat isn't "non-English web scraping." It's native language competency. I live in Seoul, can read Korean error messages, understand why Naver's auth changes, write documentation that's accurate because I've actually tested it. That advantage disappears the moment I'm building for platforms I can't read.

          Japanese would be the strongest next candidate on market size — someone who reads Japanese could run this exact playbook on Yahoo Japan, Rakuten, etc. But that's their edge to build, not mine.

          For now: the Korean portfolio is done. The actual problem is whether distribution can catch up to the product.

Trending on Indie Hackers
Your build-in-public audience is not your market. I learned the difference the slow way. User Avatar 119 comments I built a WhatsApp AI bot for doctors in Peru — launched 3 weeks ago, 0 paying customers, and stuck waiting for Meta to approve my app User Avatar 59 comments From broke and burned out as a PM, to launching my SaaS and optimizing my health User Avatar 30 comments Built a "stocks as football cards" thing. 5 days in, my launch tweet got 7 views. What am I missing? User Avatar 25 comments I kept starting projects and dropping them. So I built a system that wouldn’t let me User Avatar 23 comments We built Shopify themes to $20k/month. Now we have to pivot. User Avatar 22 comments