The problem
Temple administration is usually spread across three systems that do not speak to each other: a paper register at the desk, an accounting package somebody set up years ago, and a WhatsApp group where the real decisions happen.
It works, in the way a shop works with a calculator beside the till. Then a festival arrives, three volunteers who have never done the job are on the desk, and at the end of the week nobody can say with confidence what was collected, what was given out, or where the difference went.
Business context
A temple is not only a place of worship; it is an organisation that answers to trustees and, in most jurisdictions, to a charity regulator. Diaspora temples feel this most sharply — they are often newer, growing quickly, and run by committees whose members change.
That is the gap OmKaarya was built for: not a donation button bolted onto a website, but the operating system underneath the whole thing.
Users
Three different people, with almost nothing in common. A volunteer at the desk who may be doing this for the first time this month. A committee member who needs to know the position without learning accounting software. A trustee or auditor who arrives once a year and asks questions that must be answerable.
Software that suits any one of those three usually fails the other two, which is why so much of this work ends up back on paper.
Constraints
- A volunteer must be able to work the desk after one session, because volunteers rotate
- Sevas, prasadam stock and ornaments have to reconcile against each other, not sit in separate lists
- Devotee records must survive the person who wrote them down
- Reporting has to satisfy charity-law obligations, not just look tidy
- Every temple is different in structure, so the system has to flex without becoming a configuration project
What we built
Seva POS at the desk, with prasadam stock and ornaments tracked alongside it, so what came in and what went out reconcile rather than being estimated after a festival. A devotee record holding history, contributions and family details, kept properly instead of in one person’s memory. Accounts underneath all of it, reporting in the shape trustees and auditors expect.
The public positioning is that a temple is live in 48 hours. That is a claim about setup, and it holds only because the hard part — deciding what a temple actually needs to record — was made once, in the product, rather than being rediscovered per customer.
Product decisions
We modelled the temple as a tenant with plan-level packs rather than a pile of feature flags, because a small temple and a large trust want genuinely different systems and neither should pay for the other’s complexity.
We also resisted making the desk screen configurable. A volunteer on their first Saturday does not benefit from options; they benefit from the common task being obvious. Configuration lives in administration, where somebody has time to think.
Results
OmKaarya is live at omkaarya.com and is the product we point to when someone asks whether we can build multi-tenant software with real administrative depth.
We are not publishing adoption figures or efficiency percentages. We have not measured them in a way we would defend, and named temples do not appear here because we have not asked for permission to name them.
What we would do differently
We would put the weight budget on this one at the start. Measured in September 2026, the marketing site ships around eight megabytes — mostly unoptimised images and one oversized JavaScript chunk — which is not a standard we would accept on client work, and it is on our own list to fix.
Writing that down here is uncomfortable, which is roughly the point of measuring things.