Murugan Temple of St. Louis · Proposed mobile app For the board meeting. Bring this page; leave the deck behind.
Please approve the following five items together, as one discovery package:
| Item | What it means in practice | |
|---|---|---|
| ☐ | A short discovery phase | Time to establish what the temple actually needs before anything is designed or built. |
| ☐ | Interviews | With priests, administrators, volunteers, donors, families and senior devotees. |
| ☐ | Validation of temple rules | Policies, workflows, service categories, capacity rules and payment constraints, confirmed by the people who own them. |
| ☐ | A clickable prototype | A working mobile design the board and devotees can tap through and react to — not code. |
| ☐ | A limited pilot | One recurring pooja and one major event or festival. |
| Decision | Why it is needed now | |
|---|---|---|
| 1 | Who is the temple's decision owner for this work? | Discovery stalls without one named person who can settle questions between meetings. |
| 2 | Which recurring pooja and which festival should the pilot use? | The pilot needs a monthly service and a high-attendance day, chosen with the priests. |
| 3 | Whom may we interview, and over what period? | Interviews cannot begin without the board's permission to approach priests, volunteers and donors. |
| 4 | Which policies and service rules must be validated first? | Some rules — capacity, cancellation, what a private service request commits the temple to — block design until settled. |
| 5 | What would make the board judge the pilot a success? | Better agreed before the pilot than argued after it. |
Discovery and interviews → prototype → validation with leadership → pilot scope agreed → pilot on two real events → return to the board with findings and a costed recommendation.
Cost and duration are estimated only after discovery. Known cost drivers: number of integrations, whether payments run through the existing store or a new route, content migration volume, and ongoing volunteer time to keep the app current.
The smallest useful step is item 3 alone — validating temple rules and workflows on paper. That work is reusable whether or not an app is ever built, and it can be stopped at any point with nothing lost but time.
All app screens shown in the accompanying deck are conceptual designs. Nothing has been approved, purchased or built. Sources reviewed September 2026.
← Back to the presentation