DEV Community: Wei Bin

I mapped a YouTube channel's entire catalog in two runs — for under a cent

Wei Bin — Sun, 15 Nov 2026 08:09:40 +0000

Competitor research on YouTube usually dies in one of two places: you click through forty videos by hand and give up, or you start writing a scraper and give up slightly later, somewhere around the third rate-limit.

I needed a channel's full catalog — titles, URLs, and the view numbers that show which topics actually land — for a content teardown. Instead of building anything, I ran two existing tools back to back. Total elapsed time: under a minute. Total compute cost: less than a cent. Here's the exact pattern, with the real output.

Step 1: Enumerate the catalog (fast, cheap, deliberately shallow)

The first run takes a channel handle and returns its video catalog as structured rows. I pointed it at @OpenAI with a 30-video cap:

Wall time: about 7 seconds
Rows back: 30
Compute cost: $0.001

Each row carries the skeleton: videoId, title, url, channel name and channel ID. What it deliberately does not carry: view counts, durations, publish dates. Those fields come back null, and that's a design choice worth understanding — enumerating a catalog and enriching a catalog are different jobs with different costs. The enumeration pass is built to be nearly free, so you can afford to run it on every competitor you have.

Step 2: Enrich only what you'll actually read

From the 30 rows, I fed 3 video URLs into the companion details tool. Now the expensive fields show up:

Video	Views	Duration	Likes
How Mozilla uses GPT-6 Cyber to find and fix Firefox vulnerabilities	14,565	20:19	160
Cyber at the Frontier: Introducing Daybreak Red Team & Daybreak Defense Factory	51,193	34:36	—
What Codex Unlocks for Holiday Extras	6,772	2:26	70

Wall time: seconds
Compute cost: $0.0024 for the 3 videos

Notice the honest gaps: one row came back without a like count. Per-video enrichment reads public pages one by one, and public pages don't always expose every counter. A tool that returns a confident number for every field on every video is inventing some of them; I'd rather get a null I can see.

Why the two-step split matters

If you enrich inline during enumeration, a 500-video channel costs 500 detail fetches before you know whether you care about 490 of them. Split the steps and the economics flip:

Enumerate everything — pennies, seconds. Now you have the full topic map: what they publish, how often, how they title.
Sort and filter locally — by title keywords, by series, by recency.
Enrich the shortlist — pay the per-video cost only for the rows that will actually feed a decision.

The same pattern works for TikTok profiles, playlists and search results — enumerate wide and cheap, enrich narrow and deep. It's also how I'd advise evaluating any data tool: ask what the enumeration pass costs before you ask what the detail pass returns.

Running it yourself

Both tools are public Apify actors, no code required — paste a channel handle, set a cap, download JSON or CSV:

Channel catalog: https://apify.com/bin_ai_tools/youtube-channel-videos
Video details: https://apify.com/bin_ai_tools/youtube-video-details

If you'd rather automate it, both run through the Apify API with the same inputs, so the two-step pattern drops straight into a script or a scheduled job — a weekly competitor-catalog diff is about twenty lines.

The teardown I built on top of this took an afternoon. The data collection took a minute. That ratio is the whole point: the analysis is the work; the gathering shouldn't be.

How to track a live flight with one API call (real ADS-B data, no enterprise feed)

Wei Bin — Sun, 15 Nov 2026 08:00:14 +0000

Every side project that touches flight data hits the same wall: the well-known flight data feeds are priced for airlines and enterprises, and the "free" tiers are either schedule data dressed up as live, or demos that die the moment you ship.

I wanted actual live positions — where is this aircraft, right now — for a tracker widget I was building. So I built FlightScope on top of the open ADS-B receiver network (adsb.lol) plus the OurAirports and OpenFlights datasets, and I've been running it as a public API since. This post is a walkthrough of what the data really looks like, with responses I captured live while writing it.

One call: the complete live profile of a flight

Give the API a flight number — IATA (TS655) or ICAO (TSC655) form both work — and you get the operator, the aircraft, and its live position in a single response:

{
  "flight": { "iata": "TS655", "callsign": "TSC655",
    "airline": { "name": "Air Transat", "iata": "TS", "icao": "TSC" } },
  "aircraft": { "icao24": "c051d1", "registration": "C-GEZO", "typeCode": "A321" },
  "live": { "latitude": 40.889648, "longitude": -73.986694,
    "altitudeFt": 35025, "groundSpeedKt": 464.3, "trackDeg": 19.76,
    "verticalRateFpm": 128, "onGround": false, "phase": "airborne",
    "squawk": "6166", "lastSeenSecondsAgo": 0 },
  "ageSeconds": 0
}

That's an Air Transat A321 at 35,025 ft doing 464 knots over New Jersey, climbing gently at 128 feet per minute, captured the second I asked. The fields worth noticing:

lastSeenSecondsAgo / ageSeconds — ADS-B data is only honest if it tells you how old it is. Every live response carries its freshness, and positions served from the short edge cache say so. A tracker that hides this is showing you a plane that may have landed ten minutes ago.
phase — ground vs airborne, derived from the broadcast itself (the barometric altitude field), and labelled as derived in the full response. It is not the airline's official status, and the API says that in the payload rather than in fine print.

"What's flying over me right now?"

The endpoint I end up demoing most is the radius query. One call over JFK (40.6413, −73.7781, 80 km radius) came back with 30 aircraft — callsigns, types, altitudes, speeds, ground flags — everything you need to draw a live map:

GET /flights/near?lat=40.6413&lon=-73.7781&radiusKm=80
→ { "count": 30, "flights": [ { "callsign": "TSC655", "typeCode": "A321",
    "altitudeFt": 35025, "groundSpeedKt": 464.3, "onGround": false }, … ] }

No polling a firehose, no WebSocket plumbing — a stateless GET you can call from a cron job, a Cloudflare Worker, or a browser.

The batch trick: 100 flights, one call

If you're building a fleet board or a multi-flight tracker, per-flight polling burns quota fast. The batch endpoint takes up to 100 flight numbers in one POST and returns one result per flight plus a summary — and the whole batch counts as one call against your quota:

curl -X POST "https://flightscope-live-flight-tracking-and-airport-data-api.p.rapidapi.com/flights/batch" \
  -H "X-RapidAPI-Key: YOUR_KEY" -H "Content-Type: application/json" \
  -d '{"flights": ["TS655", "AAL751", "DL123"]}'

That pricing-of-attention detail — batch = 1 call — is deliberate. I'd rather you build the dashboard than ration refreshes.

Airports without a second API

Trackers always end up needing airport context too, so the same API carries profiles for 3,270 commercial airports from OurAirports (public domain): codes, coordinates, elevation, municipality, and links. GET /airport/KJFK returns John F. Kennedy International with its IATA/ICAO codes, position and elevation in the same response shape as everything else. There's also /airports/search for name/city/code lookup and /aircraft/{icao24} for looking an airframe up by transponder hex.

The honest limits of ADS-B

Three things this kind of data cannot do, which I learned to state up front because users discover them anyway:

If it isn't broadcasting, it isn't there. A flight with no live ADS-B signal returns 404 FLIGHT_NOT_LIVE. That means "no receiver heard it just now" — not "cancelled", not "doesn't exist". Military traffic and some regions are simply dark.
No schedules, no gates, no delay minutes. ADS-B tells you where an aircraft physically is. Departure boards, terminals and baggage belts live in airline systems, not in radio broadcasts.
Coverage follows the receiver network. Over the US and Europe it's dense; over oceans it's sparse. The ageSeconds field is how you stay truthful about that in your UI.

Within those limits, though, the data is genuinely live and genuinely open — the sources (adsb.lol, OurAirports, OpenFlights) are credited in every response, as their licences require.

Try it

FlightScope is on RapidAPI with a free tier that's enough to wire up and test a real integration, plus paid tiers if your tracker takes off:

RapidAPI: https://rapidapi.com/binbin7418/api/flightscope-live-flight-tracking-and-airport-data-api

If you build something with it — a spotted-over-my-house bot, a fleet board, a spotter app — I'd love to see it. And if there's a field you wish the response had, tell me; the schema is versioned precisely so it can grow without breaking you.

I tested 3 ways to verify catch-all email addresses — here's what actually works

Wei Bin — Sun, 15 Nov 2026 07:11:09 +0000

Somewhere between a quarter and a third of the addresses on a typical B2B list sit on catch-all domains. I know this because I build an email validation API, and catch-all is the question every user eventually asks:

"Your API says this address is fine. But the domain is catch-all — so is the mailbox real or not?"

The honest answer is that nobody can tell you that from the outside. But "nobody can" is not what the verification industry advertises, so I spent some time testing the three approaches that are actually sold as catch-all verification, using real domains and my own API's live output. Here's what each one really does.

What "catch-all" means, in one paragraph

A catch-all (accept-all) mail server is configured to accept mail for any local part at the domain — real employees, people who left years ago, and addresses that never existed. It's a deliberate, legitimate setup, common at companies that would rather receive a mis-addressed message than lose it. Google Workspace and Microsoft 365 both let admins enable it, which is why so much of B2B email lives behind it.

The consequence: from the outside, every address at that domain looks identical. And that breaks the standard verification playbook.

Way 1: SMTP probing — the server says yes to everything

The classic verification trick is to open an SMTP conversation with the receiving server, start a delivery to the address in question, and read the response code — then hang up before sending anything. A 250 means "accepted", a 550 means "no such mailbox".

On a normal domain this works reasonably well. On a catch-all domain it proves nothing, by definition: the server answers 250 for the CEO's real address and for totally-invented-zzq@ with exactly the same enthusiasm. The probe tells you the server accepts mail — which you already knew from its MX records.

There's also a practical problem nobody mentions: outbound port 25 is blocked or throttled in most cloud and corporate networks, so running your own probes at scale means fighting your infrastructure provider before you fight the data.

Verdict: on catch-all domains, an SMTP probe returns a confident-looking answer that contains zero information about the mailbox.

Way 2: Big-vendor scoring — better, but look at the resolution rates

The large verification vendors know probing fails on catch-all, so they layer scoring on top: domain age, provider patterns, and — the part you can't replicate — engagement data from their own sending networks (did this address open, click, bounce somewhere else before?).

Some of that is genuinely useful. But published benchmark figures for how often vendors actually resolve a catch-all address to a firm verdict are sobering: roughly 12% for ZeroBounce, 8% for NeverBounce, 5% for MillionVerifier. In other words, the best-known vendor in the industry settles about one catch-all address in eight. The other seven come back as some flavour of "unknown" — usually at the same per-address price as a resolved one.

Verdict: real signal, but you're paying full price for a coin that lands on its edge 7 times out of 8.

Way 3: Domain-level signals — grade the risk, don't fake the verdict

The third approach gives up on the mailbox question entirely and answers a different, answerable one: what kind of domain is this, and how much risk does an address on it carry?

This is what I built into my own API (EmailCheck), so let me show you real output instead of describing it. I ran one batch call with 10 addresses chosen to cover the signal space — consumer providers, corporate domains, a disposable service, a typo, a domain that doesn't exist:

Address	Verdict	Score	catchAllRisk	Domain age (days)
ceo@gmail.com	valid	100	low	11,417
anyone@outlook.com	valid	100	low	11,777
support@google.com	valid	90	unknown	10,653
randomperson98765@google.com	valid	100	unknown	10,653
person@microsoft.com	valid	100	possible	12,981
hello@stripe.com	valid	90	possible	11,387
hi@linear.app	valid	100	possible	null (no RDAP record)
someone@mailinator.com	risky	50	possible	8,536
user@gamil.com	risky	60	possible	10,366
test@nonexistent-domain-xyz-123.com	invalid	15	unknown	—

Four rows in that table taught me more than the marketing pages of every vendor combined:

The invented address passes. randomperson98765@google.com is an address I made up; it scores 100. Domain-level checks verify the domain — its syntax, its MX records, its age — not the mailbox. Any tool that implies otherwise for a catch-all domain is selling you a score dressed up as a verdict. The correct output is the graded signal in the catchAllRisk column: possible for business-mail patterns where catch-all is commonly enabled (Microsoft 365 tenants, Google Workspace domains like stripe.com and linear.app), low for the big consumer providers.

The typo domain accepts mail too. user@gamil.com is a typo of Gmail — and gamil.com has its own MX records and has existed for 10,366 days. Typosquatter domains accept mail (that's the point of them), so "the domain accepts mail" can never be your only check. The API flags it as a likely typo, caps the score at 60, and returns the correction (user@gmail.com) in the suggestion field.

Disposable services are true catch-alls. Mailinator accepts literally everything — that's its product. It comes back risky at 50: disposable flag set, catch-all risk possible. Both signals are true at once, and both matter for a signup form.

Missing data is returned as missing. hi@linear.app has domainAgeDays: null because RDAP has no registration record the API could read. The field doesn't estimate, doesn't interpolate — it says null and names its source when it has one. I'd rather ship a null than a confident guess, because every downstream decision (send / segment / drop) inherits whatever the API claims.

Here's the raw response for the typo row, so you can see the full shape:

{
  "email": "user@gamil.com",
  "valid": true,
  "score": 60,
  "verdict": "risky",
  "checks": {
    "syntax": true,
    "domainExists": true,
    "mxFound": true,
    "disposable": false,
    "roleAccount": false,
    "freeProvider": false
  },
  "mxRecords": ["mail.gamil.com"],
  "suggestion": "user@gmail.com",
  "typoLikely": true,
  "domainAgeDays": 10366,
  "domainAgeSource": "RDAP",
  "catchAllRisk": "possible"
}

Verdict: you don't get a yes/no on the mailbox — nobody honestly has one — but you get an auditable risk picture per address, which is what list decisions actually need.

What to actually do with catch-all addresses

After all this testing, my working rules are boring and practical:

Don't delete them. If 30% of your B2B list is catch-all, deleting them deletes your market. The big vendors' own numbers say most of those addresses are simply unresolvable, not fake.
Segment them. Send to catch-all addresses as their own cohort, after your clean addresses, so a bad pocket can't drag your main sender reputation down with it.
Let bounces teach you. A hard bounce from a catch-all domain is real information — that mailbox genuinely doesn't exist. Feed those back into your list; it's the one ground truth this problem gives you.
At signup, act on the other signals. Disposable flag, two-day-old domain, typo suggestion — those are actionable in real time, catch-all or not.

The tool, briefly

EmailCheck is live on RapidAPI with a free tier (100 calls/month), single and batch endpoints (up to 100 addresses per call, with a summary report), and the fields you saw above on every response. There's also a free bulk checker and a $9.99 pack of 3,500 checks if you'd rather not think about subscriptions.

EmailCheck on RapidAPI: https://rapidapi.com/binbin7418/api/emailcheck-email-validation-api
Free bulk checker: https://email.newkwlab.com/bulk-email-checker/
The longer catch-all write-up: https://email.newkwlab.com/questions/can-a-catch-all-email-address-be-verified/
The $9.99 pack (3,500 checks): https://binbinster.gumroad.com/l/newkwlab-credits-3500

If you verify email for a living, I'd genuinely like to hear how you treat catch-all addresses. The industry mostly pretends this problem is solved. It isn't, and the pretence is priced per address.

I built a tool that puts two people into one Christmas photo — then tested whether the AI keeps their faces

Wei Bin — Sun, 15 Nov 2026 06:43:22 +0000

Every December, the same small problem shows up in my messages: couples who don't have a single good photo together. One of them travels for work, they live in different cities, or they simply never got around to taking a proper holiday picture. The photos exist — just never in the same frame.

So I built a small tool for exactly that. It's called SnapDuo. You upload one portrait of each person, pick a style, and it generates one photo of the two of you together.

How it works

Two photos in, one photo out. There are three styles right now:

Christmas Couple — the classic: matching red sweaters in front of a Christmas tree, mugs of cocoa, holiday-card energy.
Christmas Market — a candid-style shot at a Christmas market, Santa hats on, hot drinks in hand, crowds blurred behind you.
Tiny Boyfriend — the meme one: she holds a miniature version of him standing in her palm.

Under the hood, generation runs on the nano-banana-2-1 model through the Kie API, at 1K resolution (about 3 credits per image). Before paying for any production generations, I validated the prompts with a free image tool first — I didn't want to burn credits discovering a prompt was broken.

The flow is deliberately boring: upload two portraits, get a watermarked preview for free, and only pay if the result actually looks like you.

The part I actually cared about: does it keep their faces?

AI couple photos have one failure mode that kills the whole product: the output looks nice, but it doesn't look like them. A pretty picture of two strangers is worthless here.

So before calling this done, I ran a stability test. Three templates, two generations each, six images total. Same input portraits every time. For each output I checked three things:

Faces — do both people still look like the people in the input photos?
Hands — the usual AI disaster zone. Any extra fingers, melted grips on the mugs, broken palms?
Composition — does the same template produce a comparable shot twice, or is it a slot machine?

Result: 6 out of 6 passed. Faces were recognizable in every generation, no hand or face failures in any of the six, and each template's two runs were consistent in composition and quality — similar framing, similar lighting, no wild swings. That consistency matters more to me than one lucky great shot, because users will re-roll and compare.

Each photo also gets 3 free re-rolls, because "usually consistent" is not "always," and nobody should pay to find out.

Pricing: flat pack, no credits

I went back and forth on pricing and landed on the simplest thing I could: previews are free (watermarked), and a single $9.99 pack unlocks any 3 photos in full HD without the watermark. No subscription, no expiring coins, no credit math.

The reasoning: the preview is the product demo. If the free preview doesn't look like you, you shouldn't pay — and if it does, $9.99 for three finished photos is an easy yes or no. I didn't want a pricing page that needs its own tutorial.

What went wrong (so far)

The honest flaw: background signage. In the Christmas Market shots, text on the market stall signs in the background comes out garbled — readable-looking at a glance, nonsense up close. It's blurred background detail, so it doesn't ruin the photos, but it's there and I'm not going to pretend otherwise. Faces, hands, and clothing rendered clean; distant text did not.

Privacy-wise, I kept it strict: uploaded photos are used only to generate your picture and are automatically deleted within 7 days. They're never sold or used for training.

What's next

It's Christmas season, which is either perfect timing or a deadline, depending on how you look at it. The product is live and the templates are tested. What I don't have yet is proof that strangers want this — so the real test for me is whether real users show up and unlock photos before the end of November. If they do, I'll add more scenes. If they don't, I'll have learned something cheap.

If you want to try it: SnapDuo — the preview is free. There's also a short guide on how it works, including the photo rules that make results look most like you.

I'd genuinely like feedback on two things: does the face consistency hold up with your photos, and is the flat-pack pricing clearer than the credit systems other tools use? Building this solo, so outside eyes help.