Drawing 02.7, nonprofit site and back office
Journey to Jericho
The site and back office for a faith-based mentorship ministry in Columbia, Tennessee that fathers the fatherless through the work of a motor shop: the mission, a formation track, mentor and volunteer applications, events, and giving.
| No. | Part | What it does here |
|---|---|---|
| 1 | Browser | Visitors read the mission, apply to mentor or volunteer, subscribe, and give; staff run the admin. |
| 2 | Prerendered site | React and Vite, rendered to HTML per route at build and synced to S3 on each release. |
| 3 | CloudFront | One host: the site from S3, and the API and admin to the Rails function. |
| 4 | Rails 8 on Lambda | API and admin: forms, events and posters, Stripe giving, and donor accounts. |
| 5 | Neon Postgres | Submissions, people, events, gifts, and a record of every email sent. |
| 6 | SQS jobs | A queue and a Lambda that send receipts and notifications and settle Stripe events after the request returns. |
| 7 | SendGrid | Notifications, receipts, the newsletter welcome, and gift confirmations. |
Why it exists
Journey to Jericho is a faith-based nonprofit in Columbia, Tennessee that fathers the fatherless through mentorship, skill, and identity in Christ. Gifts went through a separate Church Center giving page, and the ministry needed a front door that could carry a heavy mission without feeling heavy: one where people can give, apply to mentor, refer a young man, or offer to volunteer, and a back office that answers every person who steps in. Patrick Taylor led this build; Conner worked on the parts people feel first.
How it works
Donors give once or monthly on the ministry's own site through Stripe, and sign in later by an emailed link or code to see their giving history. Mentor applications, mentee referrals, volunteer interest, and contact messages all land in one admin, where every person gets a contact history, with duplicates merged and a stage for each donor. Staff keep events and their posters in the same admin.
Nothing slow happens while a visitor waits. A submission is saved first; then a background queue sends the receipts and notifications by email and records the person in the ministry's contact history. A nightly job lays out the coming weeks of recurring events.
Underneath, the public pages are built ahead of time as plain HTML and served from storage on AWS, and the same address sends the admin and the API to a Ruby on Rails app. The ministry also has an operations handbook: who holds each account, how a release ships and rolls back, and what handing each area to someone else would take.
What it does
- The mission and a seven-pillar formation track
- Mentor applications, mentee referrals, volunteer interest, and contact
- Events kept in an admin, with posters
- One-time and recurring gifts through Stripe
- Donor accounts with giving history
- A contact history for every person, with duplicates merged and a stage for each donor
- Causes with goals and totals in the admin, and donor and gift exports
Screenshots
Something like this on your list? Tell us about it.
Talk about a build like this