Church Management Platform

About This Document

This document summarizes the technology behind Church Management Platform for church leadership and decision-makers. It covers the technology stack, API capabilities, security practices, data management, and hosting—with enough key terms to discuss with technical advisors.

How It Works

The system has two main pieces that work together: a backend server (handles data, business rules, and security) and a frontend interface (what people see in the browser). They communicate through an API—a structured set of commands that keeps everything organized and secure.

Technology Stack

Every piece of technology below is open source or industry standard—widely used, well-documented, and supported by large developer communities. This means there is no vendor lock-in and any qualified developer can maintain or extend the system.

Backend (Server-Side)

Database

Frontend (What Users See)

Third-Party Services

Platform Integrations

API & Integration Capabilities

The system is built API-first, meaning every feature is available through structured, documented REST endpoints. This is the same architecture used by modern services like Stripe, Twilio, and Google.

What This Means in Practice

• Mobile app — the companion mobile app (React Native, iOS & Android) uses the exact same API as the web application, with zero backend changes. See the Mobile App documentation.
• Third-party integration — full two-way Planning Center sync is live and operational; other church tools (giving platforms, volunteer scheduling, worship planning) can connect through the same API.
• Kiosk independence — the lobby kiosk runs as a lightweight client calling the API, meaning kiosk hardware can be swapped without touching the server.
• Separation of concerns — the database, server logic, and user interface are independent layers. Any one can be updated or replaced without disrupting the others.

API Coverage

The REST API currently provides over 80 endpoints organized into these areas:

Security

The system uses multiple layers of industry-standard security practices:

• JWT authentication — every request is verified with a signed token (the same mechanism used by banking and healthcare applications).
• Role-based access control — eight defined roles (Super Admin, Admin, Staff, Event Coordinator, Check-In Admin, Group Leader, Volunteer, Member) control who can see and do what. Admin-only features are enforced on the server, not just hidden in the interface.
• Password hashing — passwords are stored using BCrypt, a one-way hash. Even database administrators cannot see user passwords.
• HTTPS encryption — all data in transit is encrypted via SSL/TLS certificates (managed automatically by Let's Encrypt).
• Phone verification — new accounts verify their phone number via a one-time SMS code (Twilio Verify API) before accessing the system.
• Child safety codes — check-in generates a unique security code that must be presented for child pickup.

Feature Modules

The platform is organized into independent feature modules that can be enabled or disabled per deployment. This allows each church to tailor the system to their needs — turn on only the modules you use, and keep the interface clean.

Available Modules

How It Works

• The Superadmin manages modules at Configuration → Feature Modules using simple on/off toggles.
• When a module is disabled, its sidebar items are hidden and its routes are blocked. If someone navigates directly to a disabled module's URL, they see an informational page explaining that the module is not currently active.
• Dashboard buttons and Recent Activity filter chips also respect module status — disabled modules won't clutter the interface.

Church Branding & Customization

Every deployment is branded to your church through application settings — no code changes required. The platform reads church identity information from configuration and displays it consistently across the web interface, mobile app, emails, and SMS messages.

What Can Be Customized

• Church logo — displayed in the web header bar, login/registration/password-reset pages, kiosk check-in header, and the mobile app home screen
• Church name & display name — used in page titles, email from-name, email subjects and body text, SMS verification messages, and the header bar. The display name is computed automatically (see below)
• Tagline — shown on the mobile app hero banner
• Service times — parsed and displayed on the mobile home screen church info card
• Contact information — address, phone, email, website, and mailing address
• Giving methods — Zelle email, Venmo handle, CashApp handle, and bank ACH details shown on the Give page. Empty values are automatically hidden from the interface
• Tax status, livestream URL, and external giving link — available for use across the platform

Display Name Logic

The platform automatically computes a display name from the church name. This display name appears in the header, browser tab titles, emails, and SMS. The logic handles three cases:

Logo Contains Church Name (LogoIncludesName)

When a church’s logo image already contains the full church name, the LogoIncludesName setting should be set to true. In this case, the platform hides the church name text next to the logo and shows only the platform suffix — avoiding redundancy. The suffix shown depends on whether the church name ends with “Church”:

When LogoIncludesName is false (or not set), the full computed display name is shown alongside the logo as described above. Browser tab titles always use the full display name regardless of this setting.

Where Branding Appears

Configuration Reference

All branding fields are configured in the Church section of application settings. Every field is optional — empty values fall back to sensible defaults or are hidden from the interface.

Data Management

Current Data

The database holds the church's operational data: approximately 5,800 people, 1,800 families, 150 groups, and 7,300 group memberships. This is the church's system of record, replacing legacy church management software.

Automated Data Archival

As the system accumulates check-in and attendance records over time, an automatic archival process keeps the database lean and fast. Here's how it works:

• Real-time tables (check-ins, registrations) hold only the most recent two months of data—optimized for the fast read/write speeds that kiosk check-in demands.
• Once a week (Sunday at 3:00 AM), an automated script moves older records into compact long-term storage within the same database. Hundreds of individual check-in records compress into a single summary row per event.
• All historical data remains fully queryable for attendance reports and per-person history.

Proof-of-concept testing showed this approach can handle years of data efficiently: 62,000 check-in records compressed into 105 summary rows—a 99.8% reduction in row count while keeping every data point accessible.

Hosting & Deployment

Where It Runs

The application is hosted on a Virtual Private Server (VPS) running Ubuntu Linux—the most widely-used server operating system in the world. The server is provisioned through Hostinger, a mainstream hosting provider.

• Domain: accessible via a custom HTTPS domain
• SSL/TLS: certificates auto-renewed by Let's Encrypt (free, industry standard)
• Reverse proxy: Nginx handles incoming traffic and serves the frontend
• Process management: systemd ensures the application auto-starts on server reboot

Deployment Process

Updates are deployed by building the code locally and copying the compiled files to the server. The process takes about two minutes and causes less than 10 seconds of downtime (service restart). Database schema changes can be deployed independently when needed.

Industry Standards & Best Practices

Key terms a technical reviewer would look for:

Backup & Reliability

Protecting church data requires more than just a good database — it requires automated backups, off-site storage, and tested recovery procedures.

Automated Daily Backups

Every night at 2:00 AM, the server automatically creates a complete snapshot of the entire database — every member record, family, group, event, check-in, donation, and attendance record. These backups are compressed and stored locally with 14 days of history.

Off-Site Cloud Storage

Each backup is automatically copied to off-site cloud storage (a separate data center). This means that even if the physical server were completely lost (hardware failure, data center issue), your data is safe in a geographically separate location.

Backup Verification

Having backups is only useful if they actually work. Every week, the system automatically restores the latest backup to a temporary database and validates it — confirming that records are present and the data is intact. This catches corruption or incomplete backups before they’re ever needed.

Recovery Capabilities

Uptime Monitoring

An external service checks the platform every 5 minutes from outside the server. If the site goes down for any reason, administrators are notified immediately by email — often before any church members notice.

Options for Larger Churches

For churches that need higher availability and near-zero data loss, the platform architecture supports additional infrastructure options:

• Database replication — a live standby database that stays seconds behind the primary, ready to take over if the primary fails.
• Managed database services — cloud-hosted database with automatic failover, point-in-time recovery, and built-in monitoring (additional monthly cost).
• Multi-server deployment — multiple application servers behind a load balancer for higher capacity and zero-downtime updates.