Building CFOLD: a web app from a blank page.

Church admin lives in spreadsheets, group chats and one person's memory.

Rosters get lost in WhatsApp groups, nobody notices a family drifting away until it's been three months, and prayer requests written on cards are never followed up. We set out to replace all of that with one shared system for pastors, administrators, ministry leaders, door greeters and finance and prayer teams, while volunteers and the congregation use the parts they need without ever creating an account.

Two decisions came first. We would build it from scratch rather than adapt an existing church platform, and it would be a paid, multi-church product from week one: every church its own tenant, with four roles and email invites built in from the start.

A modern stack, tuned to run on shared hosting.

• Front end — Next.js 16 (App Router) with React 19 in TypeScript, and Tailwind CSS for the app. The marketing site and help centre live inside the same app, so links churches had already shared never broke.
• Back end — server components and Server Actions with no separate API server, Prisma over MariaDB, and every query scoped to the signed-in church through one session helper, with access rules in one permissions file.
• Accounts and email — Auth.js email-and-password sign-in, plus invites, receipts, reminders and password resets sent from hello@cfold.org.
• Deployment — a push to main builds and deploys automatically, and hourly jobs (reminders, small-group check-ins, trial expiry) run from an external scheduler calling a protected URL, because the hosting plan has no cron.
• Three languages — English, Sinhala and Tamil. The church picks the language, so everyone in one church sees the same screens.

The problems worth writing down.

• Next.js on shared hosting — production builds kept crashing under the host's limits. We pinned the build to a single CPU worker, switched it to webpack, capped the database connection pool and cached the database client properly.
• Sign-in that survives a busy server — authentication used to look up the database on every request, so a struggling server could sign everyone out. We removed that lookup so sign-in only verifies the session, and errors now say what actually went wrong.
• Keeping every church's data apart — many churches share one database, so church scoping and permissions each live in exactly one place rather than being repeated query by query.
• Time zones — the server runs on UTC but churches don't, so every "which day is it?" question is answered in the church's own time zone.
• Duplicates and guessable links — the app refuses to create a second record for someone already on file and lets admins merge existing pairs safely, and shared public links moved to short random codes while old links keep working.

A first version that knows what it isn't.

Shipping fast meant saying no on purpose. There's no native app, because it's a phone-friendly web app instead. There's no online billing yet, no WhatsApp API (click-to-chat links do the job for now) and no AI features. Pricing is one monthly plan with no per-member fees, and a yearly plan was offered and deliberately withdrawn. Some features were built and then removed after feedback from the pilot church, including a pastoral notes area, a separate Pastor role and a QR code for the register.