Case Study · St John's
Digitizing Everything A Church Does
- Role
Lead Full Stack Engineer
- Timeline
Sep 2025 - Present
- Surfaces
Member app
Staff dashboard
Counter POS
Public site
- Stack
Expo
Next.js
NestJS
Postgres
Stripe
Overview
Everything the parish does now runs through one platform.
The cafe took payments through Square. General information sat on a website nobody opened. Announcements went out over group chats. Orders reached the kitchen because somebody said them out loud. Four separate ways of working, none of which knew the others existed. Today one app covers what members do, one dashboard covers what staff do, and both run on the same backend.
Impact
- 278
- active users on the mobile app.
- ~150
- food and cafe orders a week, in the app and at the counter.
- 1
- engineer, from an empty repo to production.
What It Covers
- 01Daily scripture, church news, and upcoming events.
- 02Food and cafe ordering, in the app and in person at the counter.
- 03Venue bookings with deposits, blackout dates, and a refundable bond, shipping now.
- 04A Sunday school and document library.
- 05Donations, with tax-deductible receipts issued automatically.
- 06Push and email notifications, plus SMS when a cafe order is ready.
Why One Platform
Every tool the parish had ended at its own edge.
Square knew a coffee had been sold. It did not know who bought it, that the item was nearly out of stock, or that the same person had the hall booked on Saturday. A group chat is not a system of record either, because the message scrolls away and whoever was not in the chat never got it. Buying four more tools would have added four more edges.
The Platform
Four surfaces, one backend, one permission model.
A member app, a staff dashboard, a counter POS, a public site, and one API behind all four. What makes it a single platform rather than four apps sharing a database is the permission model: eight roles map to named feature gates, and admin navigation, route protection, and API authorization all defer to that same mapping instead of each encoding its own rules. Access changes in one place and every surface obeys it.
Built In Layers
You do not centralize a parish in one release.
The order was deliberate. Content first, because a late announcement is an inconvenience. Then money, because a wrong charge is somebody's money. Then the counter hardware, then scheduling, then tax compliance. Each layer had to hold up in production before the next one was worth building on top of it, which is why ten months separate the first screen shipped from the receipts release now going out.
Features
Two Menus, One Engine
Shepherd's Table and Chapter 6 Cafe are one system wearing two faces. They share tables and diverge by rule: cafe items are always visible while food runs in curated selling groups, and every customization option can carry its own stock independent of the item it belongs to.
Venue Bookings
A request can span the church and the hall at once. Both dates lock together or the whole submission fails, so two families cannot end up holding the same Saturday. Admins layer blackout dates over the top, and a refundable bond is taken and returned through the same flow. Built and signed off on staging, releasing to the parish now.
In-Person POS
An Android tablet takes tap-to-pay at the counter, and a second terminal lives inside the staff dashboard. Cafe orders print stickers server-side no matter which one took them, which removed the last step that ran on somebody remembering it.
AI Church Assistant
Members ask the app what is on this week, or what the church teaches, and get an answer grounded in the parish's own events and material rather than a search result. It has a daily message budget, so a runaway conversation cannot run up a bill.
One Permission Model
Eight roles, named feature gates, and an audit log that records every write an admin makes. A volunteer who only runs the cafe never sees a booking, and every approval traces back to a person.
Key Insight
A parish runs on volunteers, so no screen can assume it is being used twice.
The person approving a booking might do it once a month, and nobody trained them. That is why every admin write lands in an audit log, why the onboarding guide reads as plain English rather than documentation, and why destructive actions state their consequences instead of trusting familiarity.
Final Designs
