Harvest speaks English, and only English.
The interface would be translatable, so a congregation that worships in two languages could read the app in both.
Every screen, email and notification is English. A member who does not read English gets an English app, and there is no setting that changes it.
- Translating the member app first, where most of the reading happens
- A per-member language choice rather than one setting for the whole church
- Right-to-left layouts costed separately — mirroring a layout is not the same job as translating it, and assuming translation covers it is how it gets skipped
Planning Sunday still happens in a spreadsheet and a group chat.
An order of service your team plans together — songs, people, timings — instead of a document somebody emails round on Thursday.
Harvest runs events, check-in and the livestream. It does not plan the service itself: there is no order of service, no song library and no rota.
- A song library carrying keys and CCLI numbers, with chord charts attached
- Rehearsal scheduling with availability and blockouts, so the conflict is caught before Sunday
- Recurring templates, because most services are last week with three things changed
Applications arrive as email, and end up retyped into a spreadsheet.
A review pipeline on top of the forms Harvest already collects — several reviewers scoring the same application, and the acceptance letter generated from the decision.
Forms collect submissions, export to CSV and link to a CRM contact. Everything after that — status, reviewer notes, the contract or the rejection — happens outside Harvest.
- A status on each submission, so an application can be somewhere rather than just received
- Multiple reviewers with scores and notes on one application — the part a spreadsheet handles worst
- The acceptance or rejection document generated from the decision, as a fixed template with merge fields
- No e-signature. That is a different product and pretending otherwise would be the sixth thing this site had to correct
There is no manual. There should be.
A documentation site an admin can search at the moment they are stuck, instead of working it out from the interface.
Harvest has a contact form and an FAQ. Neither is documentation: nothing explains how a feature works, in order, in one place you can link a volunteer to.
- A separate site at its own address, so it can be indexed and linked without touching the app
- Written per admin task, not per screen — the question is usually "how do I take a registration", not "what is this button"
- A decision recorded rather than a design settled — the tool and the shape of it are both still open
Harvest is your app. It is not your website.
A church site you could build and edit inside Harvest, drawing on the events, sermons and giving pages already in your account.
There is no website builder, no page builder and no template gallery. What exists is branding — your domain, logo and colour on the Ministry plan — and editors for your blog, documents and sermon notes. An earlier draft of our own Terms claimed a website builder and had to be corrected; this line is the correction holding.
- Pages that read live from your Harvest data, so a service time is not typed in two places
- Publishing to the domain a church already points at Harvest
- This one is furthest out of everything on this page
An assistant that does the work, not one that answers questions.
An agent working inside the admin — drafting, filing and chasing across Harvest and the tools a church has already connected.
Admin work is manual. Every newsletter, every follow-up and every record is typed by a person, and nothing in Harvest acts on an admin's behalf.
- Acting across the admin surfaces rather than talking about them
- Reaching the tools a church has already connected, not just Harvest's own data
- Months of work, sitting behind the things churches are paying for today
This is not AI Chat, which already ships. AI Chat is for your members: it answers their questions from your own teaching, and it is part of the Small Team and Ministry plans at no extra charge. This one would be for your staff, it would take actions rather than answer questions, and it does not exist.
A person at two churches needs two accounts.
One identity that carries across churches, with a separate role at each — a worship leader at one and a member at another, signing in once.
Accounts are per church. Somebody who serves at two has two logins and two profiles, and nothing connects them.
- A single identity with per-church membership and roles hanging off it
- Existing accounts migrated first, so nobody has to start again
- Security-critical and weeks of work. It is a permissions rewrite, and the risk of getting it wrong is one church seeing another's data
A donor can give, but cannot say what for.
Funds a church configures — General, Missions, Building, Benevolence — that a donor picks at the moment of giving and that follow the gift into every report.
Giving goes to one undesignated pot. A church that runs a building fund tracks it outside Harvest, or asks donors to write it in a note.
- Funds the church defines, rather than a fixed list we choose
- The designation carried into receipts, statements and exports — a fund that only exists on the giving page is worse than none
- It touches every path that writes a donation, so it is not a small change
Missing something that is not on this page?
Tell us. What churches actually ask for is how this list gets ordered, and a request from a real ministry outranks a good idea we had on our own.