One number, a whole handset, and a database that keeps up with 125 brands
A metered IMEI lookup service that turns fifteen digits into a device, its specifications and its status. It's sold three ways to three audiences and backed by a device database that maintains itself.
The shape of the work
- Industry
- Consumer Electronics
- Duration
- 22 weeks
- Cooperation model
- Dedicated team
- Services
- Platform engineeringPublic APIData pipeline
- Integrations
- Stripe BillingCloudflare TurnstilePostmarkSentryGSMArena feeds
- Technologies
- Next.jsTypeScriptNode.jsPostgreSQLStripeTailwind CSSFingerprintJS
- Team
- 1 Project lead2 Full-stack engineers1 Data engineer1 QA engineer
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
The hard problem
A device database goes stale the week you stop feeding it, and a free lookup tool is abused the day it ranks. They had both problems at once: a catalog nobody was maintaining, and anonymous traffic they could neither price nor throttle.
Manual catalog entry had failed in the ordinary way: it worked while one person owned it and stopped when they moved on. The abuse problem was structurally different. The free tool's value depends on requiring no signup, so every obvious throttle either put a wall in front of the traffic that becomes revenue or caught whole offices behind one IP.
One resolution service behind three front doors: a consumer lookup, a repair-shop and retailer workspace, and a keyed developer API. Behind it, a scraping and reconciliation pipeline keeps brands and models current, and device-level fingerprinting makes abuse answerable without forcing everyone to sign up.
How the pieces fit
- 01
Modeled brand, model and variant separately so a spec change doesn't orphan a lookup
Separating the axes required re-homing a catalog in which brand and model had been one string, and about a tenth of it couldn't be resolved automatically.
- 02
Built one resolution service and put three differently-priced surfaces in front of it
Three surfaces sit in front of one resolution service, each priced and shaped for its audience, none holding its own copy of the data.
- 03
Metered the developer API per key, with usage visible to the customer before the invoice
Metering reads the same counters that enforce the rate limit, and usage accrues visibly in the console with the projected charge beside it.
- 04
Kept the database current with a scrape-and-reconcile job in place of manual entry
A scheduled job scrapes manufacturer and regulatory sources and raises differences for review instead of writing them, so nothing becomes canonical unreviewed.
- 05
Fingerprinted anonymous lookups so abuse is throttled without a signup wall
FingerprintJS identifies the device instead of the IP, so the expensive tenth of anonymous traffic is throttled while offices behind one address aren't.
- 06
Shipped the four free tools as top-of-funnel, on the same resolution service
The four free tools run on the same resolution service as the paid product and are built to the same standard, because most paying customers arrive through one.
The system we were asked to build
The IMEI lookup service sells one answer (what is this handset, and can it be trusted?) to three audiences who buy it very differently. We built the lookup, the metered developer API, and the pipeline that keeps a 125-brand device database current.
A device-intelligence service with a catalog nobody had fed for eighteen months and a free lookup tool that had started ranking. Both facts arrived together and compounded: the traffic the tool attracted was mostly scripted, and the answers it returned were increasingly wrong about anything released since the catalog was last maintained by hand.
Platform & API Engineering
One resolution, three products
A consumer lookup, a trade workspace and a developer API all read the same service, each priced and shaped for its audience.
One resolution service sits behind three front doors that share nothing but the answer: a consumer lookup optimized for a single anxious question, a workspace where a repair shop checks a bench full of devices, and a keyed API for developers. Each is priced and shaped for its own audience, but none of them holds its own copy of the data, so a correction lands in all three at once.
- Three products, one resolution service beneath them
- Priced and shaped per audience, with no duplicated data
- A correction lands in all three surfaces at once
One canonical record in the staff desk: a battery correction approved on the model record, then read minutes later by the consumer lookup, a repair shop's bench and a developer's API key, each returning the corrected value.
A night's reconciliation run across 125 brands: seven differences raised, from a new model to a legacy one-string entry, and none written until someone passes them into the record.
125 brands, kept current
A scrape-and-reconcile job detects missing models and fills them, with a human review step before anything becomes canonical.
A scheduled job scrapes manufacturer and regulatory sources, reconciles what it finds against the canonical table, and raises the differences for review instead of writing them: a new model, a changed specification, a brand that has renamed itself. Nothing becomes canonical without a human passing it, because a silently wrong device record is worse than a missing one for everyone downstream.
- Scrape and reconcile across 125 brands on a schedule
- Differences raised for review, never written directly
- Nothing becomes canonical without a human pass
Metering you can watch
Per-key usage shows in the developer console as it accrues, long before the invoice.
Usage accrues visibly in the developer console as calls land, with the current period's count, the rate limit and the projected charge on the same screen. Metering is computed from the same counters that enforce the limit, so the number a developer watches is the number they'll be billed on. A discrepancy between the two is the single fastest way to lose an API customer.
- Per-key usage visible as it accrues, not at invoice time
- Rate limit and projected charge on the same screen
- Metering and enforcement read the same counters
The developer console mid-period: calls counted as they land, the month-end projection and its charge beside them, the rate limit read from the same counter, and a rate-limited call listed but not metered.
The free validator refusing a fourteen-digit number, showing the Luhn working, and offering back the full IMEI with its check digit, one of four free tools on the same service as the paid lookup.
Free tools as the front door
Validator, generator, barcode and MEID conversion run on the same service, and are how most paying customers arrive.
The validator, generator, barcode reader and MEID converter run on the same service as the paid product and cost nothing to use. They are the acquisition channel: most paying customers arrive through one of them, having already confirmed the data is right on something they cared about. They're built to the same standard as the paid surfaces, not treated as marketing.
- Free tools run on the same service as the paid product
- Most paying customers arrive through one of them
- Built to the same standard as the paid product
Abuse control without signup
Device fingerprinting throttles the expensive tenth of anonymous traffic while the free lookup stays frictionless.
The free lookup stays open with no signup, so abuse has to be answered without a login. FingerprintJS identifies the device, not the IP, which is what lets the expensive tenth of anonymous traffic be throttled while everyone else notices nothing. An IP limit would have caught an office and a NAT along with the scraper. Throttling degrades to a delay before it becomes a refusal.
- Device fingerprinting instead of IP, so offices aren't caught
- The expensive tenth throttled; everyone else unaffected
- Degrades to a delay before it becomes a refusal
An hour of anonymous lookups counted per device: four fingerprints carrying a tenth of the traffic are delayed or refused, while twelve devices behind one office address carry on untouched.
Eleven languages
Eleven language trees, each locale a route segment with prerendered marketing and product pages, beside the German lookup page as rendered and the hreflang links in its head.
Locale is a route segment, so every surface, marketing pages included, is properly translated instead of bolted on.
Locale is a route segment, so every one of the eleven languages is a real prerendered page with its own URL, metadata and hreflang, never a client-side string swap. The marketing pages are translated on the same footing as the product, which is unusual and deliberate: the traffic that matters here arrives on a marketing page in its own language or not at all.
- Locale as a route segment: eleven prerendered language trees
- Real URLs, metadata and hreflang, not a client-side swap
- Marketing pages translated on the same footing as the product
Phase by phase
Phase 1: The Device Model
Brand, Model, Variant: Kept Apart
Modeled the three levels as separate records, so a variant gaining a spec or a brand renaming a line doesn't invalidate every lookup beneath it.
- Device Schema
- Brand Taxonomy
- Variant Resolution Rules
Phase 2: One Service, Three Doors
Same Answer, Three Prices
Built a single resolution service and put a consumer lookup, a trade workspace, and a keyed API in front of it, so the three audiences buy the same answer in the shape each one actually wants.
- Resolution Service
- Segment Surfaces
- Pricing Tiers
Phase 3: The Metered API
Usage You Can See Before The Invoice
Metered per key with the running count exposed in the developer console, because a metered API whose usage is only visible on the bill is one customers stop trusting.
- API Keys
- Usage Metering
- Developer Console
- Rate Limits
Phase 4: Keeping It Current
A Database That Feeds Itself
Built the scrape-and-reconcile job that finds brands and models missing from the catalog and fills them, with an admin review step so a bad scrape never silently becomes the record.
- Scrape Pipeline
- Missing-Model Detection
- Reconciliation Review
Phase 5: Abuse Without A Wall
Throttling The Anonymous Tenth
Fingerprinted the device instead of the session, so the small fraction of anonymous traffic driving most of the cost can be throttled while everyone else keeps a frictionless free lookup.
- Device Fingerprinting
- Abuse Rules
- Audit Log
The trade workspace: a repair shop's morning bench of nine pasted numbers, eight resolved with their locks and a verdict each, and one refused on its check digit before lookup and not charged.
What it carries now
125
Brands in the catalogue
−94%
Manual catalogue entry
−71%
Anonymous abuse cost
11
Locales served
Brands in the catalog is the count after the pipeline's first full pass. Manual catalog entry compares the maintenance hours before and after. Anonymous abuse cost is the change in infrastructure spend attributable to unauthenticated traffic. Locales served is a count of fully prerendered language trees, not of translated strings.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
What the architecture settled
A device database is a pipeline, not a table: the week you stop feeding it, it starts lying.
A catalogue is a pipeline: the manual version worked while one person owned it and began lying the month after they stopped, which is the failure mode of every hand-fed table.
Three audiences buying the same answer want three products, not three pricing rows.
The consumer, the repair shop and the developer buy the same fact and need three different products: pricing rows would have given all three a bad fit.
Metered usage that is only visible on the invoice is metered usage customers stop trusting.
Usage visible only at invoice time is the fastest way to lose an API customer, and it costs nothing to expose the counter that is already being kept.
Fingerprinting the device instead of the session throttles abuse without putting a signup wall in front of the traffic that becomes revenue.
Fingerprinting the device rather than the session or the IP is what let the free tool stay frictionless while the abuse became answerable.
How the work was run
- 01
We built the resolution service and the developer API first, because metering was the thing blocking revenue, and ran the scrape pipeline in shadow for six weeks before it was allowed to write to the catalogue. The consumer and trade surfaces followed once the answer underneath them was trustworthy.
A dedicated team for twenty-two weeks, with the three surfaces built against one resolution service from the first sprint rather than being unified later. The reconciliation job's human review step was insisted on by the client and turned out to be right: a silently wrong device record is worse than a missing one for every downstream consumer.
One minute of anonymous traffic, replayed
An address limit refuses the office. A device limit refuses the scraper.
The same minute of lookups against the free tool (an office, a busy technician, a scraper and one buyer) with no throttle, with the obvious limit per IP address, and with the per-device fingerprint limit that shipped. Switch tabs, or use the arrow keys once one is focused.
What shipped: count per device fingerprint, whatever address it arrives from. Each office device is light and untouched. The busy browser is only slowed. The scraper is slowed, then refused.
- A repair office12 devices behind one address · 36 lookups36 · 0 · 0
- One busy browserA technician checking a bench · 25 lookups20 · 5 · 0
- A scraperOne device rotating 8 addresses · 240 lookups20 · 40 · 180
- A buyer at homeOne phone, one listing · 2 lookups2 · 0 · 0
Only the scraper is refused, after a delay first. The office and the buyer notice nothing, and nobody had to sign up.
Why a wall was never the answer: the free lookup’s value is that it asks for nothing, and the traffic a signup would stop is the traffic that becomes revenue.
A catalogue that feeds itself, and one answer sold three ways
The device database is a living pipeline. What reaches a buyer, a repair shop or a developer has passed a reconcile step and a person, and is read from one place.
- 01 · SourceManufacturer & regulatory sourcesA scheduled scrape across all 125 brands, so the catalogue no longer depends on one person entering models by hand.
- 02 · IngestionReconcile against the canonical tableNew models, changed specs and renamed brands are raised as differences, never written directly.
- 03 · ReviewA human passNothing becomes canonical unreviewed, so a bad scrape is a row to reject, never a wrong device record.
- 04 · StateBrand, model, variant in PostgreSQLThree levels kept apart, so a variant gaining a spec or a brand renaming a line doesn't orphan a lookup beneath it.
- 05 · DeliveryOne resolution service, three doorsConsumer lookup, trade workspace and keyed API hold no copy of the data, so a correction lands in all three at once.
What a wrong answer can reach
Data integrity & fair metering
No unreviewed record becomes canonical
The reconcile job raises differences for a human instead of writing them, because a silently wrong device record is worse than a missing one for every consumer downstream.
The count you watch is the count you pay
Metering reads the same per-key counters that enforce the rate limit, and usage accrues in the developer console with the projected charge beside it, before any invoice.
Abuse is throttled without a wall
Anonymous lookups are counted per device fingerprint, whatever IP they come from, so offices behind one address aren't caught. Throttling degrades to a delay before it becomes a refusal.
Selling one dataset to buyers who each want it differently? Scope your build in 3 minutes.
Scope your buildNearby engagements
Data & AnalyticsA checkout that stopped losing sales to a 6-second load
Profiling found the real bottleneck behind a slow checkout (an N+1 query and an oversized bundle) and tuned both, with before-and-after metrics locked in as a baseline against future regressions.
E-commerce & Retail · 5 weeks
Web PlatformsA reader people finish, and a library that remembers where they stopped
A reading platform for a comics catalog: a browse surface people can actually navigate, a reader that gets out of the way, and a history that puts everyone back on the page they left.
E-commerce & Retail · 18 weeks
Web PlatformsOne platform, two trades, and three quarters of the domain never changed
A multi-tenant Laravel platform sold into two trades. Purchasing, sales, returns, expenses, tenancy and roles are one product; only the nouns on top of them change.
E-commerce & Retail · 30 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
