What happens when demand outruns the team that built it
Numero went into the summer travel season with two engineers and a product that worked. Installs tripled in six weeks, carried by airport word of mouth and a run of travel creators, and the app climbed into the top ten of Travel on both stores.
Then the activation flow started failing. Roughly one in twelve customers who paid did not get a working line on the first attempt — the carrier provisioning call would time out, the retry would collide with it, and support would activate the profile by hand. Every one of those tickets landed on the same two people who were meant to be shipping.
Hiring was the obvious answer and the slow one: a senior full stack hire meant two to three months of interviews before a line of code, and travel season would be over. They came to byThursday.ai instead — vetted AI Native Developers, matched in days, productive on the first one.
The team we matched, and what each person owned
We started with two developers on the activation path, the part that was costing money every hour, then added four more over three weeks as the ownership map filled in. Every surface had one name against it.
Core functions handled by the team:
- Activation pipeline: carrier provisioning rebuilt around an idempotent job queue, so a timeout retries cleanly instead of racing itself.
- Carrier integrations: one adapter per partner network, each with its own sandbox and contract tests, so a change in one cannot break the rest.
- Mobile releases: the React Native build, App Store and Play submissions, staged rollouts and crash triage.
- Billing and plans: top-ups, refunds and regional pricing, instrumented so a pricing test takes hours rather than a release cycle.
- Reliability: the on-call rotation, alerting on activation success rather than server health, and load tests before every seasonal peak.
“We didn’t need advisors. We needed people who could open the repo on a Monday and ship by Wednesday. That’s what showed up.” Lina Haddad, Head of Product, Numero eSIM
Why byThursday.ai instead of hiring in-house
Numero had the budget to hire. What they did not have was the quarter it would have taken, or the appetite to run a recruiting process through the busiest weeks of their year.
- Speed — first developer in the codebase four days after the call, a full team of six inside three weeks.
- AI fluency — every developer works with AI tooling daily, so they were shipping against an unfamiliar carrier API in week one rather than reading it for a fortnight.
- No hiring overhead — no sourcing, no take-home exercises, no equity negotiation, no ninety-day ramp.
“The part I didn’t expect was how little managing it took. I gave context once and got working code back, not a list of questions.” Lina Haddad, Head of Product, Numero eSIM
How the work stays predictable
Every engagement runs on the same five steps. They are written down rather than held in anyone’s head, which is what lets a second or sixth developer join without slowing the first one down.
The five pillars:
- Vetting before the match: every developer passes a live full stack build and an AI-tooling assessment before entering the network.
- Scoped to the stack: matched against your actual codebase and language — for Numero, React Native, Node and Postgres — so day one is commits, not reading.
- Written handover: each developer documents what they own and how it deploys, so no part of the system lives in a single head.
- Weekly checkpoints: a standing review of what shipped, what slipped and what changes next week.
- Replace, don’t renegotiate: if a developer isn’t right, we match a new one within five business days at no cost.
The same five steps run whether a company takes one developer or ten. It is the reason the sixth was no slower to add than the first.
What changed in nine months
The engagement began with two developers and settled at six. These are the numbers Numero tracked across that period.
- Activation success: 91.4% to 99.2% — measured on first attempt, across every carrier partner.
- p95 activation time: 48s to 9s — after the provisioning path was rebuilt around a job queue.
- Release cadence: every 3 weeks to twice a week — more than forty production releases in nine months.
- Manual activations: 340 a week to under 20 — support moved off provisioning and back onto customers.
What other founders can take from this
Numero’s situation is common, and the lessons travel further than consumer mobile.
- Ship speed is a hiring problem before it is an engineering problem. Numero’s architecture was fine. Their calendar was not.
- Alert on the outcome, not the server. CPU and memory looked healthy through the whole failure; activation success did not.
- Make retries idempotent before you scale. Most of the lost activations were the system colliding with its own retry.
- Separate the people who ship from the people who keep it up. Numero split feature work and reliability in week one and never merged them back.
- Measure cadence, not headcount. Releases per month told them more about real capacity than the size of the team ever did.
What’s next
Numero is opening six new markets, which means new carrier adapters and a localisation pipeline that two of the matched developers are building now. eSIM transfer between devices is in testing, the single most requested thing in their support queue.
The team has stayed at six. The stated goal for the next year is to double activations again without doubling the people it takes to run the product.