Book a pujari, a bhajan band and the samagri in one place.
For about four months I was the only designer on a puja booking platform in Hyderabad. I designed four apps, one for families and one each for pujaris, bhajan bands and samagri stores, 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. The app has to help families trust a pujari they've never met.
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 involves and how it worked before.
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, and the family sees the full 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 came up most in the pujari conversations
So a pujari's card and profile had to give families the same confidence.
Laying the ground. The structure and the main decisions.
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.
WhyFamilies need a way to trust a pujari without a relative's recommendation.
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. Paying part upfront confirms the booking without asking families to pay everything in advance.
ChoseA start code when the pujari arrives and a finish code to close the booking.
ReplacedNothing: the first version had no confirmation.
WhyPayment and ratings depend on the puja taking place, and nothing confirmed that it did.
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 use.
04The family app
74 screens.
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 steps: 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.
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 I'd track to see whether the design works.
This is what verification and ratings are for. If most bookings still go to pujaris families already knew, those features aren't doing enough.
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.