Security & your data

You’re considering trusting us with your congregation’s contact details and your church’s giving. Here is exactly how that works, in plain terms — including the parts we haven’t built yet.

Your church’s data is separated by the database itself

Every record belongs to one church. That isn’t enforced by remembering to add a filter in the right place — it’s enforced by PostgreSQL row-level security on every one of the seventy-odd tables that hold church data, with FORCE set so the rule applies even to the account that owns the database. Each request opens a transaction that declares which church it is acting for, and the database refuses to return anything else for the life of that transaction.

Practically: if we wrote a bug tomorrow that forgot to filter by church, the database would return nothing rather than another church’s people.

Where your data physically sits

Your database runs on Neon in Amazon’s US East (N. Virginia) region, and the application runs on Vercel. Everything travels over HTTPS and is encrypted at rest by the hosting providers.

On backups, we’d rather give you the real number than a comfortable one: we can rewind the database to any point within the last 24 hours. That covers the common disaster — a bad import, a mistaken bulk delete, something noticed the same day. It does not cover a problem you only discover a week later. So if you are about to do something drastic, take an export first (it’s one click), and keep your own copy of anything you couldn’t bear to lose. We are working on a longer window and will say so here when it changes.

We never see a card number

Online giving runs through Stripe’s own hosted checkout. Card details are entered on Stripe’s page, not ours, and never pass through PewHQ.

More than that: your gifts never pass through us either. Each church connects its own Stripe account, and charges are created directly on that account. Payouts go from Stripe to your bank. We are not a middleman holding your offering, and we could not withhold it if we wanted to.

What we send to AI, and what we don’t

Several features use an AI model from xAI: asking questions about your data, drafting sermon slides, drafting follow-up messages and social posts, generating website copy, and matching columns when you import a spreadsheet. Being specific about what that means:

• Ask your data sends your question and a description of our table structure to the model, which writes a read-only query. That query is checked against a fixed list of permitted tables and run inside your church’s own read-only transaction with a time limit. Up to 50 result rows are then sent back to the model so it can phrase the answer in a sentence — so if you ask about your top donors, those names and amounts go to xAI.
• Importing a spreadsheet sends your column headings and up to three example values per column, so the model can work out which column is which — so a few real names or amounts from your file are included. It only proposes the mapping; you approve it, and the import itself is ordinary code that never sees the model.
• Drafting features send what you typed — sermon notes, a few facts about your church — and get text back.
• AI never writes to your database and never moves money. It suggests; deterministic code and a person decide.

If you would rather no church data reached an AI provider at all, tell us — the features are separable and we would rather know than assume.

Passwords, keys and tokens

• We never store passwords. Sign-in is handled by Clerk, including social sign-in.
• API keys are stored only as a SHA-256 hash. The key itself is shown once when created and cannot be retrieved afterwards — not even by us.
• Connected social account tokens are encrypted before they are stored.
• Sensitive actions — deleting a person, recording or deleting a gift, moving money between funds — are written to an activity log your admins can read.

Your data is yours, and you can take it

Every list can be exported to CSV, and there’s a one-click download of everything as a zip, plus an accounting export for your bookkeeper. No support ticket, no waiting period, no export fee. If you leave, you leave with your data.

Removing a person hides them everywhere but deliberately keeps their giving and attendance history, because those are your financial records and a deletion shouldn’t silently alter last year’s totals. Ask us if you need a record removed outright.

Who else is involved

Running PewHQ means these companies handle some of your data:

• Stripe — payments and payouts
• Clerk — sign-in and accounts
• Neon — the database
• Vercel — hosting and uploaded files
• Resend — email you send from PewHQ
• xAI — the AI features described above
• Twilio — text messaging, once it’s switched on for your church

What we haven’t done yet

We would rather you hear this from us than discover it:

• No SOC 2 or similar certification. We’re a small, young product. If your insurer or board requires a formal audit report, we don’t have one.
• Text messaging isn’t live yet. It’s built, and waiting on carrier registration.
• We’re early. PewHQ is in early access. That’s reflected in the price, and it means you’ll get a real person quickly — but it also means we’re not a twenty-year-old company, and you should weigh that.

Ask us something

If your church has a question this page doesn’t answer — or you want a specific claim here demonstrated rather than asserted — email contact@cdmediainc.com. A real person reads it.