SNE Częstochowa is a Catholic evangelization community that has run retreat courses and events since 2011, across ten local schools, by volunteers. We built its first app, then rebuilt it in seven weeks and moved the organization’s courses into it, from the sign-up to the settlement. The app is what people see. The process is what changed.
Payments that match themselves
Online payments land on the participant’s record automatically, instead of someone matching bank statements to course lists.
Sign-up without a coordinator
People sign up in the app or from the website, answer the course’s own questions, and get every follow-up message on schedule.
One view of the organization
Every course’s stage, every payment and every member’s history in one place, instead of on the director’s phone.
The Situation
SNE is not a small operation. Hundreds of members are organized into dozens of groups across ten local schools, each group with its own leaders. Hundreds of people take part in its courses every year, and every course is staffed by a volunteer crew. Every course follows the same arc: preparation, sign-up, checking who has paid and who is coming, the course itself, then a settlement of money and attendance and a review. The community has run that arc for years. What it ran on was people.
Sign-ups arrived through a form on a website more than a decade old. Each one sent a confirmation to the participant and a copy to a shared mailbox, with a promise that details would follow two weeks before the course; a volunteer with access to that mailbox removed cancellations by hand. Payment meant a bank transfer, and one person with access to the account matched transfers against each course’s own list. Crew members applied through a separate online form. Who had attended or served on which course, and who belonged to which group when, was spread across an old member database, group lists and spreadsheets. The state of the whole organization was visible to one person, on one phone.
The community already had an app: we built its first version a year earlier, for news, events and groups. It ran inside a web view, and its history was a list of workarounds for the framework rather than for the product. The course work still happened outside it.
What We Did
Seven weeks to the stores
A native rewrite of the app, from the decision to rebuild to the App Store and Google Play.
Payments from day one
Online payments switched on two days after the release and took their first payments within a day.
Nothing thrown away
Every original data model kept and extended, with automated tests grown from 66 to 799.
We rewrote the part that was fighting its framework and kept the part that worked. The app was rebuilt natively on Expo, with the old app as the reference for how every screen should behave. The Django backend stayed and grew: every original data model kept, new modules for messaging and payments, and the process rules added on top. A small senior team did it, a lead developer and QA, with AI doing much of the typing. The first working version of the new app, from sign-in to the course catalogue and participant lists, came out of Claude Code in the first two days, built against architecture decisions written before any code. The remaining weeks went into what makes software like this hold: the rules of the process, the tests, QA and review.
The course lifecycle became something the software enforces rather than something the director remembers. A course moves through its stages on its own dates: registration opens and closes when it should, and a course that has ended moves itself into settlement overnight. Settlement cannot be submitted until attendance is marked, the finances are in and the required summary questions are answered.
Course details open to all participants, and participation management layer for manager.
Sign-up and payment now happen in one place. The community’s website lists the season’s courses straight from the platform and hands the sign-up to it, with each course’s own questions: dietary needs, parish, previous courses. Payment runs online through Tpay and is matched to the participant automatically, with a bank transfer as the fallback. Crew members owe nothing, as a rule in the system rather than a note to the treasurer. Members apply to serve on a course from the app, and the director approves or declines.
Every new course starts with a default schedule of six messages, from the sign-up confirmation to the note after the course, plus messages to all participants or the crew by email or SMS. Each member carries one history: the courses they attended or served on, their service roles, and the groups they belonged to over time.
A settlement that will not submit until attendance and the required summary answers are in, and a message to everyone on the course.
What Moved
The organization’s courses now run through one system instead of forms, mailboxes, bank statements and phone calls:
- Sign-up: from a web form and a shared mailbox to a self-service sign-up, in the app or from the website, with the course’s own questions.
- Payment: from bank statements matched by hand to online payments matched automatically. They took their first payments within a day of switching on.
- Crew: from a separate form and phone calls to a request in the app that the director approves.
- Messages: from emails written per course to a schedule every course starts with.
- Settlement: from an ad hoc reckoning per course to a stage every course enters when it ends, which will not close with anything missing.
- Oversight: from one person’s phone to every course’s stage visible in the app.
Underneath, the season’s 19 courses sit on a backend that was extended, not replaced, with its automated tests grown from 66 to 799 and checks that run on every change.