Celeiro de Aruanda
Operational system + public transparency dashboard for an Umbanda temple: mobile-first, real-time accountability.
- Year
- 2026
- Role
- Full-stack development, design and UX
- Status
- Live
- Complexity
- Very High
For whomTemple volunteers (any age, 100% on mobile) plus the community following the public dashboard
The case
Problem
An Umbanda temple, 100% volunteer-run, with high donation volume and continuous support to families and institutions. Registrations, stock, deliveries and reporting lived in scattered spreadsheets, with no unified history and no reliable way to show the community the real impact.
Solution
I consolidated donations, stock, deliveries and beneficiary registration into a mobile-first system with role-based RLS (admin, coordination, volunteer). On top of it, the public transparency dashboard recalculates impact in real time (kg of food converted into meals, food parcels and days feeding a family), shows the latest delivery and generates a shareable image to rally new donors.
Outcome
- Volunteer logs a delivery from their phone in seconds
- Coordination sees stock and priorities on one dashboard
- Community follows donations through the public dashboard
- Supporters see themselves named on the Gratitude Wall
399.5 kg
food donated
227
people served
97%
of donations already reached beneficiaries
Architecture
React 19 + Vite on the front, Supabase on the back (Postgres with role-based RLS, Storage, Auth and Edge Functions). The public dashboard recalculates KPIs in real time. Mobile-first to the bone, designed for a volunteer logging a delivery on the street.
System modules
8 modules integrated in the same database, same auth, same design system.
Stock
Control of what comes in, goes out and sits idle.
- Inflows, outflows and adjustments with justification
- Expiration and minimum-stock control
- "What we need right now" list
Donations
Record and history of everything that arrives.
- Donation registration (item, quantity, donor)
- History per donor and per period
- Anonymous donations with aggregated count
- Recurring donations
Deliveries and visits
Schedule and record what goes out and who is visited.
- Pending, scheduled and completed deliveries
- Shared visual calendar across volunteers
- Record with date, recipient and items
- History per beneficiary and per family
Beneficiaries
Registration of families and institutions served.
- Mobile-first registration wizard
- Families aggregated by neighborhood
- Partner institutions
- Delivery history per beneficiary
Donors
Who sustains the operation.
- Complete donor record
- Contribution history
- Public Gratitude Wall
- Linked to the donation-registration screen
Reports and KPIs
The entire operation turned into numbers.
- Operational dashboards by period
- Spreadsheet export
- Public calculation memo for every metric
Public transparency
External dashboard open to the community.
- Impact recalculated in real time
- Kg → meals, food parcels and days conversion
- Latest delivery visible on the home page
- Shareable impact-image generator
Users, permissions and audit
Control over who does what plus a trail of every edit.
- Differentiated roles (admin, coordination, volunteer)
- Who edited, what, when
- Audit filter by user, module and period
- Full trail for accountability
Architecture decisions
How the project evolved: technical choices, what changed and why.
Scattered spreadsheets → single database with role-based RLS
Before
Registrations, stock, deliveries and donations lived in separate spreadsheets, with no unified history and no edit traceability.
After
Single Postgres model with Row Level Security per role (admin, coordination, volunteer) and an audit trail of every edit.
WhyA 100% volunteer-run operation needs traceability with zero training. RLS enforces the rule in the database, regardless of the front-end.
Static reporting → live-recalculated dashboard
Before
Impact reports came out as monthly PDFs, already outdated and ignored by the community when they finally landed.
After
Public dashboard that recalculates impact in real time and converts kg of food into meals, food parcels and days feeding a family.
WhyTransparency only mobilizes if it's current and readable. A public calculation memo grants credibility without needing to explain a spreadsheet.
Desktop-first → mobile-first to the bone
Before
Admin systems assume the volunteer sits at a desk, a situation that simply does not exist in this operation.
After
Every screen designed for mobile first: registration wizard, delivery logging and dashboard fit in the hand, at any age.
WhyVolunteers log deliveries at the family's doorstep, not at a desk. If it doesn't fit on the phone, it doesn't happen.
Tech stack
Technologies
Integrations
Have a similar project?
If you recognized your business in any of the challenges above, let's talk about yours.
Other projects
See all →
Heavy-duty tire catalog with filters, installments and admin panel: built for a truck-tire specialist.
Platform for an aesthetics brand split into 3 pillars: Studio live, Class and Store on a waitlist, with flows by decision stage.