Product decisions in Indian software are made on the assumption of a smartphone with a data connection, and for a great many use cases that assumption is fine. For others — agricultural supply chains, rural financial services, blue-collar workforce management, government schemes — a significant portion of the people the product exists to serve either do not have a smartphone, share one within a household, or have one they cannot reliably keep charged and connected. Designing only for the app excludes them entirely.
The channels that reach these users are old and unglamorous. SMS works on every phone and needs no data. Voice calls and interactive voice response reach people who cannot read comfortably, which is a larger population than product teams from urban backgrounds tend to assume. USSD — the menu-driven service reached by dialling a short code — works on any handset with no data and no installation, which is why it underpins so much of financial inclusion. A missed-call trigger, where the user calls a number and hangs up, is a free way for someone to signal intent.
Designing for these constrains you usefully. A flow that has to work in a hundred and sixty characters, or through a voice menu with four options, forces a clarity that app interfaces rarely achieve. The discipline is to identify the two or three things the user actually needs to do — check a balance, confirm a delivery, report a reading, request a callback — and build only those. Attempting to replicate the app's full functionality over SMS produces something nobody can navigate.
The assisted model is often better than the direct one and gets overlooked. Rather than the end user interacting with your system at all, an intermediary who does have a smartphone — a field agent, a shopkeeper, a village-level entrepreneur, a supervisor — operates it on their behalf. That changes the product entirely: you are building for a semi-professional user doing many transactions, which means density, speed and offline capability matter far more than onboarding does. A great deal of successful Indian rural technology works this way.
Language and literacy are not the same constraint and need separate handling. Text in a regional language helps someone who reads that language. It does nothing for someone who does not read comfortably in any language, and for them voice, icons and numbers are the interface. Numeric input is close to universally accessible; free text is not. Designing so that the critical path can be completed with digits alone is the single most inclusive decision available.
Finally, be honest internally about whether you are building this or gesturing at it. An SMS fallback that nobody tested, or a voice flow built once and never reviewed, is worse than not offering it — the user tries the channel they can reach, it fails, and they conclude the service does not work. If these channels matter to your market, they need the same instrumentation, monitoring and iteration as the app. If they do not matter, saying so is better than a token implementation.
