Skip to main content
CASE FILE 05 / SUB-DOSSIER / STATUS: SOLD
SOLD2024 — INTO COMMERCE

NUMHUB

A virtual number marketplace bot, built and run with a business partner — real payments, real customers, eventually sold.

OVERVIEW

NumHub was a Telegram bot reselling virtual phone numbers for account verification, aggregating 10 SMS-activation providers behind one wallet-based storefront. It handled real Zarinpal payments, automatic number-freshness checks, and code delivery via resilient polling queues, plus an admin panel for sales by provider and country.

We ran it for paying customers and eventually sold the business.

MY ROLE & THE TRADE-OFF

MY ROLE — I owned the bot logic, the SMS-provider aggregation layer, and the payments/wallet integration; my partner ran sales and provider relationships.

TRADE-OFF — polling queues over provider webhooks, since providers’ webhook reliability varied; polling cost latency but meant one code path instead of ten fragile ones.

Ten providers meant ten different ideas of what a reliable webhook looks like — some didn’t retry, some didn’t sign payloads consistently, some just dropped events under load. Standardizing on one polling loop that treats every provider the same way traded latency for something more valuable at this scale: one thing to debug when a delivery is late, not ten.

RESULTS & LESSONS

Real customers, real payments, and an eventual sale of the business — the clearest signal I have that the polling-over-webhooks call was the right one for a system with this many unreliable upstream providers. It’s the same trade I made again later on Pi Ducky Controller, for a related reason: simplicity in the client beats speed when the thing on the other end can’t be trusted to behave consistently.

MATERIALS — NODE.JS · TYPESCRIPT · GRAMMY · MONGODB · ZARINPAL
← BACK TO CASEWORK