We have spent the last 18 months building multiple mobile apps for India. We have built subscription-based, work-related apps for mass-market consumers as well as large businesses. This has taken us through 9 complete product/design cycles, and countless incremental changes.

I wanted to put down what we have learnt, in the hope that it will help others in the initial stages of building for India. This part focuses on some of the unique challenges we faced here, withOUT going into how we solved some of these.


Note: Some of these are specific to Android (95% of smartphones here run Android)

1. User Diversity

You will have users at various levels of mobile familiarity. Just imagine these three personas:

  • yourself,
  • your parents, and
  • your delivery boy.
Attribution: Icons made by Freepik from www.flaticon.com are licensed by CC 3.0 BY

You would understand “Sync”, but your parents and delivery boy probably wouldn’t.

You and your parents could follow plain English instructions, but your delivery boy would probably need other cues.

Your parents might appreciate a step-by-step, but you and your delivery boy would want to get on with it.

And so on. Some of us may avoid this, to an extent, by concentrating on a core target audience. But if you are building, say, a banking app, then it has to work friction-free for all three.

2. Data usage

Even today, in the post-Jio world, a significant percentage of urban users use data intermittently.

Attribution: Icons made by Freepik from www.flaticon.com are licensed by CC 3.0 BY

Wi-Fi only: For one of our mass-market apps, a majority of customers would download content only twice a day (this was pre-Jio): on their office Wi-Fi around 10 am, and on their home Wi-Fi, from 6 pm onwards. In between, they would turn on mobile data only to check mail and WhatsApp messages.

The afternoon battery savers: Another set of customers would be always-on in the first half, but will start turning off data post 3 pm, when their batteries slipped below 30%

Uneven data usage patterns like these create some unique challenges for:

  • Content delivery (the “heavy” asset data),
  • Features that need real-time sync (eg. chat, or a one-on-one quiz),
  • Multi-device sync (add all-day simultaneous usage),
  • Peak-load strain on our infra (eg. the 10 am office Wi-Fi rush hour)
  • Notifications, support conversations, etc.

3. Battery, GPU, and OS

This is quite straightforward, and I guess not unique to India, except that computing power and battery life vary widely, even inside a tight target audience. Some folks won’t mind always-on apps, but most would.

Also, as of this writing (Aug 10, 2017), even for an expensive app ($20+ per year), about 12.5% of weekly installs are on KitKat or lower (Android 4.4-). That’s pre material design :).

4. Forked OSes with minds of their own

Attribution: Icons made by Freepik from www.flaticon.com are licensed by CC 3.0 BY

Some manufacturers promise all-day battery, and keep that promise by interfering with your app’s core workings — like terminating background threads after 30 seconds.

Some also do this to take care of over-heating, or in the name of security.

This adds new complexity to your architecture, and new devices to your test plan.

5. Extreme customization and support expectations

Attribution: Icons made by Freepik from www.flaticon.com are licensed by CC 3.0 BY

It’s hard for your support team to stick to a “product” narrative here. Expect customization requests/orders to flow in from day 1, and expect users to complain if specific needs aren’t met.

Expectations of support, especially phone support, are quite high. We still have a 1-star from one of our first customers, who couldn’t reach us on our Republic Day last year. (This is after clear communications on support timings and holidays).

Also, like the Zappos stories, expect a lot of general requests. We make a product for LIC Agents (who sell life insurance for India’s largest, state-run insurer). Here’s a sample of our more colorful support conversations with these users:

  • How to fill up a form for the agent’s own housing loan
  • Which are the best US-based colleges for the agent’s daughter
  • How to pitch to this particular customer

Lastly, language. While most folks are fine using an English app, some struggle to explain a problem in English. Expect phone conversations to slip into vernacular. We have a pretty diverse team that speaks 8 different languages, but we still struggle sometimes.

6. One-stars as a support shout-out

We carefully shepherded one of our apps through it’s first 1,000 star ratings on Google Play Store. Maintaining 4.6+ was tough — but not because people didn’t like the app.

Some folks simply used a PlayStore 1-star to ask for support. In their experience with other companies, this had brought a faster response than the in-app chat.

7. Non-standard screens

(Android only) Managing different resolutions and screen sizes is expected. But some phone manufacturers even make up their own non-standard aspect ratios. Contrary to what our engineers believe, not everything is 16:9.

If most of your images are going to be in containers (like a product catalog or photo feed), then this may not be a big issue. Except perhaps if your splash screen has a circle on it :).

But if you are doing any image/text superimposition, this can hold up releases. Also, imagine having to tell your lead designer that their pixel-perfect image assets have to look good even when stretched and skewed.

Whew!

That’s the easy part — challenges.

Thanks for reading! More to add? Have you faced any other unique challenges, building for India? Drop me a line, and we’ll talk/solve, or at least laugh about it.

After-thought: Now, this is not to say everything is gloom-doom challenging. We have had more than our share of good moments — exciting, fulfilling, heartwarming, or just ridiculously funny. As I am sure you’ll have yours. But good times in some other piece. This one was about challenges, so...