MOBUNLOCK
A phone unlocking app whose whole product is its integrations. Four of them, running against each other, on every order.
- Role
- Mobile app, platform architecture, integrations
- Surface
- iOS and Android, plus a public reseller API
- Status
- In service
The hard part was never the unlock.
A customer sees one button. Behind it, the platform has to work out what the handset is, which vendors can service it, what that will cost today, whether the customer has paid, and what to do when the vendor goes quiet for six hours.
Every one of those answers came from a different system, each with its own failure mode. A device lookup returns something ambiguous. A supplier changes a price list without notice. A payment settles after the order has already been routed. A reseller submits the same order four times because their shop wifi dropped.
The product was the coordination. Most of the engineering went into making those four systems disagree safely.
What it ran on
FOUR INTEGRATIONS, ONE ORDER.
Device intelligence
Everything downstream depends on knowing what the handset actually is, so the lookup layer came first.
- IMEI validated on device before any paid call goes out
- Type allocation code resolved to make, model and variant
- Carrier detection, lock state, blacklist and warranty status
- Results cached per device, so a repeat lookup cost nothing
Supplier network
Unlocks are fulfilled by wholesale vendors. Each one has its own catalogue, its own turnaround and its own bad days.
- Every vendor sat behind one adapter interface
- Price lists and service catalogues synced on a schedule
- Orders routed by availability, turnaround and cost
- Failed or expired orders refunded without a human touching them
Payments and payouts
Money moves in two directions at once: customers paying in, resellers drawing down and being paid out.
- Payment captured at order time and held against that order
- Reseller wallets with per-tier pricing
- Ledger entry for every movement, no balance written directly
- Supplier invoices reconciled against fulfilled orders
Reseller API
Repair shops do not want a dashboard. They want to submit orders from the software already on their counter.
- Keyed REST API scoped per reseller account
- Idempotent submission, because resellers retry on any timeout
- Webhooks on every status change, with signed payloads
- Sandbox mode against a fake supplier for integration work
DECISIONS THAT HELD UP.
One adapter interface for every supplier
Adding a vendor is configuration plus a small adapter, never a change to order handling. Dropping one that turns unreliable takes minutes.
Orders as a state machine
A status column that anything can write to becomes unreadable within a year. Transitions are explicit and illegal ones are rejected, so an order's history can always be reconstructed.
Idempotency on every write
Retries are the normal case when a shop's connection drops mid-request. Duplicate submissions return the original order rather than charging twice.
Money only moved through the ledger
No code path adjusts a balance directly. Every credit and debit is an entry, which makes a dispute with a reseller a query rather than an argument.
Where it stands
MobUnlock is in service. It is here because the shape of the problem recurs constantly: a business whose value sits in orchestrating other people’s systems reliably, on a phone, where none of that complexity is allowed to show.
GOT A SYSTEM THAT MUST TALK TO FIVE OTHERS?
That is the work we are best at. Tell us what has to stay in sync and we will tell you what it takes.
Start a project