The questions churches actually ask

A church can run its website, its people and households, adult check-in and connection, service planning, worship presentation, livestream production, and Bible, study and sermon work.

ChurchOS is pre-launch, so this happens by arrangement with us rather than through open signup, and no church is charged.

No. Online giving is not built. There are no donation, fund or gift records in the platform and no payment processor is connected to it.

The /giving page on this site describes what is intended and says on the page that it is not built. A church that needs online giving now should keep its existing giving provider.

No. Events and registration are not built — there are no event or registration records in the platform.

No. There is no appointment booking and no availability calendar.

No, and this one matters more than the others. There are no child, guardian, authorised-pickup or room records, and no check-in workflow built around child safety.

A church running children's ministry should keep whatever it uses for that. Do not repurpose the people directory as a children's register — it was not designed for it and would not stand up to a safeguarding review.

Not a native one in an app store. The product is built to work in a phone browser and the congregation-facing parts are designed phone-first, including the live service view a member follows during a gathering.

The pricing page shows the plans and their prices from the platform's own plan catalogue.

Nothing can be charged today: subscription billing is not built, there is no checkout and no invoice can be issued. Any church using ChurchOS at the moment is doing so at no cost.

That is not the intention. Giving is intended to be included in the plan price rather than charged as a share of what a congregation gives, with card processing fees going to the processor.

Since neither giving nor billing is built, treat that as a stated intention and not as a term. It will be a term when the terms of service take effect.

Yes, and it is the database that enforces it rather than the application. Every table holding church data carries a row-level security policy, and the policies apply to the account that owns the schema too, so there is no privileged path around them.

The test suite attempts cross-church reads in raw SQL, in both directions, on every change. A wrong policy fails the build rather than reaching a church.

Only the people the church entitled. A note restricted to pastoral staff is not visible to an administrator or to a volunteer with a broad role, and reads of sensitive records are recorded in the church's audit log.

Not yet by yourself. Self-service export is not built.

The commitment is that a church leaves with its records; the mechanism today is that you write to us and we export them by hand. We would rather describe the manual process that works than the automated one that does not exist.

No. The study and sermon features run against a language model ChurchOS hosts itself. The software can only be configured to use a local model server or a test mock; there is no code path that sends church content to a commercial AI provider.

Assisted answers must cite the source they came from or not be given.

No. There is no analytics script, no advertising pixel and no social tracking on these pages, which is why there is no cookie banner. ChurchOS sets cookies only to keep somebody signed in after they sign in.

This is the right question to ask a pre-launch supplier and it does not have a satisfying answer yet. There is no escrow arrangement and no automated export, so the practical answer today is that we would export every church's data and hand it over.

A church holding records it cannot afford to lose should keep its own copy in the meantime.

Not yet. Every church gets an address at mychurchos.app which is free, permanent and not a trial.

Connecting a domain a church already owns is not wired up, and buying one through ChurchOS is a separate piece of work that has not started.

None, and we will not publish a figure we cannot evidence. There is health checking, error tracking, blue/green deployment with a health gate, and a rollback path.

There is not yet enough operating history to state an availability number honestly, so there is no service-level agreement.

The database is backed up on a schedule with integrity checks, and restores are rehearsed rather than assumed.

Those backups are currently on the same machine as the database, which protects against a bad deployment or a mistaken deletion but not against losing the machine. Off-site backup is required before ChurchOS is sold commercially and is not in place today.

No external penetration test and no SOC 2 examination. The security page describes the protections that do exist and says the same thing about the ones that do not.

A church has roles and permissions with server-side enforcement, and staff accounts can sign in with their own credentials rather than a shared login.

Self-service invitations — an administrator emailing an invite from inside the product — are being built and are not available yet.

The presentation engine drives the main screen, stage display, stream output and congregation phones from one cue list, and it tracks song rights and reported uses.

ChurchOS ships no lyrics catalogue. Reproducing lyrics needs a licence held by the church, and shipping a catalogue without one would put every church using it in breach.