Taking over a synagogue system, and turning it into a platform

The client

A synagogue whose membership system was written by another developer, and other congregations looking for a modern replacement for their current software.

The challenge

The existing system worked well for one synagogue, but it was written for that one congregation, by one person. To serve others, it needed to become a properly supported, secure service that many congregations can share, each keeping its own customs and its own way of doing things.

What we're building (in progress)

Each congregation gets its own secure space and switches on only the modules it needs. 27 of the 30 planned modules are built, including:

• Members, families and yahrzeits (memorial anniversaries) on the Hebrew calendar
• Membership dues, whether fixed, sliding-scale, "fair share" or pledged, with invoices, payments and statements
• Donations with HMRC Gift Aid claims, following the rules on time limits and donor benefits
• Service times, set relative to sunrise and sunset, and honours
• Hall and mikveh (ritual bath) bookings that can't clash, even when two people book at the same moment
• Cemetery plots, funerals and stone settings
• Hebrew school, bar and bat mitzvah classes, the library, plaques and volunteer rotas
• Mailshots and text messages, checked by a second person before they go, and never sent on the Sabbath or festivals
• Data-protection requests, tracked against the legal deadline
• Tools to find and fix duplicate people, missing links and inconsistent records

Every congregation does things its own way

Congregations follow different customs, and the platform follows them rather than the other way round. A congregation starts from a preset for its tradition, from UK Orthodox to Sephardi, Chabad, Masorti or Reform, with the right wording throughout. Customs can then be set for the whole congregation, a family or a single person, and they decide how dates such as yahrzeits are worked out. Lists, settings, fields, roles and invoice numbering can all be changed without a developer, and the calendar works for Israel as well as elsewhere.

Safe by design

Staff sign in with passkeys or two-factor codes. Each congregation decides who can see and change what, down to individual sensitive details, and every permission is checked on the server, not just hidden on screen. Two people editing the same record can't overwrite each other, and every change is recorded in an audit log without copying personal details into it.

Checked from every angle

Before going further, we ran an independent, adversarial review of everything built so far and fixed what it found. Around 1,000 automated tests now cover the platform, including tests against a real database and a browser check that opens every page as thirteen different kinds of user.

Technical details

A Blazor web application on .NET with MongoDB, migrated from a single-site SQLite version. Congregations are resolved by subdomain, modules are switched on per congregation, and documents are stored per congregation in Azure Blob Storage. Email and SMS go through Azure Communication Services; congregations subscribe through Stripe.

Server-side permission checks on every write, optimistic concurrency, per-congregation time zones and a configurable permission grid with custom roles and sensitive-field tags. Tax receipts are pluggable, with UK Gift Aid and US year-end statements. About 840 unit, 110 integration (against a disposable MongoDB) and browser smoke tests that load 163 pages as 13 users, plus Stryker mutation testing.

• C#
• .NET
• Blazor
• MongoDB
• Azure