A twelve-year-old stack, replaced in six months. Without pausing the roadmap.

Zain’s self-service app carried millions of subscribers through the things people actually do with an operator: check a balance, top up, change a bundle, query a bill. It worked, and it had worked for twelve years, which was the problem.

The platform underneath it had been extended one release at a time since launch. Deploys were a monthly, late-night event the whole team stayed up for. The business portal had no single sign-on and no audit trail, which is the first thing an enterprise procurement team asks for. An in-house team of roughly twenty was spending the majority of its time keeping the existing system standing rather than adding to it.

Rebuilding meant stopping, and stopping meant a year with nothing new for customers. What Zain needed was not a bigger team but a second one, running in parallel on the replatform. We matched three developers in five days and ten inside seven weeks.

Two tracks, one roadmap

The in-house team stayed on the product subscribers use every day. The matched team took the replatform domain by domain, with every extraction behind a feature flag until it was proven against real traffic.

Core functions handled by the team:

• Service extraction: balance, top-up, bundles and billing pulled out of the monolith one domain at a time, each behind its own flag.
• Identity and access: single sign-on, SAML, role-based permissions and a full audit log for the business portal.
• Data migration: twelve years of subscriber and billing history moved with a dual-write period and nightly reconciliation, with no customer-visible downtime.
• Mobile rebuild: the self-service app rewritten against the new services, shipped market by market rather than in one cutover.
• Release engineering: the pipeline, automated tests and staged rollouts that turned a monthly deploy into a daily one.

“We had been told a replatform meant a year with nothing new for customers. We shipped the rebuild and the roadmap at the same time, because we had two teams instead of one stretched thin.” Faris Al-Khatib, Director of Engineering, Zain

Why byThursday.ai instead of hiring in-house

The replatform needed ten people for seven months, not ten people permanently — and it needed them before the next budget cycle, not after it.

• Scale on a schedule — ten developers inside seven weeks, a pace no internal requisition process was going to match.
• Legacy fluency — we matched developers who had done monolith-to-services work before, rather than ones learning it on live subscriber data.
• No permanent headcount — the team scaled back to two for maintenance once the migration closed, without a restructure.

“The weekly checkpoint was the whole thing. I always knew what had shipped and what was at risk, which is more than I could say about our own sprints.” Faris Al-Khatib, Director of Engineering, Zain

How ten developers stayed coordinated

Coordination, not talent, is what breaks a ten-person engagement. The same five steps run on every byThursday.ai project, and at this size they are the entire reason it held together.

The five pillars:

1. Vetting before the match: a live full stack build and an AI-tooling assessment, filtered further for developers with production migration experience.
2. Scoped to the stack: matched to Java, Spring and Oracle specifically, so the first pull requests landed in week one.
3. Written handover: every extracted service shipped with a runbook covering deploy, rollback and alerts, owned by Zain’s team rather than ours.
4. Weekly checkpoints: a standing review across both tracks, so the in-house team and the matched team never planned against each other.
5. Replace, don’t renegotiate: two developers were swapped in the first month at no cost, with replacements in the codebase within five business days.

Nothing about the process changes with headcount. That is what makes the tenth developer as straightforward to add as the second.

What changed in seven months

Zain measured the engagement against the estimate its own team had written before we started.

• 14 months of planned replatform work delivered in 6 — against Zain’s own pre-engagement estimate.
• Deploys: monthly to more than 30 a week — and no late-night release window since the third month.
• App store rating: 2.8 to 4.5 — across both stores, over two quarters.
• Self-service containment: 38% to 71% — journeys completed in the app without contacting support.
• Call-centre volume down 24% — on the journeys the rebuild covered.

What other teams can take from this

Most of what Zain learned applies to any product that outgrew the decisions it was built on.

• A replatform does not have to cost you the roadmap. It costs you a second team, which is faster and cheaper to assemble than most organisations assume.
• Business buyers are checking for three things. Single sign-on, audit logs and a compliance report. Build them before procurement asks, not during.
• Migrate with dual writes and reconciliation. Twelve years of data moved without a maintenance window because nobody trusted a single cutover.
• Keep the in-house team on what customers pay for. Institutional knowledge belongs where the churn risk is.
• Deploy frequency is a product metric. The rating moved because the fixes could finally reach people the same week they were written.

What’s next

Two of the matched developers stayed on to extend the business portal into a self-serve API for enterprise accounts, now in private beta. The rest of the engagement closed on schedule.

Zain has since taken the same two-track approach to its retail systems, against a codebase a new engineer can understand in a week and runbooks written while the work was being done.