1. Who is responsible for what
This is the most important thing in this document, so it comes first. There are two different relationships here, and they carry different responsibilities.
For the data your ministry holds about its members — contacts, donors, attendance, course progress, giving history — your ministry is the data controller. It decides what to collect, why, who may see it, and when it should go. Harvest is the data processor: we store and process that data on your instructions, in order to run the service you are paying for, and for nothing else. We do not sell it, we do not rent it, we do not use it to build advertising profiles, and we do not use one ministry's member data to serve another.
For the data about your ministry's own relationship with Harvest — the administrator who signed up, billing records, support conversations, and the analytics of this marketing site and of the application itself — Harvest is the controller, because those are our decisions rather than yours.
That split is why a member who wants their record corrected or removed should ask their church, and why a church that wants us to delete a workspace can simply tell us to.
2. What we hold as controller
For our own relationship with your ministry we hold:
- Account details — the name, email address and workspace details of the people who administer your Harvest workspace.
- Billing records — plan, billing period, payment status and invoices. Card details are held by our payment providers, not by us.
- Support and enquiry messages — anything you send us through the contact form on this site, so we can reply and keep track of the conversation.
- Aggregated page-view analytics for this marketing site, which tell us which pages are read. They count visits; they are not used to identify you. This covers theharvest.site only.
- Product analytics for the Harvest application itself, which tell us which parts of the app are used. This covers the whole application, including the pages it serves to the public. These work differently from the site analytics above, and they record two different things depending on who is looking.
- Where someone is signed in, the event is recorded against the internal account id of that person, and against the church their account belongs to. That id is not a name or an email address, but it does stand for a single person — so it is not anonymous, and we do not describe it as such.
- Where nobody is signed in, there is no account id and no stored profile of the visitor. What the event is recorded against instead is a random device identifier, kept in that browser. It is not a name or an email address either, and we never look up who it belongs to, but it singles out one browser across visits — so it is not anonymous, and we do not describe it as that either.
3. What we process on your ministry's behalf
Everything your ministry puts into its workspace, we hold as processor. Depending on which parts of Harvest you use, that can include:
- Contact and member records, including the names of children checked in where your ministry uses check-in that way.
- Donor records and giving history.
- Attendance and check-in records.
- Course enrolments and progress.
- Content your ministry creates — posts, sermon notes, courses, documents and uploaded files.
- Messages your ministry sends through Harvest, and the records of them.
We process it to provide the service, to keep it secure, to back it up, and to support you when you ask. If your ministry checks children in, the records that creates are treated exactly like any other data you control: held on your instructions, visible to the people you give access to, and deleted when you tell us to delete them.
4. Where the data lives, and who else touches it
Harvest runs on infrastructure operated by other companies. Workspace data is stored in Firestore on Google Cloud; files and media are stored in Cloudflare R2; the site and application are served from Vercel.
These are our sub-processors — the parties that handle data in the course of us running the service:
- Google Cloud (Firebase and Firestore) — the database and authentication behind every workspace.
- Cloudflare — file and media storage (R2), and network delivery.
- Vercel — hosting for this site and the Harvest application, and aggregated page-view analytics for this site.
- PostHog — product analytics inside the Harvest application, its public pages included: which screens are opened, recorded against an internal account id where someone is signed in and against a device identifier where nobody is, rather than against a name or an email address.
- Stripe — subscription payments, and the Stripe Connect rails your ministry uses to take gifts.
- Dodo Payments — subscription payment processing.
- Resend — transactional email, such as sign-in links, receipts of our own billing, and notifications.
- Upstash — queues, caching and rate limiting.
Each of them handles the data for the purpose named above and no other. We do not share your ministry's data with anyone else, and we do not disclose it to third parties for their own purposes.
Product analytics sits apart from the rest of that list. It is held by PostHog on PostHog's own cloud infrastructure, separately from your workspace data: your workspace records are in Firestore, and the analytics are not stored with them, nor necessarily in the same country.
What that processor is not allowed to do matters more than what it does. There is no session recording — the application does not capture or replay what is on your screen, and the code that would do it is switched off and blocked from being downloaded at all. Nothing is collected automatically from the page: what you click, type, copy or hover over is not read. Errors are not sent to it either.
What is sent instead is a short, fixed list: that a screen was opened; which of three kinds of screen it was — an admin screen, a member screen, or a public one; and, where the person is signed in, the internal account id of that person and the church their account belongs to. No names, no email addresses, no giving, no message or prayer content.
The screen is recorded as its route pattern and never as the address actually visited. A form opened at /form/aB3xQ is recorded as /form/[formId]; the identifier in the address — which form, which event, which blog post, which check-in — is replaced before anything leaves the browser, and an address the application does not recognise is recorded as /[unrouted] rather than passed through. The same replacement is applied to the other addresses the analytics code collects by itself, including the page address and the page you arrived from. A link followed from somewhere else keeps the name of the site it came from and loses the rest of the address.
Two things still send nothing at all. This marketing site is a separate application and sends nothing to that processor. Sign-in and onboarding are deliberately left out of it: on those screens the analytics code is never started. Not started and configured not to look — never started, because they are the screens built out of email and password fields.
One consequence of that is worth stating plainly, because it is new and because it applies to people who have no relationship with us at all. The application's public pages — a church's blog post, a form, an event or giving-campaign page, a children's check-in page — are now counted in the same way as the screens behind the login. Someone who opens one is counted without signing in, without an account, and without being asked first. Nothing about them is looked up and no profile of them is stored; what they are given is the random device identifier described above, written into their own browser, which is what lets a second visit be recognised as the same browser rather than a new one. If that browser has been signed in to Harvest before, the visit is counted against the account it was last signed in as, because it is the same browser.
Product analytics sets one cookie in your browser. It is a first-party cookie, it lasts 365 days, and it holds whichever of the two identifiers above applies — the account id if you are signed in, the device identifier if you are not — together with the current session and a record of where you first arrived from. It is set on the public pages too, which means it can be set before you have signed in or been asked for anything.
5. Payments and giving
Subscription fees cover access to the Harvest software. Congregational giving and donation features connect directly through third-party payment rails (Stripe Connect); Harvest does not hold, control or forward donation funds, and charges a 0% platform fee on them.
Practically, that means donor payment details are handled by Stripe under your ministry's own Stripe account, and Harvest never holds a card number. What Harvest stores is the record of the gift — amount, date, donor as your ministry recorded them — because your CRM, your receipting and your giving statements are built on it.
Card details for your own Harvest subscription are handled by our payment providers in the same way: entered with them, held by them, never stored by us.
6. Email
Transactional email that Harvest sends on your behalf — notifications, sign-in links, confirmations — goes through Resend.
Bulk newsletters are sent from your ministry's own Mailchimp account. Where that is how you have set things up, the contact details involved reach Mailchimp under your agreement with them, and their privacy terms apply to what they do with them.
7. How long we keep it
While your subscription is active, we keep your workspace data for as long as you want it. You can delete records yourself at any time, and a deletion you make in the app is a real deletion.
If you cancel, your data is retained for 12 months and then deleted. We do not spring that on you: we email a notice at 11 months, and a second notice at 11.5 months, before anything is removed. Within that window you can export everything, or resubscribe and pick up where you left off. Export is never gated behind a payment.
If you ask us to delete a workspace sooner than that, we will delete it. Backups age out on their own cycle shortly afterwards.
8. Security
Data travels over encrypted connections, and our infrastructure providers encrypt it at rest. Access to a workspace is controlled by the roles your ministry assigns, so a volunteer sees only the part of the workspace you have given them.
Access by the Harvest team to a ministry's workspace data is limited to what is needed to operate the service and to support you when you ask for help.
No system is perfect. If a breach affects your ministry's data, we will tell you what happened, what was affected, and what we are doing about it.
9. Making a request
If you are a member of a church that uses Harvest and you want to see, correct or remove your record, ask your church. They control that data, and they can act on it directly in their workspace. If they need our help to answer you, we will help them.
If you administer a Harvest workspace and want to see, correct or export what we hold about you, or want your workspace deleted, contact us and we will do it.
10. Changes to this policy
When this policy changes, the updated version is published here and the date at the top changes with it. Where a change materially affects how we handle data, we will email workspace owners.
11. Contact
The quickest way to reach us is the contact form at theharvest.site/contact. It goes straight to the Harvest team, and we answer every message.