From One Market to 90: How We Scaled a Consumer App to 1M+ Users Without Losing the Product Soul

The Problem With Most Global Growth Playbooks

The standard consumer growth playbook — paid acquisition, referral loops, push notification re-engagement, app store optimisation — was written for products where users share a cultural context, a connectivity baseline, and a common decision-making framework. Edvoy served none of those assumptions.

A student in Lahore applying to study in the UK had different trust triggers, different content consumption patterns, different device capabilities, and a fundamentally different relationship with the concept of “studying abroad” than a student in Colombo applying to Australia. Treating them as the same user in the same funnel produced the same result every time: optimised for one market, broken for the other.

What Made Each Market Different

Before we could build for global scale, we had to understand what “global” actually meant in our context. Here is what market-level research and product data revealed across six of our highest-volume source markets:

The Five Product Decisions That Drove Global Scale

1. 01
   Context-aware onboarding, not a single universal flow. We built onboarding as a decision tree, not a linear sequence. Based on a student's source country, intended destination, and application timeline, the app served a different first-session experience. A Nigerian student in the early exploration stage saw peer testimonials and destination country guides. A Pakistani student six weeks from an application deadline saw a document checklist and fast-track counsellor booking. Same app, different soul.
2. 02
   Performance as a feature, not a footnote. In markets like Bangladesh and parts of Sub-Saharan Africa, app performance was a conversion driver, not a nice-to-have. We introduced market-specific performance budgets — maximum APK size, maximum time to interactive, maximum image payload per screen — and treated exceeding them as a P1 product bug. Reducing app size by 30% in our Bangladesh build increased install-to-activation by 18%.
3. 03
   Trust signals localised by market, not just by language. Translation was table stakes. The harder work was localising what trust looks like. In India, trust came from institutional credibility — rankings, partnerships, and official accreditations. In Nigeria, trust came from social proof — “2,400 Nigerian students placed at UK universities last year.” In Pakistan, trust came from transparency — showing the exact process, timeline, and expected costs with no ambiguity. We built a trust signal framework that mapped content type to source market, and deployed it across all in-app surfaces.
4. 04
   Retention architecture built around journey stage, not calendar time. Standard retention playbooks measure Day 1, Day 7, Day 30 retention. For a product with a 12–18 month decision cycle, those metrics are nearly meaningless. A student who installs the app in September for an intake the following September does not need to be re-engaged in week 2 — they need to be re-engaged in February when shortlisting decisions typically start. We rebuilt our retention architecture around decision stage: Exploration, Shortlisting, Application, Pre-departure, and Post-arrival. Each stage had its own re-engagement triggers, content cadence, and success metrics.
5. 05
   Channel strategy localised to user behaviour, not platform preference. We defaulted to email-first for re-engagement because that is what every playbook recommends. Our data told a different story. In Pakistan and Bangladesh, WhatsApp outperformed email 4:1 on open rates and 6:1 on action rates. In India, in-app notifications combined with SMS outperformed WhatsApp for time-sensitive nudges. We built a channel preference model per source market and re-routed our entire re-engagement communication stack accordingly. Email dropped to a secondary channel in 60% of our markets.

“Localisation is not a feature you add after you have built the product. It is a product principle that must be embedded from the first line of the architecture. The teams that treat it as translation work always end up rebuilding.”

The Personalisation Engine That Made It Work

Serving 90 markets with bespoke product experiences is not operationally sustainable without a robust personalisation layer. We could not have a separate roadmap for each market. We needed a single platform that was intelligent enough to adapt.

We built the Student Context Engine — a real-time personalisation system that maintained a profile for every student across four dimensions: origin context (source country, language, cultural decision-making norms), intent context (destination country, programme type, application timeline), journey stage (Exploration through Post-arrival), and engagement signal (session frequency, content consumption depth, counsellor interaction history).

Every content piece, every notification, every in-app recommendation, and every search result ranking was filtered through this four-dimensional context. A student in Nigeria, exploring UK universities, six months from their target intake, who had been reading scholarship content, saw a completely different app experience from a student in India, shortlisting Australian universities, 10 weeks from application deadline, who had been engaging with visa content. Same product, different experience, at 1M+ user scale.

What the Funnel Looked Like Across 90 Markets

What We Learned

The Outcomes

The Bigger Lesson

Scaling a consumer product globally is not a growth problem. It is a product architecture problem. The teams that try to solve it with more paid acquisition in more markets always hit the same ceiling: the product was not built for the user they are trying to acquire. The teams that solve it by building intelligent context into the product foundation — what the user sees, how fast it loads, what builds their trust, when and how it re-engages them — find that global scale becomes a compounding advantage rather than an ever-increasing cost.

One million users across 90 countries is not one product used by one million people in the same way. It is one product that has learned to speak in a million different registers — and has the architecture to keep learning.