Member records and households
Search and filter people, group them into households, and tag them. Small groups and volunteer teams point back to the same records, and you can export the people list as a CSV.
- Households
- Tags
- Groups
- CSV export
Church management software
Pews.
I built Pews for everything a church does to get ready for Sunday.
The full app covers member records, service planning, check-ins, and giving, with a Go backend and a SvelteKit front end. What's open to churches right now is smaller: an early-access tool for follow-ups and volunteer gaps that works alongside Planning Center.
pews.Sunday workspace
SERVICE OVERVIEW
Getting ready for Sunday
1
Service planOrder of service · songs · notes
2
Volunteer assignmentsTeam positions · availability
3
Check-in deskPeople · attendance · medical alerts
Illustrative UI · sample data
No real church records
No real church records
239commits in the reviewed repository
90Svelte page route files
41SQL files in the embedded migration set
23top-level API test functions
Counted from the code in November 2026. The test number is how many API tests exist. I didn't run them for this page, and none of these numbers say anything about usage.
Why I built it
I spent years as a worship pastor before I moved into tech. Every Sunday ran on five different apps that didn't know about each other. I wanted one place where a person's household, their small group, their volunteer schedule, and their attendance all lived together.
So the app is built around how those things connect. A service plan has its songs in order. A volunteer has a position and the dates they're away. A check-in points back to a person, and a gift points to a person and a fund. Most of the real work was getting those links right.
How the pieces fit together
The staff screens and public pages are SvelteKit. Behind them is a Go API using Chi, which checks a login token on every protected route. PostgreSQL holds the church records, and each record is tagged with its church so database rules can keep churches apart. Giving runs through Stripe Connect, which handles checkout and sends payment events back.
scroll to see the full diagram →
What's in the app
All of this exists in the code. Not all of it is in the early access.
Services, songs, and volunteers
Plan a service in order, pull songs from a searchable library, reuse templates, and assign teams. When someone marks a weekend off, the scheduler flags the conflict.
- Service templates
- Song library
- Team schedules
Check-ins with context
Each event and check-in station records who came in and who left. A check-in can show medical alerts, and the app keeps a list of who's allowed to pick a kid up. That list alone isn't a child-safety system, and I wouldn't sell it as one.
- Attendance history
- Medical alerts
- Pickup records
Donation records and checkout code
Funds, donor history, recurring gifts, and year-end giving statements as PDFs, all on top of Stripe Connect. The app checks Stripe's signature on every payment event before trusting it. None of this is in the early access yet.
- Stripe Connect
- Fund tracking
- Statement PDFs
What I'd check before real church data goes in
Church records hold addresses, giving history, and medical notes. That raises the bar for calling anything ready.
Make sure each church only sees its own data
The code tags queries by church and has database rules to match. I still need to confirm the right church follows each request through to the database, and test it with the real database account. A rule on paper doesn't prove it caught a given query.
Know which database changes actually run
The backend bundles one folder of SQL changes and runs them at startup. There's a second migrations folder in the repo that it doesn't run. If a change lands in the wrong folder, it never happens.
Don't confuse having tests with passing them
The API tests cover logins, people, groups, giving, check-ins, and one church trying to read another's data. They need a running server and database. I didn't run them for this page, so I'm only saying they exist.
What building it taught me
When an app does this many things, the hard part is where they meet. One person shows up in five places, each with its own rules.
Domain modelingStart with the relationships
Someone can be in a household, a small group, and the worship team at once. Shared records make that useful. They also mean you have to decide early who can see what, and what happens when someone's deleted.
Integration workTrace the whole payment path
Sending someone to checkout is the easy part of giving. The real work is catching what Stripe sends back and putting it on the right person and the right fund.
Release disciplineRead past the completion summary
A screen can look done while its API routes are still commented out. A notification can report success without sending an email. I check the whole path now before I call anything finished.
Product scopeMake room for a smaller first use
I built a lot. Churches don't switch systems easily, though, so the early access starts small: weekly follow-ups and volunteer gaps, next to the Planning Center they already use.
What this page doesn't claim
- The code does far more than the early access offers. Pews isn't replacing Planning Center right now, and I haven't confirmed the Planning Center connection is ready for real use.
- The last commit was March 23, 2026, and some things aren't finished. The worship-planning API routes are commented out, and one volunteer email still doesn't actually send.
- It hasn't had an outside security audit or any compliance certification, and I haven't proven churches are kept apart in a live system.
- There are no church customers, revenue, uptime, or load numbers here, because I don't have any to show.
If your team builds workflow software, let's talk.
I'm looking at hands-on systems and product engineering roles. I'm happy to walk through the data model, the API, and what I'd check before trusting it with a church's records.