A pujari, a bhajan band and the samagri, booked in one place.
Four apps for a puja booking platform in Hyderabad: one for families and one each for pujaris, bhajan bands and samagri stores. I designed them from the first client brief to developer handoff.
Deepam is a pseudonym and the client's name is withheld.
Families find a pujari the way they find a doctor: through someone they trust. An app has to carry that trust to a stranger on a screen.
Research with the client and pujaris, the structure of all four apps, a visual language, 177 screens and developer handoff.
Pujaris, bands and stores share one flow: sign up, get approved, take bookings and get paid. I designed it once and changed only the steps where their work differs.
The intention. Who a booking serves and what it has to replace.
01The business
Families in Hyderabad book a verified pujari for a home puja, add a bhajan band if they want music and order the samagri from a store nearby. A single puja can involve a family, a pujari, a band and a store.
Each provider sees only their part; the family sees the whole thing in one booking.
The brief: make booking a pujari feel like booking any other service at home. See who is nearby, what they charge and what other families thought, then pay in the app.
02Research
Alongside the client calls, we spoke to pujaris about how they work without an app. Most of their bookings came through word of mouth and the temples they serve.
"A family finds a pujari the way they find a doctor: someone they trust tells them who to call."
What the pujari conversations kept coming back to
So the product had to rebuild that trust, on a pujari's card and profile.
Laying the ground. The structure and the calls it rests on.
03Decisions
ChoseOne shared flow for all three: sign up, get approved, take bookings and get paid, adjusted only where their work differs.
ReplacedThree separately designed apps.
WhyPujaris, bands and stores follow the same order. 4 of the 10 steps are identical down to the screen, and 103 provider screens come from one sequence.
ChoseAadhaar and a Pravarana video before anyone can book them.
ReplacedTrust through who recommended them.
WhyA stranger on a screen needs the same standing a relative's recommendation gave.
ChosePay 20% to confirm and the rest after, or pay in full and get ₹100 back.
ReplacedThe full ₹7,600 up front, in the first version.
WhyCash after the puja is the habit. Part-payment keeps the booking firm without asking for everything before the day.
ChoseA start code when the pujari arrives and a finish code to close the booking.
ReplacedNothing: the first version had no confirmation.
WhyBoth sides are paid or rated on the puja happening, and nothing confirmed that it had.
ChoseReject in the app up to 24 hours before.
ReplacedCalling support within 30 minutes.
WhyThe family hears in time to book someone else.
ChoseSuspension shows the reason on the pujari's home screen, with an appeal on the same card.
ReplacedHome as usual, with no explanation.
WhyA report flow has to be fair to pujaris as well as families.
Adornment. The screens families and providers actually hold.
04The family app
74 screens, including the states a demo usually skips.
05The provider apps
Pujaris prove who they are before anyone can book them. Bands can turn down a slot they're already playing. Stores run on orders and stock. Everything else follows the same backbone: sign up, wait for approval, take work, get paid.
Pujari app 37 screens, bhajan band app 35, store app 31.
06The system
One green, one type family and one icon set across all four apps. Ten near-identical greys became three text tones and two border tones, each saved as a variable developers can read by name.
One type family with open, wide shapes stays readable at 12px next to prices and timings. One 2px Lucide stroke style replaced three Font Awesome weights.
The offering. Revisions with the client, and what went to the developers.
07Revisions and handoff
Once the first version of every app was with the client, the revisions fell into three themes: how a family pays, how both sides confirm the puja happened and what happens when something goes wrong. That meant six changes, each designed from both sides of the booking.
Pay 20% now and the rest after, or pay in full and get ₹100 back.
The family shares a start code; the pujari's code closes the booking.
Reject up to 24 hours before, and start the puja from the same screen on the day.
Share live location, reach support or call police help on 112. Families can report the pujari.
The reason on the home screen, and an appeal from the same card.
Distance, delivery time and rating, with a sort that includes delivery time.
The client's list had two items still open: rescheduling and a calendar for pujaris. Both change what the family and the pujari see, so each is designed from both sides.
For rescheduling, the family asks for a new time, the pujari sees it against the rest of that day and the original booking stays until someone confirms.
08How I used AI
09At launch
There are no numbers to share yet. These are the signals that will say whether the design did its job.
The whole trust layer exists for this. If most bookings still go to pujaris the family already knew, verification and ratings aren't carrying enough weight.
Whether the with-and-without-samagri toggle is understood, and whether stores need to be surfaced earlier.
Approval sits between sign-up and a first booking. This shows where pujaris drop off before they ever earn.
Paired with how many suspensions are overturned on appeal, it shows whether the report flow is fair to pujaris as well as families.
The complete Deepam case study, with all four apps, is on Behance.