Bringing Local Temple Events to a Global Audience Through Live Streaming
Designing for an audience the tech industry doesn't usually design for - and what changes when you do.
The hardest user research I have done was watching my grandmother try to use a "simple" app.
This client wanted to bring devotional events from village temples in central India to a global audience of devotees who had moved away - to other Indian cities, to the Gulf, to the US, to Australia. The viewers were emotionally invested. Many were elderly. Many were on inherited mobile phones with patchy connectivity. Most had never used a streaming app in their life.
The product brief sounded simple. The reality was that nothing about the audience matched what most streaming products assume.
Context
A village temple does not have AV infrastructure. It has a priest, a devotional practice, a community, and at most a smartphone someone donated. A temple operator who wants to stream is not a creator - they are a custodian of a tradition who suddenly has a new tool.
A devotee abroad is not on a 100Mbps fibre connection lying in bed. They are on a phone that they handed to a parent. They want to attend the morning aarti at the temple they grew up near. They want to feel present. They do not want to learn a streaming product.
The platform had to bridge those two worlds without burdening either.
The product challenge
Two reductions, both load-bearing.
On the temple operator side: the streaming workflow had to be one-button. Open the app, point at the deity, tap stream, walk away. Anything more complex than that - codec selection, bitrate tuning, scheduled events - would have meant the priest needed to learn something. He didn't have time and didn't see why he should.
On the viewer side: the experience had to assume the viewer had never used a streaming product. Open notification, tap, watch. No login wall, no profile setup, no "create an account to comment." Trust was assumed; the temple was the brand, not the platform.
My role
I led product and engineering: the streaming infrastructure, the operator app (designed around one button), the viewer experience (designed around zero friction), notification systems, and the cultural design choices that made the product feel native to a devotional context rather than imported from a Silicon Valley template.
Core features
- One-button streaming for temple operators with auto-detection of network conditions.
- Scheduled events: recurring daily aarti times, festival days, special pujas - visible to subscribers.
- Push notifications the moment a temple went live, in the languages the audience actually spoke.
- Viewer experience: open and watch, no signup gate.
- Multi-device cast: viewers could push the stream to their TV with a tap.
- Donation flow: small recurring or one-time contributions to the temple, frictionless.
- Cultural surface: calendar of festivals, temple history, languages of the temple's tradition.
Technical highlights
The streaming layer used a managed real-time-streaming provider rather than a self-hosted one. The wrong place to optimize cost when the failure mode is "grandmother sees a black screen during morning prayer." We layered on bitrate adaptation, automatic fallback to audio-only when bandwidth collapsed, and aggressive reconnection logic. Most operators streamed from a single phone in a temple, often handheld; we treated dropped frames and buffer events as expected, not exceptional.
Scheduling lived in a calendar primitive that supported the actual temple calendar - daily recurrence at sunrise, lunar festivals computed from a local calendar, special events configured manually. Generic CalDAV-style models didn't have a clean place for "every Ekadashi" or "the third Saturday of the month, in the Saka calendar." We built it.
Notifications were the entry point for every viewing session. The notification was the product for most users. We invested heavily in delivery reliability, multi-language support, and the ability to silence notifications without unsubscribing - many devotees had multiple temples but couldn't watch all of them, and the notification fatigue would otherwise have killed engagement.
The donation flow was deliberately spare. Donors who wanted to give could give in two taps. The flow assumed they did not want to fight a payment form. Recurring contributions to a specific temple were as easy as subscribing to a newsletter.
What this taught me
Designing for non-tech-savvy audiences is a design discipline, not a concession. It is not "we will make a simpler version for them." It is "we will design for the actual user from the start, and the result will be a better product for everyone." The streaming operators who used this platform also included tech-fluent priests at city temples - they liked the one-button workflow too.
Cultural design matters in product design. Color palettes, iconography, language defaults, calendar primitives, even the position of the donate button - all of these had to feel native to the audience's existing relationship with the temple, not imported from a fitness app. When the product felt foreign, viewers bailed even if it worked technically.
Live streaming preserves something more than the event. The platform let elderly devotees who had moved abroad reconnect with daily practices they thought they had given up. That outcome was emotional, not commercial. It also turned out to be the engine of word-of-mouth growth - every viewer was a potential evangelist to a sibling, a parent, a cousin in another city.
Outcome
The platform delivered local devotional events to a globally distributed audience reliably and at low operator burden. Temple operators who had never streamed before went live in minutes. Viewers who had never used a streaming product attended morning aarti from kitchens in Texas and Singapore. The cultural design choices made the product trusted in a community where most software is treated with suspicion.
If you are building for an audience the tech industry doesn't usually design for: spend more time watching them use what you build than designing what you build. The right product looks obvious in their hands and inscrutable in any pitch deck.