Forem: George Kioko

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.

I Built an AI Powered Influencer Finder That Costs Almost Nothing to Run

George Kioko — Wed, 15 Apr 2026 02:59:48 +0000

Most influencer discovery tools charge $200-500/month. I built one that costs me cheap to run and finds real influencer profiles with names, follower counts, bios, and emails across Instagram, TikTok, and YouTube.

Here's exactly how it works, what broke along the way, and the architecture that finally made it reliable.

The Problem

A brand asked me to find 50 fitness micro-influencers on Instagram with contact info. The options were:

Upfluence: $478/month minimum
Modash: $299/month
Manual research: 3 hours on Instagram, copy-pasting into a spreadsheet

I figured I could automate this for pennies.

The Architecture (What Actually Works)

After three failed approaches, here's what stuck:

Google SERP search (via Apify GOOGLE_SERP proxy)
  -> Extract social profile URLs from search results
    -> HTTP fetch each profile (via Apify residential proxy + Googlebot UA)
      -> Parse OG meta tags for real names, follower counts, bios
        -> Output structured data

The key insight: you don't need to render Instagram pages in a browser. Instagram serves complete Open Graph meta tags to Googlebot. A simple HTTP GET with the right User-Agent through a residential proxy returns everything you need.

For example, fetching https://www.instagram.com/kayla_itsines/ with a Googlebot header returns:

og:title: "KAYLA ITSINES (@kayla_itsines). Instagram photos and videos"
og:description: "16M Followers, 845 Following, 8,977 Posts"

Real name, follower count, post count. No browser. No login. No CAPTCHA.

What Broke (And How I Fixed It)

Attempt 1: Puppeteer + Apify Proxy

Used PuppeteerCrawler to search Google and visit profiles. Google CAPTCHA'd me. Instagram detected headless Chrome. Got 0 results.

Attempt 2: crawl4ai on VPS (direct IP)

Deployed crawl4ai (real Chromium) on a cheap Contabo VPS. Worked for normal sites but Google and Instagram both blocked the datacenter IP. 0 results again.

Attempt 3: crawl4ai + Apify proxy pipeline

The fix: route crawl4ai's browser traffic through Apify's proxy pool.

Google searches go through GOOGLE_SERP proxy group (designed for Google)
Instagram profile fetches go through RESIDENTIAL proxy group (residential IPs)
Use a lightweight HTTP fetch endpoint (no browser needed for profile pages)

This is what finally worked consistently.

The Gemma 4 Enhancement

The VPS also runs Google's Gemma 4 (2B parameter model) via Ollama. When the regex-based profile extraction from SERP results misses something, Gemma acts as an intelligent fallback:

"Given these Google search results, extract all Instagram profile URLs, 
usernames, display names, and follower counts. Return JSON."

With think: false (disabling chain-of-thought reasoning), Gemma responds in 3-5 seconds instead of 60. For simple classification tasks, the thinking overhead isn't worth it.

Real Results

Running "beauty" niche on Instagram, 5 results requested:

Username	Real Name	Followers	Source
@mikaylajmakeup	Mikayla Jane Nogueira	3M	og_meta_enriched
@ericataylor2347	Erica Taylor	2M	og_meta_enriched
@darcybylauren	lauren janelle	189K	og_meta_enriched
@amandaensing	Amanda Ensing	1M	og_meta_enriched
@jamiegenevieve	Jamie Genevieve	1M	og_meta_enriched

All real names (not just handles), all real follower counts, all in about 2 minutes.

Cost Breakdown

Component	Monthly Cost
Contabo VPS (6 vCPU, 12GB RAM)	Under $15
Apify Creator Plan	$1
Apify proxy usage	~$2-5 per 1000 searches
Total	~$11-14/month

Compare that to $200-500/month for commercial influencer tools.

The Code

The full source is on GitHub: influencer-marketing-intel

Or try it directly on Apify (no code needed): Influencer Marketing Intelligence

Input:

{
  "niche": "beauty",
  "platforms": ["instagram", "tiktok", "youtube"],
  "maxResults": 50,
  "followerRange": "micro_10k_100k"
}

Output: structured JSON with username, displayName, estimatedFollowers, bio, contactEmails, nicheTags, profileUrl for each influencer found.

What I'd Do Differently

Start with the OG meta approach from day one. I wasted weeks trying to make Puppeteer work on Instagram. The Googlebot UA trick was the breakthrough.
Don't fight anti-bot systems, route around them. Residential proxies cost pennies and save hours of debugging.
Local LLMs for extraction are underrated. Gemma 4 on a VPS replaces brittle regex patterns. When Instagram changes their HTML structure, Gemma adapts. Regex doesn't.

I build scraping tools 57 actors on Apify Store, 869 users. If you have a data problem that needs automating, I probably already built the tool.

Follow the build log: @ai_in_it on X

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

George Kioko — Tue, 14 Apr 2026 07:38:09 +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.

Why Local Lead Gen Agencies Are Paying $39 Per Google Maps Search (And Getting 10x ROI)

George Kioko — Tue, 14 Apr 2026 01:10:47 +0000

If you run a local lead gen agency, you already know the grind. Client says "find me 200 plumbers in Phoenix." You open Google Maps, start scrolling, copying names into a spreadsheet, checking websites, hunting for emails. Four hours later you have maybe 80 results and half the emails bounce.

That's the old way. Here's why agencies are switching to a single API call instead.

The Manual Research Problem

A typical local business research session looks like this:

Search Google Maps for the category and city
Click each result, grab the name, phone, address
Visit the website to find an email
Check if the business is actually active
Score the lead based on reviews, website quality, ad presence

For one city and one category, that's 3 to 4 hours of work. If your client wants 10 cities, you're looking at a full work week just on data collection. Most agencies hire VAs at $15 to $25/hour for this, which means $200+ per market.

What One API Call Returns

I built Google Maps Lead Intel specifically for agencies who need this data fast. You pass in a search query like "dentist Phoenix AZ" and it returns:

Business name, address, phone, website
Email addresses (validated, not guessed)
Google rating and review count
Whether they run Google Ads
Website tech stack and CMS
Social media profiles
A lead score based on online presence signals

One call. 90 seconds. $39 per search area.

The Math That Makes Agencies Switch

Here's the comparison that keeps coming up in conversations with users:

Method	Cost per market	Time	Data quality
Manual VA research	$200+	4 hours	Inconsistent
Google Maps Lead Intel	$39	90 seconds	Validated emails, scored leads

That's an 80% cost reduction and you get better data. The validated emails alone save you from bounce rate problems that kill sender reputation.

Who Actually Uses This

Two agencies using Google Maps Lead Intel right now generate about $540/month between them on the platform. One runs it for appointment setting clients across 15 metro areas. The other uses it for local SEO audits where they need to show clients their competitive landscape.

The pattern is the same: client pays $500 to $2,000/month for lead gen services, agency spends $39 per market on data, and the rest is margin.

Why $39 Is Actually Cheap

Think about what you're replacing:

No VA training or management
No spreadsheet cleanup
No email verification tools (already validated)
No waiting 4 hours per market
No inconsistent data formats

A VA doing this work costs $200+ per market. Even a junior employee at $20/hour spends 4 hours minimum, which is $80 before overhead. At $39 you're getting enriched, validated, scored data in 90 seconds.

Real Use Cases From Current Users

Appointment setting agencies run it for every new client market. Dentists, chiropractors, HVAC, plumbers. They load the results directly into their CRM and start outreach the same day.

Local SEO companies use it to build competitive analyses. "Here are the 50 businesses ranking for your keyword, here's their review count, here's who runs ads." That report alone justifies a $1,000 monthly retainer.

Commercial real estate teams pull business data for tenant prospecting. They need to know who operates in specific areas, what their online presence looks like, and how to reach them.

Getting Started

The actor runs on Apify. You can test it from the Apify Store page with any search query. Results come back as structured JSON that drops straight into any CRM, spreadsheet, or automation tool.

If you're spending more than 2 hours per week on manual Google Maps research, this pays for itself on the first run.

Try it: Google Maps Lead Intel on Apify Store

Built in Nairobi. 48 actors in production, 869 users, $211 revenue last month. Questions? Drop them below.

From 0 to 1,092 Visitors and 419 Actor Starts: What I Learned Building 53 APIs

George Kioko — Mon, 13 Apr 2026 10:46:16 +0000

Last month, 1,092 people visited my Apify Store page. 281 of them clicked through to an actor's input page. 419 hit the Start button and actually ran something. Those numbers are small by SaaS standards. But for a solo developer in Nairobi who did not know JavaScript 4 months ago, they represent something real.

Here is what I learned watching that funnel take shape.

The Funnel Nobody Tells You About

Apify gives you analytics on every actor. The flow looks like this:

1,092 page views. 281 input page views. 419 actor starts.

That last number being higher than input page views confused me at first. It happens because returning users skip the description page and go straight to the input form. Repeat usage matters more than first impressions. Some users run a single actor 200+ times. One person ran my WHOIS lookup 262 times in a month.

The lesson? Retention is baked into the product, not the marketing. If the tool works well on the first run, they come back without being asked.

Where Traffic Actually Comes From

I expected Twitter and dev.to articles to drive most of my growth. I was wrong.

69% of my traffic comes from Apify Store search. People type "google scholar scraper" or "email validator" into the Apify marketplace and find my tools. This is basically app store SEO. The actors with the best README files, clear titles, and specific keywords rank higher.

12% comes from Google. Those same README files index on Google, so people searching for niche data problems land on my actors directly. Two of my actors rank on the first page for their target keywords.

8% comes from the Apify Console, meaning existing users discover new actors while browsing their dashboard.

The remaining 11% is social media, articles, and direct links. All that tweeting and article writing moves the needle, but not as much as writing a good README.

The China and Singapore Surprise

39% of my traffic comes from China and Singapore. I built every actor assuming my users would be in the US and Europe. Completely wrong.

It makes sense in hindsight. Developers and data teams in Asia need the same tools. English language documentation works globally. And the Apify Store does not have geographic barriers.

This changed how I think about naming and descriptions. I stopped using US specific references and started writing for a global audience. Small shift, big impact on discoverability.

From Scrapers to Solutions

My early actors had names like "LinkedIn Employee Scraper" and "YouTube Transcript Extractor." They worked fine but competed with dozens of free alternatives.

The actors that grew fastest were the ones I repositioned as solutions. "Google Maps Lead Intel" instead of "Google Maps Scraper." "Entity OSINT Analyzer" instead of "Entity Search." "Competitor Intelligence" instead of "LinkedIn Comparison Tool."

Same code underneath. Different framing. The solution named actors attract buyers. The scraper named actors attract tire kickers who want everything free.

The Power User Pattern

Most users try an actor once. Maybe twice. Then they leave. But a small group of users runs the same actor hundreds of times. These are the users who pay for everything.

My WHOIS lookup has one user with 262 runs. Google Scholar has someone at 230. AI Content Detector at 132. These power users are building automated pipelines that call my actors on a schedule or in bulk.

The business model only works because of them. Optimizing for power users (faster response times, better error handling, higher rate limits) matters more than converting first time visitors.

What I Would Do Differently

I wasted time on Reddit (got banned from r/webscraping for posting too aggressively), cold DMs (zero conversions), and Discord communities (untrackable results).

If I started over today, I would spend 80% of my time writing great README files with clear keywords and 20% writing technical articles on dev.to and Hashnode. Everything else is noise.

53 actors. 869 users. 1,092 page views. Built solo from Nairobi.

The tools that grow are the ones that solve a specific problem well and show up when someone searches for that problem. That is the entire playbook.

I build data APIs and scrapers on the Apify Store. If you need structured data from any website, check out my portfolio: george.the.developer on Apify

Two APIs I Built This Week That Cost Nothing to Run

George Kioko — Sun, 12 Apr 2026 23:25:33 +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.

I Built a Tool That Shows Why Your Competitor's LinkedIn Posts Win

George Kioko — Sun, 12 Apr 2026 23:23:56 +0000

You post on LinkedIn three times a week. Your competitor posts twice. They get 3x your engagement. Why?

I kept asking myself this question and never had a real answer beyond "their content is better." That's not useful. I wanted specifics. What topics are they covering that I'm not? What formats are they using? What posting patterns work for them?

So I built a tool that runs the comparison automatically.

The problem nobody talks about

Most LinkedIn "strategy" advice is generic. Post more videos. Use carousels. Write hooks. But that advice ignores the most important variable: your specific niche, your specific audience, your specific competitors.

What works for a SaaS founder posting about product updates is completely different from what works for a recruiter sharing hiring tips. You need data from your actual competitive set, not broad averages.

What the tool actually does

You give it two LinkedIn company or creator URLs. It pulls recent posts from both accounts and runs a side by side analysis:

Topic gap analysis: What themes does your competitor cover that you never touch? Maybe they post about industry news every Monday and get solid engagement, while you only post product updates.

Format comparison: Are they using video, carousels, text posts, polls? The tool breaks down the format mix for both accounts and shows where the gaps are.

Engagement benchmarks: Average likes, comments, and shares per post type. Not vanity metrics but actionable patterns like "their video posts get 2.3x the engagement of their text posts."

Posting cadence: When do they post? How often? Is there a pattern to their highest performing content?

Real output example

I tested it on two fintech companies. Here's what came back:

TechCorp vs YourBrand — 30 day comparison

TechCorp: 100% video content, avg 847 reactions/post
YourBrand: 85% text, 15% carousel, avg 312 reactions/post

Topic gaps you're missing:
  - Industry commentary (TechCorp: 40% of posts, you: 0%)
  - Customer stories (TechCorp: 25% of posts, you: 5%)

Recommendation: Test 2 video posts/week covering
industry news. TechCorp's video format gets 2.3x
higher engagement than their own text posts.

That's specific enough to actually change your content calendar.

How it works under the hood

The actor uses Crawlee with Playwright to visit LinkedIn pages and extract post data. No API key needed, no Sales Navigator subscription. It runs on Apify's cloud infrastructure so you don't need to manage servers or proxies.

The analysis logic compares engagement distributions, runs basic NLP for topic categorization, and generates the recommendations based on statistical gaps between the two accounts.

Pricing

$0.02 per comparison report. Run it weekly on your top 3 competitors and you're spending about $2.40/month for ongoing competitive intelligence. Compare that to social listening tools charging $200+/month.

Try it on Apify: LinkedIn Competitor Intelligence

The first run takes about 60 seconds. You'll know exactly what to change before your next LinkedIn post.

Built in Nairobi. 52 actors in production, 746+ users. Questions welcome in the comments.

I Built a TikTok Shop Product Finder That 30 People Actually Use

George Kioko — Sat, 11 Apr 2026 15:39:59 +0000

Six months ago I started building scrapers on Apify as a solo developer. Most of them got 2 or 3 users and collected dust. But the TikTok Shop scraper hit different. It now has about 30 active users and nearly 300 runs, which makes it one of my most popular tools.

Here is the story of why I built it and what I learned.

The Dropshipping Problem

If you are in ecommerce or dropshipping, you have probably noticed TikTok Shop is where the action moved. Products go viral on TikTok and sell thousands of units before they even appear on Amazon. The affiliate program is printing money for creators who pick the right products early.

But finding those trending products is a nightmare. TikTok does not have a public product API. Their website renders everything dynamically with heavy JavaScript. Traditional scraping tools break constantly because TikTok changes their frontend every few weeks.

Most dropshippers end up scrolling TikTok manually for hours, screenshotting products, and hoping they picked a winner. That felt like a problem worth solving.

What the Scraper Does

The TikTok Shop Scraper lets you search TikTok Shop by keyword or category and pulls back structured product data: titles, prices, ratings, review counts, seller info, and product URLs.

You type in "kitchen gadgets" or "phone accessories" and get back a clean JSON dataset of what is actually selling on TikTok Shop right now. No manual scrolling. No screenshots. No guessing.

The real value is in the numbers. When you can see that a specific garlic press has 4,200 reviews and a 4.8 star rating, you know it is moving units. Compare that to scrolling past it in a TikTok video and thinking "that looks popular, maybe."

Why TikTok Shop Data Is Hard to Get

I will not pretend this was easy to build. TikTok is one of the hardest sites to scrape on the internet. Here is what makes it painful:

Anti bot detection: TikTok runs aggressive fingerprinting. Simple HTTP requests get blocked instantly. You need a full browser with realistic behavior patterns.

Dynamic rendering: Product listings load through multiple API calls triggered by scroll events. You cannot just fetch the HTML and parse it.

Frequent changes: TikTok updates their frontend regularly. Selectors that worked last week break this week. I have had to push fixes multiple times just to keep up.

Rate limiting: Hit them too fast and you get IP banned. The scraper uses smart proxy rotation and request throttling to stay under the radar.

Building on Crawlee with Puppeteer handles most of this. The Apify platform provides the proxy infrastructure and browser management. But it still requires constant maintenance whenever TikTok ships a new update.

What 30 Users Taught Me

The users break down into three groups:

Dropshippers (the majority) use it to find trending products before they saturate. They run searches weekly across 10 to 15 categories and look for products with high review counts but low competition on Amazon or Shopify.

TikTok affiliates use it to find products with active affiliate programs. If a product has good reviews and a decent commission rate, they create content around it.

Market researchers use it less frequently but in bigger batches. They pull data across entire categories to spot trends for brands or agencies.

The most common feedback: "I used to spend 3 hours scrolling TikTok looking for products. Now I spend 10 minutes looking at the data."

The Numbers

The scraper is still private (TikTok scrapers live in a gray area that makes me cautious about going fully public), but through the Apify Store it has organically attracted about 30 users and logged 294 runs.

For context, that puts it in my top 4 actors by usage, behind only LinkedIn (623 runs), YouTube (327 runs), and CoinMarketCap (239 runs).

I did zero marketing for it. People find it by searching the Apify Store for "tiktok shop" and there is almost nothing else there.

What I Would Tell New Builder

If you are thinking about building scrapers or APIs, find the platform that everyone wants data from but nobody has built tools for yet. TikTok Shop was that for me. The demand was already there. I just had to show up.

The product does not need to be perfect. It needs to solve a real problem that people are currently solving manually. Thirty users is not a massive number, but every one of them found me organically because the alternative was wasting hours on manual research.

You can check it out on the Apify Store. If you are in the dropshipping or TikTok affiliate space, it might save you some serious time.

OFAC Sanctions Screening for $0.01 Per Entity (No Enterprise Contract)

George Kioko — Sat, 11 Apr 2026 15:39:26 +0000

If you work in compliance, you already know the pain. Sanctions screening tools from the big vendors cost $10,000 to $50,000 per year. They require sales calls, procurement cycles, and a six month onboarding process before you can check a single name against the SDN list.

I built an API that does it for a penny per entity. No contracts. No minimums. No sales demo.

What It Actually Checks

The OFAC Sanctions Checker queries three major sanctions databases in a single call:

US OFAC SDN List (Specially Designated Nationals) from the Treasury Department
EU Consolidated Sanctions List from the European Commission
UN Security Council Sanctions from the United Nations

You send a name (person or company), and it returns matches with confidence scores, match types, and the specific list where the hit was found. Fuzzy matching is included, so "Vladimir Putin" catches variations like "V. Putin" or transliterated spellings.

Why This Matters Right Now

Fintechs, crypto exchanges, and trade compliance teams all face the same problem: they need sanctions screening, but they are too small for Oracle or Dow Jones pricing. The regulatory pressure is real though. OFAC fines start at $50,000 per violation and go up to $20 million. The EU is equally aggressive.

If you are a 10 person fintech processing cross border payments, you cannot skip screening. But you also cannot justify $30K/year for a tool you might query 500 times a month.

At $0.01 per entity, 500 monthly checks costs you $5.

How It Works in Practice

const response = await fetch(
  'https://api.apify.com/v2/acts/george.the.developer~ofac-sanctions-checker/run-sync-get-dataset-items',
  {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': 'Bearer YOUR_TOKEN'
    },
    body: JSON.stringify({
      entityName: "Acme Trading LLC",
      entityType: "company",
      checkLists: ["SDN", "EU", "UN"]
    })
  }
);

const results = await response.json();
// Returns: matches, confidence scores, list sources

Drop that into your KYC onboarding flow, your payment processing pipeline, or your trade compliance checks. Each call takes a few seconds and costs a penny.

Who Is Using This

Two users are running it consistently right now, mostly in trade compliance workflows. The typical pattern is batch screening: uploading a list of counterparties before processing a shipment or wire transfer.

One user runs it as part of a daily cron job, checking new customers against all three lists overnight. At their volume (roughly 200 entities per day), they are spending about $60 a month instead of $30,000 a year.

The Compliance Gap Nobody Talks About

There are thousands of small businesses that should be screening but are not. Import/export companies, money service businesses, crypto OTC desks, even law firms doing cross border transactions. They skip it because the enterprise tools are priced for banks with 10,000 employees.

That is a real risk. OFAC enforcement does not care about your company size. The fines hit a 5 person MSB the same way they hit JPMorgan.

A penny per check removes the excuse.

Try It

The API is live on the Apify Store. You can test it without a credit card. Pay per event pricing means you only get charged for actual checks, not seats or subscriptions.

If you are building compliance tooling or running a fintech that needs sanctions screening without the enterprise markup, give it a shot. The worst case is you spend a dollar testing it.

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

George Kioko — Sat, 11 Apr 2026 06:07:17 +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 — Fri, 10 Apr 2026 17:53:24 +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.