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
The songs and the rehearsal still live outside Harvest.
A song library your team plans from — keys, CCLI numbers and chord charts — and a rehearsal that knows who is already busy.
Harvest plans the service itself: an order of service with timings your team builds together, and a volunteer rota that invites people and takes their answer. What it does not have is the worship side of that — there is no song library, no CCLI reporting, no chord charts, no rehearsal scheduling and no availability blockouts, so who can make which Sunday is still asked in a group chat.
- 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
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 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 whatever address a church reaches Harvest on
- 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. 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
Harvest does not text your congregation yet.
Broadcasts to your members, donors or a tag from a number of your own — and a keyword a member texts to that number to get their giving link back.
Nothing in Harvest sends a text. There is no broadcast composer, no automated reminder, and no keyword a member can text you. Giving happens on your branded donation page, from a link or a QR code you print or put on a slide, and every gift still writes a receipt and a CRM record the same way. Check-in, event registration and pledges confirm by email.
- A number bought from inside Harvest, so there is no separate carrier account to open before the first message goes out
- A recipient count and a segment cost shown before anything is sent — a broadcast is the one action where finding out afterwards is too late
- A keyword that answers with your giving link, so the closing slide can say "text one word" instead of spelling out a URL
- US numbers first. Per-segment rates vary about tenfold by country and pretending otherwise is how a church gets a bill it did not expect
This is not the donation page, which already ships and is how a church takes a gift today. What is missing is the messaging itself, in both directions.
Harvest has no affiliate programme right now.
A link you could share, paying you 30% of what a church that joins through it actually pays for its plan — every payment it makes in the twelve months from its first.
Nothing pays a share for a referral today. There is no place to ask for a link, nothing that reports what a link has brought in, and no money moving either way. Links shared while the programme was advertised are still recognised when someone arrives on one, so an old link keeps recording where a visitor came from — and nothing is calculated or paid against it.
- What happens when a church moves up or down a plan, or leaves partway through the year
- Plans only. The share would be worked out on what a church pays for its plan, and on nothing else it pays Harvest
- How a link would be issued, how a share would be tracked and how the money would reach the person who earned it are all still open — which is why none of it is described here
This is not a cut of anything your church receives. Giving on Harvest carries no platform fee at all on any paid plan, and a gift given through your church's own payment links never passes through Harvest at all — that is how giving works today and is unchanged. What is described here would come out of what a referred church pays Harvest for its own plan, and would go to whoever referred them.
Your app lives at a Harvest address, not one you own.
A domain you already own pointed at your Harvest app, so a member would read give.yourchurch.org in the address bar rather than an address with ours in it.
Every church is served on its own Harvest subdomain — yourchurch.theharvest.app — and that address works, is yours alone, and carries your name, logo and colour on the Ministry plan. What does not work is pointing a domain you own at it. The setting was there and was never switched on behind the scenes, so a church that saved a domain was shown DNS records that pointed nowhere and verification never finished. Anything already saved is still saved; the panel that offered it is what came down.
- Root domains and subdomains of them alike — yourchurch.org and give.yourchurch.org need different DNS records, and a church should not have to know which
- The exact records generated from what was entered rather than one fixed example, because the wrong record type silently never verifies
- A verification state a church can read, so a domain part-way through pointing says so instead of looking finished
- It rests on hosting the platform does not pay for yet, which is the whole reason the panel came down rather than being left to fail quietly
This is not your Harvest subdomain, which ships: every church already has yourchurch.theharvest.app and nothing about it changes. Nor is it branding — your name, logo, icon and colour reach your app, your receipts and your certificates on the Ministry plan, and that is untouched. What is missing is only the domain you own yourself.
Sunday gets posted six times, from six different phones.
One place to write a post, put it on a calendar and send it to every account your church runs — and to read what comes back.
Nothing in Harvest reaches a social account. A volunteer opens each app in turn, pastes the same caption, crops the same picture again, and answers comments wherever they happen to land. Harvest posts to your own community feed — that is not a social account, and nothing in the admin can see a comment left on one.
- One composer that writes a post once and sends it to every account a church has connected, with the picture and the first comment attached
- A month calendar and a queue, so a team can see what goes out on Sunday before Sunday
- Comments and messages read and answered from inside the admin, rather than in whichever app they landed in
- Reach, impressions and follower counts read beside the post that earned them, instead of screenshotted out of five apps
- Boosting a post, or running a campaign, from the same screen the post was written on
- A dashboard that keeps up on its own, so a post that has gone out or a comment that has arrived shows without anyone refreshing
- Which destinations are worth carrying is a question about what each one costs to reach, not only about who is on it — and it is a decision rather than a list
- It would rest on a posting platform Harvest does not run, which is the part that decides what is possible and what it costs
This is not the community feed, which already ships: that is your own audience inside your own app, with no algorithm deciding who sees Sunday's post, and none of it changes. What is missing is the accounts your church runs on somebody else's platform, and everything that comes back through them.
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.