DEV Community: George Kioko

How I lost $540/month in 30 days to silent user churn (and didn't notice)

George Kioko — Fri, 24 Apr 2026 04:34:05 +0000

Last week my 30 day profit dropped from $268 to $50 and I assumed it was a bug in the dashboard.

It wasn't a bug. It was me not paying attention for 29 days straight.

This is a postmortem of how I lost roughly $540/month from two agency buyers who just quietly stopped running my actor on March 25. I found out on April 23. That's 29 days of ambient denial while every other part of my portfolio was also quietly rotting.

Writing this partly so I remember the lesson, partly because I know at least three other Apify devs are about to make the same mistake.

The numbers

I run a bunch of scrapers and APIs on Apify. Here's what the revenue split actually looked like in early April before things went sideways.

Actor	Users	Monthly revenue	% of total
Google Maps Lead Intel	2	$540	83%
LinkedIn Employee Scraper	37	$42	6.5%
YouTube Transcript	40	$28	4.3%
Google Scholar	18	$14	2.1%
Email Validator API	46	$11	1.7%
Website Intelligence API	22	$8	1.2%
Everything else (5 actors)	188	$7	1.1%
Total	353	$650	100%

Read that first row again. Two users. $540. More than the other 351 users combined, by a factor of like 7x.

I told myself this was fine because the product was working and the buyers were happy. Both things were true in early March. Neither was true by late March. I just didn't know.

The silence

March 25 was the last run either agency executed. I didn't flag it because nothing explicit broke. No error email, no angry message, no refund request. My Apify dashboard just showed fewer runs but the rolling 30 day number still looked okay because it was still averaging in the fat weeks from before.

Here's roughly how the number moved:

Early April: $268 rolling 30d profit. I'm feeling smug.
Mid April: $92. I figure maybe it's a slow week.
April 22: $50. I finally open the run logs.

By the time I looked, the last run from either agency was 29 days ago. Whatever issue they had (I still don't fully know), they decided it wasn't worth telling me about. They just left.

Agency users don't complain. They just stop paying. If you're building for them, burn that into your forehead.

What I found when I actually looked

This is the part that made me feel physically ill. Once I started doing a proper audit of my portfolio, I found that 6 of my other 10 monetized actors were broken in some way. Not all catastrophic. Some were returning partial data. One had a silently failing selector from a site redesign in February. One was charging $0 per run because of a broken Actor.charge() signature I'd introduced in a refactor.

Let me repeat that: I had actors that were executing successfully, returning data to users, and billing them exactly nothing. For weeks.

If one of those 2 agencies had tried a second actor of mine during that period, they'd have gotten rot. That's probably why they didn't come back.

The root cause wasn't the bugs though. Bugs happen. The root cause was that my attention was entirely on the $25/run cash cow because it was paying the bills. The cash cow was hiding the state of the herd.

Why 2 agency users paid more than 353 devs

I want to sit with this one because I think most solo devs misunderstand it.

My Google Maps Lead Intel actor charges $25 per successful run. It scrapes a geography, enriches each business with a website audit, scores them, and hands the agency a ranked list of cold outreach targets. One agency was running it on a schedule against 40 US cities per week. At $25 a pop, that's serious money.

The 353 devs on my other actors were paying $0.003 to $0.01 per row. They're hobbyists, students, one guy building a thesis scraper. They're lovely. They're also economically irrelevant to whether I can pay rent.

Two lessons fell out of this.

First, your paying users and your popular users are almost never the same people. Popularity on Apify Store is a vanity metric. Agency retention is the only metric that buys groceries.

Second, concentrated revenue is fragile in ways that only hurt you once. When I had 2 whales, my revenue was 83% dependent on their mood. The moment either whale left, my month was destroyed. Worse, because they paid so much, I built no alerting around them. I assumed I'd notice. I did not notice.

If you're reading this as an agency owner looking for scraping tools, what you actually want is a vendor who is not dependent on you. Someone with 50 paying clients will answer your ticket faster than someone with 2, because the guy with 2 is terrified of you and therefore weirdly slow to respond to bad news.

What I'm changing

Not writing a manifesto. Just the four things I'm doing this week.

Push alerting on every run. Apify has webhooks. I never wired them up because my dashboard was enough. It wasn't. Every successful run, every failed run, every billing event now pings a private Telegram channel I actually read. Here's the whole snippet, it's embarrassingly short:

// webhooks config in actor.json points at this endpoint
// payload is whatever Apify sends plus the run metadata
export async function notify(req, res) {
    const { eventType, eventData, resource } = req.body;
    const text = `[${eventType}] ${resource?.actId} run ${resource?.id}\n`
               + `status: ${resource?.status}\n`
               + `charged: $${resource?.usageTotalUsd ?? 0}`;
    await fetch(`https://api.telegram.org/bot${TG_TOKEN}/sendMessage`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ chat_id: TG_CHAT, text }),
    });
    res.status(200).end();
}

That's it. If I'd had this on March 25, I'd have noticed the absence of runs within 48 hours, not 29 days. If you run anything that bills users, stop reading and go wire this up. Seriously.

Weekly self test of every monetized actor. Every Sunday I run each of my paid actors against a known input and diff the output against last week's. If the schema changes or the row count collapses, I know before the user does. This is stupid simple and I should have been doing it from day one.

Diversifying the buyer pool. $25/run is staying. But I'm actively building out the $5 to $10 tier with two new actors targeted at small agencies, because I want the bottom of the revenue chart to be less wobbly. Ten $50/month buyers survive any one of them leaving. Two $270/month buyers don't.

Public status page. Still building this but the idea is: if an actor is degraded, the user knows before they hit it. Trust compounds and I just burned a chunk of it, so I'm paying interest now.

Close

If you run any product that bills users on autopilot, go wire a Telegram or Slack webhook today. Not tomorrow. The 30 day rolling dashboard lies to you when things trend down because it's still averaging in good weeks. Push alerts don't lie. Runs either happen or they don't.

I'm writing this mostly for me. But if you want to see what the portfolio looks like now, or hire the actor that caused all this drama in the first place, it's here:

Apify profile: https://apify.com/george.the.developer
Google Maps Lead Intel (the $25/run one): on the same profile
Everything else I've shipped (27 public actors, some broken last week, all fixed now): same profile

Ask me anything in the comments. Especially if you're an agency buyer thinking about pulling the trigger on a vendor. I have thoughts about what you should actually be looking for.

Two APIs I Built This Week That Cost Nothing to Run

George Kioko — Thu, 23 Apr 2026 11:50:41 +0000

Most APIs have a dirty secret in their pricing: the upstream service they call costs money, and that cost gets passed to you plus margin. LLM based APIs charge you for tokens. Geocoding APIs charge you for lookups. Data enrichment APIs charge you for the enrichment source.

I wanted to build APIs where the underlying operation costs literally zero. Here are two I shipped this week.

API 1: DNS Record Checker

Node.js ships with a built in dns module. It can resolve A records, MX records, CNAME, TXT, NS, and more. No external API call needed. No third party service. The DNS resolution happens through the operating system's resolver, which is free.

import dns from 'dns/promises';

const records = await dns.resolveAny('example.com');
// Returns A, AAAA, MX, TXT, NS, SOA records

That's it. Zero dependency, zero API cost, zero rate limits from upstream providers.

The actor wraps this into a clean JSON API. Pass it a domain, get back every DNS record type with TTLs, priorities for MX records, and SPF/DKIM/DMARC validation. The whole thing runs on Apify's Standby infrastructure so it responds in under a second.

Use cases that keep coming up: automated domain verification for SaaS onboarding, email deliverability checks (MX + SPF + DKIM in one call), security audits scanning for misconfigured DNS, and monitoring tools that alert when records change unexpectedly.

API 2: Sentiment Analysis

The common approach to sentiment analysis is sending text to an LLM and paying per token. That works but it's expensive at scale and adds latency.

Instead I used a word level lexicon approach. The API scores text using a pre built dictionary of ~7,000 words with known sentiment values. No LLM call. No external API. The scoring runs entirely in memory on the Node.js process.

// Simplified version of the scoring logic
const score = words.reduce((sum, word) => {
  return sum + (lexicon[word] || 0);
}, 0) / words.length;

The result includes an overall sentiment score, confidence level, and breakdown of positive vs negative word matches. It handles negation ("not good" scores negative) and intensifiers ("very good" scores higher than "good").

Is it as nuanced as GPT? No. But for brand monitoring, review analysis, social media tracking, and content moderation at scale, a deterministic lexicon approach that returns in 50ms beats a 2 second LLM call that costs 10x more.

The pattern worth noticing

Both of these APIs follow the same principle: use what's already built into the runtime or ship a static dataset with the code. No external dependencies that cost money per call.

This matters because of what I've seen with my existing domain tools. The WHOIS Lookup actor has power users running 262 lookups per user on average. Domain and DNS tools get embedded in automated workflows and run at high volume. When your per call cost is zero, your margin stays healthy no matter how much a single user hammers the API.

Pricing

DNS Record Checker: $0.003 per lookup. Sentiment Analysis: $0.003 per text analysis. Both running on Apify Standby mode for instant responses.

The infrastructure cost is just Apify compute time. No upstream API bills eating into revenue.

Try them on Apify:

Built in Nairobi. 52 actors, zero external API costs on these two. Comments and questions welcome.

2 Users Pay Me More Than 353 Users: The Pricing Lesson That Changed Everything

George Kioko — Thu, 23 Apr 2026 11:49:30 +0000

I have 48 actors running on Apify. Same platform, same developer, same tech stack. Two of those actors tell completely different stories about how software makes money.

My LinkedIn Employee Scraper has 353 users. It runs thousands of times per month. It charges $0.005 per profile scraped. Total monthly revenue from all those users and all those runs? About $9.

My Google Maps Lead Intel actor has 2 users. Two. They run it about 22 times per month between them, paying roughly $25 per run. Monthly revenue? Around $540.

That is a 60x difference in revenue per user. Same platform. Same developer. Same billing system.

What Makes Google Maps Worth $25 a Run

The LinkedIn scraper returns raw data. Names, titles, company info. It does one thing and does it well, but developers treat it like a commodity. They plug it into their own pipelines and expect it to cost almost nothing. At $0.005 per profile, it basically does.

Google Maps Lead Intel returns something different. For every business it finds, you get validated email addresses, a lead score based on 12 online presence signals, Google Ads detection, website tech stack analysis, social media profiles, and review sentiment. It is not scraping. It is intelligence.

The two users paying $25 per run are lead generation agencies. One services appointment setting clients across 15 metro areas. The other runs local SEO audits. For both of them, a single $25 run replaces 3 to 4 hours of manual research that would cost $200+ if done by a VA.

The Buyer Problem

Here is what I missed for months: the LinkedIn scraper attracts developers. Developers are price sensitive. They can build their own scraper given enough time, so they benchmark your tool against their hourly rate. If your scraper costs more than 20 minutes of their time to build, they will build it themselves.

The Google Maps actor attracts agencies. Agency buyers think in terms of client value, not engineering time. If their client pays $1,500/month for lead gen services and your tool costs $25 per market, that is a rounding error in their margin. They do not negotiate. They do not churn. They run it more as they sign more clients.

Same platform. Totally different buyer psychology.

What Actually Changed

The technical shift was not dramatic. I stopped returning raw JSON blobs and started returning enriched, scored, validated output. Specifically:

Raw Google Maps results became leads with quality scores
Guessed emails became validated emails with deliverability checks
Basic business info became competitive intelligence with ad spend signals
Flat data became actionable reports that agencies could forward to clients

The pricing shift followed naturally. When your output saves someone 4 hours of work and costs them $25, you are not competing on data volume. You are competing on time saved and decision quality.

The Numbers I Wish I Knew Earlier

353 users at $0.005/run = roughly $9/month. Those users submit support tickets, request features, and compare you to 6 other LinkedIn scrapers in the Apify Store.

2 users at $25/run = roughly $540/month. Those users send you "thank you" messages and ask if you can build them something custom.

If I could go back and rebuild my portfolio from scratch, I would build fewer tools and make each one solve a complete problem for a specific buyer. Not "scrape this website" but "find me qualified leads in this market with contact info I can trust."

The Takeaway

Stop counting users. Start counting revenue per user. Build for the buyer who measures your tool against the cost of the alternative, not against the cost of building it themselves. Package intelligence, not data.

The developer who needs 10,000 LinkedIn profiles will always shop on price. The agency owner who needs 200 qualified leads by Friday will pay whatever gets it done.

I know which buyer I am building for now.

Built in Nairobi. 48 actors in production. Questions? Drop them below.

The 5 APIs That Run 200+ Times Per User (And Why That Matters)

George Kioko — Thu, 23 Apr 2026 11:47:43 +0000

Most developer tools get used a handful of times. Someone finds your API, tries it on a test case, maybe runs it a dozen more times, then moves on. That is the normal pattern. Out of 38 actors I have running on Apify, most average 5 to 20 runs per user. Respectable numbers.

But five of them break the pattern completely. These five average 100 to 260 runs per user. Not because of better marketing or a viral tweet. Because they solve problems that require bulk processing by design.

The Numbers

Here is the actual usage data from my Apify dashboard:

API	Runs Per User
Domain WHOIS Lookup	262
Google Scholar Scraper	230
AI Content Detector	132
Website Tech Detector	126
Email Validator	105

Compare that to something like the LinkedIn Employee Scraper, which has 37 users but averages about 17 runs each. LinkedIn users grab the data they need and stop. WHOIS users feed in hundreds of domains every single session.

Why These Five?

The common thread is not the subject matter. It is the workflow. Every one of these tools plugs into a process where the user already has a list and needs to process all of it:

Domain WHOIS Lookup (262 runs/user): Security researchers and domain investors run this on batches of suspicious domains. When a phishing campaign registers 10,000 domains with similar naming patterns, someone needs registrar data, creation dates, and nameservers for every single one. That is not a one time task. New domains appear daily.

Google Scholar Scraper (230 runs/user): Academic researchers doing systematic literature reviews or bibliometric analysis. They need every paper matching a query, with citations, h index scores, and author profiles exported as structured JSON. One research project can require pulling data on thousands of papers across multiple search terms.

AI Content Detector (132 runs/user): Content moderation teams, academic integrity offices, and publishers who need to scan entire content catalogs. Checking one essay at a time is pointless when you have 500 submissions or 2,000 product descriptions to verify. The bulk API call is the only thing that makes this practical.

Website Tech Detector (126 runs/user): Sales development teams that need technology intelligence on their entire prospect list. If you are selling a React migration service, you need to know which of your 3,000 target companies still run Angular or jQuery. Feed in the list, get back frameworks, CDNs, analytics tools, CMS platforms in clean JSON.

Email Validator (105 runs/user): Cold outreach operators who clean their lists before every campaign. A 5% bounce rate destroys your sender reputation, so smart operators validate 500 to 5,000 emails before hitting send. They do this before every single campaign, not once.

What This Means for Builders

The lesson is simple: if your API solves a problem that people encounter once, you need constant marketing to keep new users flowing in. If your API solves a problem that people encounter in batches, repeatedly, you get sticky users who come back on their own.

None of these five APIs went viral. None of them got featured in a newsletter. The WHOIS lookup has 7 total users. But those 7 users have collectively run it 1,837 times. That is revenue without marketing spend.

The best APIs are not the ones with the most users. They are the ones where each user cannot stop running them.

Try Them

All five are live on the Apify Store under my profile (george.the.developer), priced per call with no monthly subscription. Domain WHOIS at $0.005/lookup, Scholar at $0.004/paper, AI Detector at $0.003/text, Tech Detector at $0.005/site, Email Validator at $0.002/email.

Built in Nairobi. 38 actors, 700+ users, 14,000+ total runs.

Google Scholar Has No API Either. Here's What 5,000 Runs Taught Me

George Kioko — Thu, 23 Apr 2026 11:46:16 +0000

Google Scholar is the single most important search engine for academic research. Billions of papers indexed, citation counts, author profiles, related work links. And Google has never released an official API for it.

Not deprecated. Not restricted. Just... never built one.

If you want to programmatically search Google Scholar, grab paper titles, authors, citation counts, and PDF links, you are on your own. So I built an actor that does exactly that.

What It Pulls

You give it a search query (like "transformer architecture attention mechanism") and it returns structured data:

{
  "title": "Attention Is All You Need",
  "authors": "A Vaswani, N Shazeer, N Parmar...",
  "citationCount": 112847,
  "year": "2017",
  "url": "https://arxiv.org/abs/1706.03762",
  "pdfUrl": "https://arxiv.org/pdf/1706.03762",
  "snippet": "The dominant sequence transduction models are based on complex recurrent..."
}

Paper titles, author lists, citation counts, publication year, direct links, and PDF URLs when available. Everything a researcher needs to build a literature review or track citations over time.

The Numbers Tell a Story

Here's where it gets interesting. The actor has 22 users and 5,065 total runs. Do the math on that ratio: 230 runs per user on average.

These are not casual users clicking "Run" once to test it. These are power users running it at scale. Academics building citation databases. Research firms tracking publication trends across thousands of queries. AI companies monitoring new papers in their domain.

That run to user ratio is the strongest signal I have that this tool solves a real problem. When someone runs your tool 200+ times, they have built it into a workflow.

Why Scholar Is Hard to Scrape

Google Scholar is notoriously aggressive about blocking automated access. It will throw CAPTCHAs after just a handful of requests from the same IP. Most simple scraping scripts break within minutes.

The actor handles this with:

Proxy rotation across residential IPs
Session management to maintain cookies between requests
Randomized delays that mimic human browsing patterns
Automatic retry logic when a request gets blocked

I also had to deal with Google's inconsistent HTML. Scholar's markup changes subtly over time. Element class names shift, layout structures get tweaked. The parser needs regular maintenance to keep working.

Who Uses This

Three main groups keep showing up:

Academics and PhD students building systematic literature reviews. Instead of manually searching and copying results, they run batch queries and get structured data they can feed into reference managers or spreadsheets.

Research firms and think tanks tracking publication trends. They want to know how many papers mention "large language models" per quarter, or which authors are publishing most frequently in a specific subfield.

AI and ML teams monitoring state of the art. When a new paper drops with high early citation velocity, they want to know about it fast.

Try It

The actor is on the Apify Store with pay per result pricing ($0.004 per paper): Google Scholar Scraper

If you have ever copy pasted results from Google Scholar into a spreadsheet, this will save you hours. And if you are doing it at scale, it will save you from getting IP banned.

Built in Nairobi by George. 40+ actors, 5,000+ runs on Scholar alone.

YouTube Has No Transcript API So I Built One (150 Users Later)

George Kioko — Thu, 23 Apr 2026 11:44:51 +0000

You know what's wild? YouTube, a Google product, has no official API for pulling video transcripts. You can upload, search, and manage playlists through their API. But if you want the actual words spoken in a video? Good luck.

I ran into this wall in late 2025 while building a content repurposing tool. I needed transcripts from YouTube videos to feed into an LLM for summarization. The YouTube Data API v3 gives you metadata, thumbnails, view counts. But transcripts? Nope.

So I built my own.

What It Actually Does

The actor loads a YouTube video page, grabs the auto generated captions that YouTube creates for most videos, and returns clean text with timestamps. It supports multiple languages because YouTube generates captions in different languages automatically.

Here's what the output looks like:

{
  "videoUrl": "https://www.youtube.com/watch?v=dQw4w9WgXcQ",
  "title": "Example Video Title",
  "language": "en",
  "transcript": [
    { "text": "Welcome to this tutorial", "start": 0.0, "duration": 2.5 },
    { "text": "Today we are going to cover", "start": 2.5, "duration": 3.1 }
  ]
}

No API key needed. No OAuth flows. Just pass in a video URL and get the transcript back.

The Numbers After 8 Months

I published this on the Apify Store and kind of forgot about it for a while. Then I checked the dashboard:

154 users have tried it
1,737 total runs across all users
It's one of my most popular actors out of 40+

The thing that surprised me was who's using it. I expected developers. And yes, developers building AI pipelines are a big chunk. But I also see researchers pulling transcripts from lecture series, content creators repurposing their own videos into blog posts, and marketing teams analyzing competitor video content.

The Hard Parts

YouTube does not make this easy. Captions are loaded dynamically through a separate request after the page renders. The URL for the caption track is embedded inside a massive JSON blob in the page source. Finding and parsing that reliably took more debugging than the actual extraction logic.

The other challenge: some videos have manually uploaded captions, some have auto generated ones, and some have both. The actor handles all three cases and lets you pick which language you want.

Rate limiting is real too. YouTube will throttle you if you hammer it. The actor spaces out requests and uses session management to stay under the radar.

Why Not Just Use a Python Library?

There are Python packages like youtube_transcript_api that do something similar. They work fine for one off scripts. But when you need to run this at scale, on a schedule, with proxy rotation and automatic retries, you want infrastructure around it.

That's what Apify gives you. The actor runs in the cloud, handles failures gracefully, and stores results in a dataset you can export to JSON, CSV, or push to a webhook.

Try It

The actor is free to run on Apify (you just pay for compute, which is pennies per video): YouTube Transcript Extractor

If you are building anything that needs video content as text, save yourself the headache of reverse engineering YouTube's caption system. Someone already did that part for you.

Built in Nairobi by George. 40+ actors on the Apify Store, 154 users on this one alone.

My LinkedIn Scraper Just Hit Top 20 on Apify — Here's How I Built It

George Kioko — Thu, 23 Apr 2026 11:41:25 +0000

I woke up last week to an email from Apify saying my LinkedIn Employee Scraper had earned the Rising Star badge — meaning it cracked the top 20 actors on the entire platform. 176 users, 2,430 runs, and counting.

This is the story of how a side project built in Nairobi turned into one of the most-used LinkedIn scrapers on Apify.

The Problem: LinkedIn Has No Real API for Employee Data

If you've ever tried to pull employee data from LinkedIn programmatically, you already know the pain. LinkedIn's official API is locked down tight — you need partner status or a Sales Navigator license ($800–$1,200/month) just to get basic company employee info.

For indie developers, recruiters building internal tools, or startups doing competitive intel, that price tag kills the project before it starts. I needed a different approach.

How It Works: Playwright + Crawlee + Anti-Detection

The scraper runs as an Apify Actor using Crawlee (Apify's open-source crawling framework) with Playwright driving a real Chromium browser. Here's the core pattern:

import { Actor } from 'apify';
import { PlaywrightCrawler } from 'crawlee';

await Actor.init();
const input = await Actor.getInput();
const { linkedinUrls = [], maxProfiles = 50 } = input;

const crawler = new PlaywrightCrawler({
  proxyConfiguration: await Actor.createProxyConfiguration({
    groups: ['RESIDENTIAL'],
  }),
  launchContext: {
    launchOptions: {
      headless: true,
      args: ['--no-sandbox', '--disable-blink-features=AutomationControlled'],
    },
  },
  minConcurrency: 1,
  maxConcurrency: 2,

  async requestHandler({ page, request }) {
    // Human-like delay between actions
    await page.waitForTimeout(2000 + Math.random() * 3000);

    const employees = await page.$$eval('.org-people-profile-card', cards =>
      cards.map(card => ({
        name: card.querySelector('.artdeco-entity-lockup__title')?.innerText?.trim(),
        title: card.querySelector('.artdeco-entity-lockup__subtitle')?.innerText?.trim(),
        profileUrl: card.querySelector('a')?.href,
      }))
    );

    await Actor.charge({ eventName: 'profile-scraped', count: employees.length });
    await Actor.pushData(employees);
  },
});

await crawler.addRequests(linkedinUrls.map(url => ({ url })));
await crawler.run();
await Actor.exit();

The architecture isn't complicated, but the details are what make it survive in production. LinkedIn is one of the most aggressive anti-bot platforms out there, so every layer matters.

What Actually Keeps It Running

Three things separate a LinkedIn scraper that works once from one that runs 2,430 times without breaking:

Session management. Instead of logging in fresh every run, the scraper persists cookies and reuses sessions. This mimics real user behavior and avoids triggering LinkedIn's "new device" verification flow.

Residential proxies. Datacenter IPs get flagged within minutes on LinkedIn. The actor routes through Apify's residential proxy pool, rotating IPs per request. Each request looks like it comes from a different home internet connection.

Randomized timing. No fixed delays. Every pause between actions uses Math.random() to vary between 2–5 seconds. Linear timing patterns are the easiest signal for bot detection systems to catch.

I also limit concurrency to 1–2 parallel requests max. It's slower, but LinkedIn's rate limiting is harsh enough that going faster just burns through proxy credits with nothing to show for it.

The Numbers

Here's where the scraper stands today:

176 users on Apify Store
2,430 total runs in production
Rising Star badge — top 20 actor on the platform
Pay-per-event pricing at $0.004 per profile scraped

For context, I launched this about a year ago as one of my first Apify actors. It started getting steady traction around the 500-run mark, and growth has been compounding since. The Rising Star badge was a genuine surprise — I didn't realize it had climbed that high until the notification hit my inbox.

Lessons Learned Building Scrapers at Scale

LinkedIn changes its DOM constantly. I've had to update selectors at least four times. If you build a LinkedIn scraper, abstract your selectors into a config object so you can patch them without rewriting handler logic.

Users will throw anything at your actor. Company pages with 50,000 employees, URLs with typos, private profiles, pages behind auth walls. Defensive coding isn't optional — it's the entire job. Every edge case that crashes your actor is a 1-star review waiting to happen.

Pay-per-event pricing works. Charging per profile scraped instead of per run aligns cost with value. Users scraping 10 profiles pay less than users scraping 10,000. This keeps casual users happy while still generating real revenue from power users.

Good README = more users. My most-used actors all have detailed READMEs with input/output examples, Mermaid architecture diagrams, and clear pricing breakdowns. Developers don't install tools they can't understand in 30 seconds.

What's Next

I'm currently running 38+ actors on Apify covering everything from Google Scholar to Telegram channels to OFAC sanctions data. The LinkedIn scraper remains my top performer, and I'm working on v2 with better pagination handling and support for scraping by department filters.

If you're building scrapers and want to see the code, everything is on GitHub. If you just need LinkedIn employee data without building anything, the actor is ready to run on Apify Store.

Apify Store: https://apify.com/george.the.developer
GitHub: https://github.com/the-ai-entrepreneur-ai-hub

Built in Nairobi. Questions about the scraper or Apify actors in general — drop them in the comments.

I Built a TikTok Shop Affiliate Finder That Maps Every Creator Promoting a Product in 2 Minutes

George Kioko — Fri, 17 Apr 2026 07:59:48 +0000

I Built a TikTok Shop Affiliate Finder That Maps Every Creator Promoting a Product in 2 Minutes

TikTok Shop is the most interesting place in ecommerce right now. Products go from zero to 200K sales in a week. The reason is the creator economy: thousands of TikTok accounts run affiliate videos, and the good ones can move inventory faster than any paid ad.

But if you are a seller, an affiliate manager, or just a researcher, one question never gets a clean answer: "Who is actually promoting this product?"

TikTok does not give you an API for that. You have to scroll through the product page, click into videos, click into creator profiles, one by one. An hour of clicking for one product. If you are researching a catalog of 50 products, good luck.

So I built a scraper that does it in two minutes.

Live example

I tested it on a real TikTok Shop product earlier today. A PRETTYGARDEN two-piece lounge set, 205K sales, 4.6 star rating. Here is what came back:

{
  "product": {
    "name": "PRETTYGARDEN Crewneck Two-Piece Set For Women Summer Casual Oversized Split Hem Shirts & Side Pocket Biker Shorts",
    "price": "$33.99",
    "salesCount": "205915",
    "rating": 4.6,
    "url": "https://shop.tiktok.com/view/product/1730228441641554287"
  },
  "affiliates": [
    { "username": "Kay and Tay", "followers": "685.6K" },
    { "username": "Anna Scott", "followers": "176.7K" },
    { "username": "Christina Moceanu Chapman", "followers": "153.5K" },
    { "username": "Kelsey Pumel Woods", "followers": "132.3K" },
    { "username": "stay at sam", "followers": "122.6K" },
    { "username": "Candy Holcombe", "followers": "79.5K" }
  ],
  "qualityState": "verified_success"
}

That took one product URL as input and came back with a ranked creator list in about two minutes. No login, no cookies, no scrolling.

Why TikTok Shop is painful to scrape

If you tried to build this yourself, you would hit three walls in the first hour:

Anti-bot fingerprinting. Naive HTTP requests get blocked instantly. The product page renders behind JS and their bot detection is aggressive. You need a real Chromium with realistic fingerprints.

Dynamic creator blocks. The "videos for this product" section loads through a GraphQL-style API call triggered after scroll. You have to wait for it, capture it, parse it.

Frontend changes. TikTok ships UI updates every couple of weeks. Selectors that worked last month break this month. A reliable scraper needs fallback sources, not just one happy path.

The architecture: multi stage fallback

This is the part that makes it actually work in production.

Product URL
  --> Stage 1: Direct TikTok Shop page via residential proxy + Chromium
      --> Extract product data, scroll to creator block, capture API response
  --> Stage 2 (if Stage 1 blocks): TikTok product detail API fallback
      --> Structured product JSON recovered
  --> Stage 3 (if Stages 1-2 fail): Google SERP snippet extraction
      --> Product name, price, sales recovered from cached pages
  --> Output: structured JSON + qualityState tag

Every result gets a qualityState:

verified_success — product and creators both confirmed from live TikTok
partial_verified — product confirmed, some creator data from cached sources
serp_enriched — product recovered from Google cached pages, creators not available

The quality tag is the part I am most proud of. You always know what you got. No silent data quality drops.

Use cases I did not expect

When I built this I thought it was for dropshippers picking products. Turns out the most interesting users are:

Affiliate managers at agencies. They run it across a client's product catalog to see which creators are already pushing similar products. Instead of cold outreach to random influencers, they recruit creators who have proven they can sell in the category.

Competitor researchers. Someone is winning a niche. You want to know why. Run the scraper on their top three products. You get the exact creator list. You see whose videos are driving the sales.

Freelancers backfilling TikTok Shop research gigs. People charge $200-500 on Upwork for TikTok product research reports. Running the actor is a fraction of that cost. The margin is the point.

Sellers validating before inventory. Before buying 1000 units of a trending product, check if creators are actually running videos for it. If there is no affiliate activity, the sales might be paid ads, not organic.

Try it

The actor runs on Apify. One click deploy, no infrastructure to manage.

TikTok Shop Affiliate Scraper on Apify

Input: product URL or search query. Output: structured JSON with product data and creator list. You pay per verified product returned.

Source code and full README (with Chinese translation for SEA markets):
github.com/the-ai-entrepreneur-ai-hub/tiktok-shop-scraper

Related tools I built

If you found this useful, these might help too:

Influencer Marketing Intelligence finds influencers across Instagram, TikTok, YouTube by name or keyword
Google Maps Lead Intel local business leads with email validation baked in
Email Validator API SMTP check, not just regex

Full catalog: apify.com/george.the.developer

Built this on Apify with Crawlee + Puppeteer. Questions, bugs, or weird TikTok edge cases: @ai_in_it on X.

One API Call to Know Everything About a Company (Domain to Intel)

George Kioko — Thu, 16 Apr 2026 17:15:03 +0000

Your sales team sends you a list of 200 company domains. They want: tech stack, employee count estimate, social profiles, contact emails, and "anything else useful." By tomorrow.

You could open each website manually, run BuiltWith, check LinkedIn, look up WHOIS, verify emails. That is about 10 minutes per company. 200 companies = 33 hours.

Or you could make one API call per domain and get everything back as JSON.

What the API returns

Pass in a domain like stripe.com and get:

Tech stack: React, Next.js, Google Analytics, Vercel. Detected from HTML patterns, meta tags, and response headers. 60+ technologies across CMS, frameworks, analytics, infrastructure, ecommerce, and security.

Social profiles: Twitter, LinkedIn, Facebook, Instagram, GitHub. Extracted from page HTML, not from a database that is 6 months stale.

Contact info: Email addresses found on the site plus phone numbers. Not scraped from a third party. Found on the actual company website.

DNS intelligence: MX records (tells you their email provider: Google Workspace, Microsoft 365, Zoho), SPF/DMARC records (tells you email security posture), A records (tells you hosting).

SEO signals: Title, meta description, H1 tags, canonical URL, OG image. Useful for competitive analysis.

SSL status: Certificate valid, issuer, expiry date.

Real output

{
  "domain": "stripe.com",
  "title": "Stripe | Financial Infrastructure to Grow Your Revenue",
  "technologies": [
    {"name": "react", "category": "framework"},
    {"name": "nextjs", "category": "framework"},
    {"name": "google-analytics", "category": "analytics"},
    {"name": "vercel", "category": "infra"}
  ],
  "socialProfiles": {
    "twitter": "twitter.com/stripe",
    "linkedin": "linkedin.com/company/stripe",
    "facebook": "facebook.com/StripeHQ",
    "instagram": "instagram.com/stripehq",
    "github": "github.com/stripe"
  },
  "emails": ["contact@stripe.com"],
  "mxRecords": [{"exchange": "aspmx.l.google.com", "priority": 10}],
  "ssl": true
}

Cost

$0.01 per domain. Enrich 1,000 companies for $10.

Compare: BuiltWith API starts at $295/month. Clearbit enrichment is $99/month minimum. Hunter.io is $49/month for 500 lookups.

Quick start

from apify_client import ApifyClient

client = ApifyClient("YOUR_TOKEN")
run = client.actor("george.the.developer/company-enrichment-api").call(
    run_input={"domain": "stripe.com"}
)

result = client.dataset(run["defaultDatasetId"]).list_items().items[0]
print(f"Tech: {[t['name'] for t in result['technologies']]}")
print(f"Social: {list(result['socialProfiles'].keys())}")
print(f"Emails: {result['emails']}")

Also available on RapidAPI with a free tier: https://rapidapi.com/georgethedeveloper3046

I build data tools. 57 actors on Apify Store, 869 users. @ai_in_it on X.

TikTok Shop Affiliate Intelligence: Find Who Promotes Any Product

George Kioko — Thu, 16 Apr 2026 17:07:31 +0000

TikTok Shop is a $20 billion marketplace and growing. Sellers, agencies, and affiliate managers all need to answer the same question: who is actually promoting this product, and is it working?

There is no public dashboard for this. TikTok Shop does not expose affiliate data through any official API. The seller center shows you your own affiliates, not your competitors. So everyone does manual research, scrolling through product pages and creator profiles for hours.

I built a tool that automates this entire process.

What it does

Give it a TikTok Shop product URL. It returns:

Verified product details (name, price, sales count, rating)
Which creators are actively promoting it
Each creator's follower count and profile URL
Whether the data is verified from live sources or recovered from cached data

The output is structured JSON that you can plug into spreadsheets, dashboards, or CRM tools.

Why this matters for sellers

Before you launch a product or invest in inventory, you want to know if similar products already have affiliate momentum. If 10 creators with 500K+ followers are pushing a competitor product and it has 50K sales, that tells you there is demand and a distribution channel.

If nobody is promoting similar products, either you found a gap or the category does not sell on TikTok Shop. Either way, the data saves you from guessing.

Why agencies care

If you manage creator partnerships for brands, you need to know who is already driving sales in a category. Those creators have proven they can convert TikTok traffic into purchases. Recruiting a creator who already sells skincare is cheaper and faster than finding someone who might.

The freelancer angle

This is where the math gets interesting. There are gigs on Upwork and Fiverr where clients pay $200 to $500 for "TikTok Shop product research" or "find affiliates for my product." The deliverable is a report showing which products are winning and who promotes them.

Running this actor on 20 products costs about $1. Formatting the output into a report takes 20 minutes. The margin is 99%.

How to use it

Direct product URL

{
  "productUrl": "https://www.tiktok.com/view/product/1234567890"
}

Search by keyword

{
  "searchQuery": "vitamin c serum",
  "maxProducts": 10
}

Python

from apify_client import ApifyClient

client = ApifyClient("YOUR_TOKEN")
run = client.actor("george.the.developer/tiktok-shop-affiliate-sales-scraper").call(
    run_input={"productUrl": "https://www.tiktok.com/view/product/1234567890"}
)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(f"Product: {item['product']['name']}")
    for a in item.get('affiliates', []):
        print(f"  @{a['username']} ({a['followers']} followers)")

Pricing

$0.05 per product analyzed. Check 20 products for $1. No monthly subscription.

Free tier available on Apify. Try it at: https://apify.com/george.the.developer/tiktok-shop-affiliate-sales-scraper

33 users already use this. Follow the build log at @ai_in_it on X.

How to Build a RAG Pipeline from YouTube Videos (Without an API)

George Kioko — Thu, 16 Apr 2026 06:43:05 +0000

If you validate emails with regex, you are checking if a string looks like an email. You are not checking if anyone will receive your message.

I learned this the hard way. 12% bounce rate on a 5,000 email campaign. Sender reputation tanked. Half the "valid" emails were dead mailboxes that regex happily approved.

here is what actually works and why the difference matters.

What regex checks

/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/

This tells you the string has an @ symbol, a dot, and some characters around them. That is it.

totally.fake.person@nonexistent-domain-12345.com passes regex. Nobody will ever receive that email.

What SMTP verification checks

SMTP verification actually talks to the mail server. It connects on port 25, introduces itself with EHLO, then asks "would you accept mail for this address?" The server responds with a code:

250 = yes, this mailbox exists
550 = no, user unknown
252 = catch all (accepts everything)

This is the same protocol your email client uses to send mail. You are just stopping before actually delivering anything.

The 5 layers of real validation

I built an email validator that runs 5 checks in sequence:

Layer 1: Format check. Yes, regex. But just as a first filter to reject obvious garbage.

Layer 2: Domain check. Does the domain have MX records? If there are no mail servers configured, nobody is receiving email there. dig MX example.com tells you instantly.

Layer 3: Disposable detection. Is this mailinator, guerrillamail, tempmail? I maintain a list of 400+ disposable domains. These addresses work for about 10 minutes then disappear.

Layer 4: Role detection. admin@, info@, support@ are role addresses. They usually go to a shared inbox that nobody monitors for cold outreach.

Layer 5: SMTP handshake. The real check. Connect to the MX server, ask if the mailbox exists. This catches the dead addresses that everything else misses.

What this looks like in practice

Input: hello@stripe.com

{
  "email": "hello@stripe.com",
  "valid": true,
  "format_valid": true,
  "mx_found": true,
  "smtp_check": "valid",
  "is_disposable": false,
  "is_free": false,
  "is_role_based": false,
  "domain": "stripe.com",
  "mx_records": [
    {"priority": 10, "exchange": "aspmx.l.google.com"}
  ],
  "score": 100
}

Input: test@mailinator.com

{
  "email": "test@mailinator.com",
  "valid": false,
  "format_valid": true,
  "mx_found": true,
  "smtp_check": null,
  "is_disposable": true,
  "score": 40,
  "reason": "Disposable email address"
}

The disposable check caught it before we even bothered with SMTP.

The bounce rate difference

Before SMTP validation: 12% bounce rate, emails landing in spam, sender score dropping.

After: under 2% bounce rate. Same email copy, same sending infrastructure. The only change was filtering out dead addresses before hitting send.

Cost comparison

Method	Cost per 1,000 emails	Accuracy
Regex only	Free	~60% (misses dead mailboxes)
ZeroBounce	$1.60	~95%
Hunter.io	$3.00	~93%
NeverBounce	$3.00	~96%
This API	$2.00	~98% (real SMTP)

Try it

The validator is on Apify Store with a free tier: Email Validator API

Also available on RapidAPI if you prefer REST.

Python quickstart

from apify_client import ApifyClient

client = ApifyClient("YOUR_TOKEN")
run = client.actor("george.the.developer/email-validator-api").call(
    run_input={"email": "hello@stripe.com"}
)

result = client.dataset(run["defaultDatasetId"]).list_items().items[0]
print(f"Valid: {result['valid']}, Score: {result['score']}")

curl

curl "https://george-the-developer--email-validator-api.apify.actor/validate?email=hello@stripe.com" \
  -H "Authorization: Bearer YOUR_TOKEN"

I build data tools. 57 actors on Apify Store, 869 users. Follow the build log at @ai_in_it on X.

Why Regex Email Validation Is Lying to You (And What Actually Works)

George Kioko — Wed, 15 Apr 2026 09:34:37 +0000

If you validate emails with regex, you are checking if a string looks like an email. You are not checking if anyone will receive your message.

I learned this the hard way. 12% bounce rate on a 5,000 email campaign. Sender reputation tanked. Half the "valid" emails were dead mailboxes that regex happily approved.

here is what actually works and why the difference matters.

What regex checks

/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/

This tells you the string has an @ symbol, a dot, and some characters around them. That is it.

totally.fake.person@nonexistent-domain-12345.com passes regex. Nobody will ever receive that email.

What SMTP verification checks

SMTP verification actually talks to the mail server. It connects on port 25, introduces itself with EHLO, then asks "would you accept mail for this address?" The server responds with a code:

250 = yes, this mailbox exists
550 = no, user unknown
252 = catch all (accepts everything)

This is the same protocol your email client uses to send mail. You are just stopping before actually delivering anything.

The 5 layers of real validation

I built an email validator that runs 5 checks in sequence:

Layer 1: Format check. Yes, regex. But just as a first filter to reject obvious garbage.

Layer 2: Domain check. Does the domain have MX records? If there are no mail servers configured, nobody is receiving email there. dig MX example.com tells you instantly.

Layer 3: Disposable detection. Is this mailinator, guerrillamail, tempmail? I maintain a list of 400+ disposable domains. These addresses work for about 10 minutes then disappear.

Layer 4: Role detection. admin@, info@, support@ are role addresses. They usually go to a shared inbox that nobody monitors for cold outreach.

Layer 5: SMTP handshake. The real check. Connect to the MX server, ask if the mailbox exists. This catches the dead addresses that everything else misses.

What this looks like in practice

Input: hello@stripe.com

{
  "email": "hello@stripe.com",
  "valid": true,
  "format_valid": true,
  "mx_found": true,
  "smtp_check": "valid",
  "is_disposable": false,
  "is_free": false,
  "is_role_based": false,
  "domain": "stripe.com",
  "mx_records": [
    {"priority": 10, "exchange": "aspmx.l.google.com"}
  ],
  "score": 100
}

Input: test@mailinator.com

{
  "email": "test@mailinator.com",
  "valid": false,
  "format_valid": true,
  "mx_found": true,
  "smtp_check": null,
  "is_disposable": true,
  "score": 40,
  "reason": "Disposable email address"
}

The disposable check caught it before we even bothered with SMTP.

The bounce rate difference

Before SMTP validation: 12% bounce rate, emails landing in spam, sender score dropping.

After: under 2% bounce rate. Same email copy, same sending infrastructure. The only change was filtering out dead addresses before hitting send.

Cost comparison

Method	Cost per 1,000 emails	Accuracy
Regex only	Free	~60% (misses dead mailboxes)
ZeroBounce	$1.60	~95%
Hunter.io	$3.00	~93%
NeverBounce	$3.00	~96%
This API	$2.00	~98% (real SMTP)

Try it

The validator is on Apify Store with a free tier: Email Validator API

Also available on RapidAPI if you prefer REST.

Python quickstart

from apify_client import ApifyClient

client = ApifyClient("YOUR_TOKEN")
run = client.actor("george.the.developer/email-validator-api").call(
    run_input={"email": "hello@stripe.com"}
)

result = client.dataset(run["defaultDatasetId"]).list_items().items[0]
print(f"Valid: {result['valid']}, Score: {result['score']}")

curl

curl "https://george-the-developer--email-validator-api.apify.actor/validate?email=hello@stripe.com" \
  -H "Authorization: Bearer YOUR_TOKEN"

I build data tools. 57 actors on Apify Store, 869 users. Follow the build log at @ai_in_it on X.