Who Wethr is for, what it doesn't do, how it was designed, and what to expect if you bring it to your church. No spin.
The most important question to answer before anything else.
Wethr is built for mid-size congregations, roughly 100 to 500 members, with a small staff team (typically 1 to 5 people) managing coordination across 3 to 8 active ministry teams.
These are churches that have outgrown spreadsheets and group texts. Sunday coordination is real work, not a side task. But the enterprise church management platforms built for megachurches are too much, too expensive, or both.
The specific problem Wethr solves is volunteer coordination and service planning. If you have a worship team, a nursery, a hospitality crew, and a tech team, all with their own leaders and overlapping volunteers, and Sunday mornings involve a lot of manual coordination, Wethr is built for you.
It depends on your complexity, not just your count. A church of 80 members with 4 active teams, 40 rotating volunteers, and a leader spending real hours each week on scheduling would benefit from Wethr. A church of 80 where one person handles everything in 20 minutes probably wouldn't. The tool would be more structure than you need right now.
The real question is: Is Sunday coordination actually costing your leaders significant time and mental energy? If yes, Wethr is worth a conversation regardless of member count.
Wethr will work for larger congregations. There's no hard membership ceiling, and the core workflows scale well. But the product is designed around the constraints of the mid-size church: lean admin staff, cost sensitivity, and a preference for simplicity over feature breadth.
Larger churches often need multi-campus support, deeper giving integration, and enterprise SSO. Those things aren't on Wethr's near-term roadmap. That said, many large churches have mid-size-style coordination problems and would benefit from the clarity Wethr brings. It's worth a conversation.
All of them. Wethr is denomination-neutral. The product is built around the coordination structure nearly every church shares (people, teams, service plans, volunteers), not any particular theology or liturgical tradition.
Block types, role names, and team labels are fully customizable. Whether you run contemporary services with a full band or traditional services with a choir, the Order of Service builder reflects your structure.
If Planning Center is working well for you, there may be no reason to switch. Wethr isn't trying to be a Planning Center replacement for churches where it's a good fit.
Churches that find Wethr interesting are ones where Planning Center feels like too much. Steep learning curve, low volunteer adoption, feature breadth that creates noise instead of clarity. Planning Center was built for churches with the staff capacity to configure and maintain a sophisticated system. For churches without that capacity, it often ends up used at 20% of its capability at 100% of its cost.
Wethr is narrower on purpose. If you're paying for a system half your team doesn't use, it's worth a look.
Breeze and CCB are primarily ChMS platforms. Their strength is membership management, giving records, check-in, and communication. They're not built specifically for service planning and volunteer scheduling the way Wethr is.
Many churches use Breeze for broader membership management while wishing they had something better for Sunday coordination. Wethr fills that gap. The two can sit alongside each other. Wethr handles coordination, your existing ChMS handles giving and membership records.
Being clear about who we're not for makes the product better for the people we are.
Not in Phase 1, and probably not in the short term. Multi-campus support is a Phase 5 capability. The current data model is built around a single church account, so there's no cross-campus shared directory, no campus-scoped views, no way to coordinate teams across locations.
Megachurches also typically need deeply integrated giving, media and sermon management, advanced event registration, and enterprise SSO. Those aren't on Wethr's near-term roadmap.
No, not now and not in the near term. Giving and stewardship is a Phase 5 capability, several years out. If giving tracking is a core requirement, Wethr isn't the right primary platform for you today.
Many churches use Wethr alongside a dedicated giving platform (Pushpay, Tithe.ly, Breeze, etc.). Wethr handles coordination. Your giving platform handles financial workflows. They don't need to be the same system.
Service headcount and nursery check-in (badge printing, allergies, custody notes, etc.) are Phase 5 features. If check-in is a critical workflow today, Wethr can't replace your current system for that.
Nursery team coordination (scheduling volunteers and helpers, building the service plan for nursery care, managing the Nursery team roster) is fully supported in Phase 1. It's the check-in and attendance piece that isn't.
No. Wethr is a coordination platform, not a media platform. Sermon notes, series archives, podcast publishing, and live streaming integration are not on the roadmap. Wethr helps you staff and plan the service. What gets recorded or streamed afterward is handled by other tools (YouTube, Boxcast, Sermon.net, etc.).
Probably not yet. Wethr works best when there's real coordination complexity: multiple teams, rotating volunteers, a Sunday production workflow that takes effort. A church plant where everything fits in a group text isn't the right moment. You'd be adding structure before the problem that structure solves.
There's nothing wrong with starting simple. Come back when coordination starts costing you real time. That's the right moment.
The principles behind the product, and why they matter for your church.
It means the Order of Service is the center of everything in Wethr. Other platforms organize around people, or teams, or communications. Wethr organizes around the service event itself, because that's what your church is actually building toward every week.
In practice: the directory exists to support the service. Teams exist to support the service. Scheduling exists to fill roles in the service. When you open Wethr, the first thing you see is your next service. The question the whole product is built around is: Is Sunday ready?
Many church software platforms are built from the database outward. Every feature is an opportunity to capture more information, generate more reports, create more records to manage. The result is a system that feels like work to maintain and creates new admin burden even as it tries to reduce it.
Wethr's principle is that the system should carry the burden, not the people. A volunteer shouldn't have to learn software to be scheduled. A ministry leader shouldn't have to configure twelve settings before assigning someone to a role. The complexity lives in the backend. What the user sees should feel light.
In practice: volunteers log in to one screen (their schedule), see what's relevant to them, and tap to accept or decline. They don't need to learn Wethr. They just need to be in it.
Because volunteer burnout is one of the most common and preventable ways churches lose their most committed people, and it almost always happens invisibly. Someone ends up serving three Sundays a month because they never said no, the leader never tracked it, and by the time anyone noticed, the person was exhausted and quietly stepping back.
Wethr builds frequency caps and availability preferences into the scheduling system at the data level. Not as a note field someone has to remember to check, but as a constraint the scheduling engine respects automatically. A volunteer set to "once a month" can't be assigned twice without a visible conflict alert.
In Phase 1, a single church administrator can realistically manage the full Wethr setup for a church of 300 members with 6 ministry teams. That means maintaining the directory, configuring team structures, building weekly service plans, and managing volunteer assignments across teams.
In Phase 2, once auto-scheduling and communications ship, that same administrator's weekly coordination work drops significantly. The system generates draft schedules, sends notifications, and handles RSVP reminders automatically. The admin's job shifts from doing the coordination to reviewing and adjusting it.
Every workflow in Wethr is designed with the assumption that one person is holding it. Anything that requires a dedicated IT person or extensive training is out of scope.
Wethr is a PWA (Progressive Web App). It installs on iOS and Android home screens directly from the browser, looks and behaves like a native app, supports push notifications on iOS 16.4+ and all modern Android, and works offline. For most volunteers, it's indistinguishable from a native app once installed.
We chose PWA over native for practical reasons: a native app requires App Store and Google Play distribution, a separate codebase to maintain, and review cycles that slow down updates. A PWA ships instantly to all users at once. For a coordination tool used by volunteers a few times a month, the App Store burden isn't justified by the benefit.
The one real limitation: push notifications on iOS require 16.4 or newer. Email and SMS cover this gap for users on older hardware.
Churches operate on a weekly rhythm, not a real-time business pace. Volunteers aren't checking an inbox hourly. Many serve once or twice a month. Over-notifying them trains them to ignore Wethr.
Church-paced communication means messages go out when they're meaningful: assignment notifications, reminders before the service, urgent changes. Not a stream of activity updates. Every user also controls their own notification preferences (email digest vs. real-time, SMS opt-in, push notification permissions). The default is thoughtful, not aggressive.
These are the things we've consciously decided not to be.
No. A full ChMS covers giving, fund accounting, contribution statements, check-in, event registration, background checks, and a dozen other workflows that touch the administrative operations of a church.
Wethr is a coordination platform, not a church management system. Its entire focus is the Sunday coordination loop: people, teams, service planning, and scheduling. It deliberately does not try to be the system of record for giving, attendance, or member lifecycle management.
Many churches will use Wethr alongside an existing ChMS. They're complementary, not competing, for most church contexts.
No. General project management tools (Asana, Notion, Trello, Monday) are flexible but context-agnostic. They don't know what a "service" is, what a "worship team" is, or what it means for a volunteer to have a frequency cap. You'd have to build all of that meaning yourself through custom fields and conventions.
Wethr is built specifically for church coordination. The data model, workflows, terminology, and UI are shaped around how churches are organized and how Sunday services come together. You don't have to configure it to understand your context. It already does.
No. Communications in Wethr (Phase 2) are event-driven and role-aware. The system sends the right message to the right person at the right time based on what's happening in the scheduling system. It's not a general-purpose messaging platform or chat tool.
Wethr won't replace your church's email newsletter, staff Slack channel, or all-church communication strategy. It handles one specific job: getting volunteers the information they need about their schedule, and surfacing the right alerts to leaders when something needs attention.
No. Wethr automates the administrative and logistical side of coordination (building schedules, sending reminders, tracking RSVPs) so that ministry leaders have more time and energy for the relational work no software can do.
The scheduling system assigns people to roles. It doesn't build relationships with them, notice when they're struggling, or know when to have a pastoral conversation. That's the leader's job. Wethr's job is to get the logistics out of the way so that work can happen.
This is a real and valid concern. Most church software suffers from exactly this problem. The answer depends on the volunteer experience, and Wethr is designed with that concern in mind.
Volunteers don't need to "learn" Wethr. Their experience is: receive a notification, tap a link, see their assignment, accept or decline. No training, no account configuration, no familiarity with the broader product required.
Whether adoption sticks depends on whether leaders are actually consistent about using Wethr to schedule. If scheduling still happens via text sometimes, volunteers won't trust the app as the source of truth. Leadership buy-in is a prerequisite for volunteer adoption. That's true of every coordination tool.
What Wethr does in Phase 1, what it doesn't do yet, and how it handles the details.
Phase 1 delivers the Sunday coordination loop. Everything needed to go from "I need to staff a service" to "everyone knows where to be and what to do."
No, that ships in Phase 2. In Phase 1, Wethr is a coordination tool for leaders, not yet a communication tool for volunteers. Leaders use Wethr to plan and assign. How they communicate assignments to volunteers is still handled outside the app (text, email, verbal) in Phase 1.
This is a deliberate sequencing decision, not an oversight. Assignment and scheduling data needs to be reliable and in use before the notification system is built on top of it. Phase 2 wires that together: volunteers receive push/email/SMS notifications when assigned, get reminders before the service date, and can accept or decline from their phone.
In Phase 1: always manual. Leaders assign people to roles themselves. What Wethr provides is the information layer that makes manual assignment much better. You see who's available, who's eligible (right role, right team), who's at their frequency cap, and who has a blackout date, all before you make the assignment.
In Phase 2: auto-scheduling becomes available as an opt-in. Each team leader can toggle auto-scheduling on for their team. Wethr generates a draft schedule respecting all preferences and caps. The leader reviews and confirms it rather than building from scratch. Manual assignment stays available at any time. The two modes coexist.
No hard caps in Phase 1. The platform is designed to handle churches up to 500 members without performance constraints, and is architected to scale well beyond that.
The practical limit for most churches will be what one admin team can reasonably maintain, not a system limit.
Yes. A person can be a member of multiple teams at the same time, with different roles on each. The scheduling system respects their frequency cap across all teams combined. If Maria is scheduled twice as a vocalist on the Worship Team, she won't be available for a Nursery slot if her cap is two per month.
This cross-team conflict detection is one of the harder coordination problems that spreadsheets handle poorly and Wethr handles natively.
In Phase 1: the assignment is removed and the role surfaces as unfilled. The leader sees the gap and assigns someone else manually.
In Phase 2: the leader is notified of the decline. If auto-schedule is enabled for the team, the system automatically tries to find and assign an available replacement. If none is found, the role is flagged as unresolved and the leader is alerted. Pending assignments don't auto-decline. They stay open until the volunteer responds or the leader removes them.
Yes. Each service in Wethr is a separate record with its own Order of Service, date, and time. You can create as many services on the same day as needed (9am, 11am, evening service, etc.). Team assignments and volunteer schedules are managed per-service.
Conflict detection accounts for this. If a volunteer is assigned to the 9am service, they won't show as available for the 11am on the same date without a conflict indicator.
What onboarding looks like, how your data gets in, who does the work, and what you have on day one.
Not in Phase 1. Onboarding is hands-on and handled by us. The Wethr team does the setup work for you. Here's the process:
Self-serve CSV import and a setup wizard are Phase 2 and Phase 4 capabilities. Until then, the Wethr team handles it. Honestly, we think that's the right experience for pilot churches anyway.
The target is under one business day of Wethr team effort from the time we receive your data export. Data quality in the source file is the main variable. Clean, well-structured exports come through faster. Messy spreadsheets take longer to normalize.
From your side, the work is: export your people data, share it with us, and review your account once we've set it up. Most church admins spend under two hours on their side of the process.
What we migrate in Phase 1:
What we don't migrate:
The clean break on service history is intentional. Starting with a blank slate means you're not importing the assumptions and formatting of your previous system.
No. Wethr is a fully hosted web application. Nothing to install, configure, or maintain on your end. Your church subdomain (yourchurch.wethr.app) is set up automatically when your account is created. The Wethr team handles all infrastructure.
The closest thing to a "technical" step on your end is exporting your people data from whatever platform you currently use. That's a CSV export, a standard feature in every ChMS and spreadsheet tool. No IT involvement needed.
No passwords. Wethr uses email OTP (one-time code) for authentication. Users enter their email address, receive a 6-digit code, and enter it. That's the entire login. No password to create, remember, or reset.
Sessions last 30 days. A volunteer who logs in once a month will almost never see a login screen again. They tap the icon and land directly on their schedule. The login friction that kills church app adoption is gone.
Where Wethr is going and how to think about the phased build.
| Phase | Theme | What it delivers |
|---|---|---|
| Phase 1 | Foundation | Directory, teams, order of service, manual scheduling, permissions. A church can staff and plan a Sunday. |
| Phase 2 | Intelligence | Auto-scheduling, volunteer notifications, RSVP flow, email/SMS/push, CSV self-serve import. The system does the scheduling work. |
| Phase 3 | Community | Small groups, public group discovery page, visitor intake form, files and notes. Wethr extends beyond Sunday. |
| Phase 4 | Insight | Reporting dashboards, volunteer health flags, group health metrics, self-serve onboarding wizard. |
| Phase 5 | Growth | Giving, attendance check-in, member journey, multi-campus, CNAME support. |
Phases are sequenced by dependency, not arbitrary timeline. Each one builds on the last and exits with a clear definition of done.
Both are Phase 2 capabilities. Phase 2 begins development once Phase 1 is stable and in the hands of pilot churches. There's no fixed calendar date. The timeline depends on Phase 1 adoption and feedback. The intent is that Phase 2 begins development within the first few months of Phase 1 being live.
If your church's ability to adopt Wethr depends on auto-scheduling or volunteer notifications, Phase 1 may not be the right moment to onboard. If you can pilot Phase 1 for service planning and manual scheduling while waiting for Phase 2, that's the ideal path.
The phase structure and sequencing reflect real product intent, not vaporware. That said, every product roadmap evolves based on what's learned from real usage. The themes of each phase are stable. The specific features within later phases will be shaped by what pilot churches actually need.
Phase 1 and Phase 2 are the most locked in. The principle we hold to: nothing gets added that makes Phase 1 and Phase 2 worse. Feature breadth for later phases never comes at the cost of the core coordination experience.
Small groups (group creation, member enrollment, public discoverability, and group-level messaging) is a Phase 3 capability. Phase 3 is the "Community" phase and directly follows Phase 2. Features planned include a public-facing group discovery page, a visitor intake form, and file/notes storage.
If small groups are a current urgent need, Wethr Phase 1 won't serve that yet. If you're willing to manage small groups outside Wethr for now and consolidate later, Phase 1 and 2 still deliver significant value in the Sunday coordination workflow while Phase 3 catches up.
Where your data lives, who can see it, and how the platform is built.
All data is stored in a cloud-hosted PostgreSQL database (Supabase) and isolated by church. Every database record is tagged with your church's unique ID. One church can never access another church's data by design. Row-Level Security (RLS) policies enforce this at the database layer, not just the application layer, so data isolation holds even if there's a bug in application code.
Your data is hosted in US-based infrastructure. The Wethr team can access your data for support and onboarding purposes. No third parties have access to your church's member data.
Wethr works in any current version of Chrome, Safari, Firefox, or Edge on desktop, tablet, or mobile. As a PWA, it can be installed on iOS (16+) and Android home screens for an app-like experience.
Internet Explorer is not supported. It reached end of life in 2022 and lacks the web platform APIs Wethr relies on.
You can export your directory, team structures, and service history at any time via CSV export. Your data is yours and is portable. If you close your account, Wethr retains your data for a 90-day grace period during which you can request a full export. After that period, data is deleted from production systems.
We're not building the kind of platform that holds your data hostage to keep you around.
Partially. The PWA service worker caches two key views for offline use: the current volunteer's upcoming schedule, and the next service's Order of Service. If a volunteer opens the app with no connection (in the parking lot on Sunday morning, say), they see their assignment and the service plan from the last sync.
Actions taken offline (RSVP responses, messages) are queued and sent automatically when connectivity returns. Admin-level editing requires a connection.
Wethr is a custom-built Next.js application: Next.js (App Router) for the frontend, Supabase for the database and authentication, Cloudflare R2 for file storage, and Inngest for background job processing. It's not a reskinned version of another platform or a no-code tool.
This matters for long-term reliability: Wethr's behavior and data model are fully under its own control, not dependent on the product decisions of a third-party platform provider.
What Wethr costs to run, and what the pricing model will look like.
Wethr is in a pilot phase. Formal pricing hasn't been finalized and pilot churches are onboarding under an early-access arrangement. Contact us to discuss what participation looks like.
The model we're building toward is a flat monthly subscription per church, not per-seat or per-member. A church of 150 members and a church of 400 members should pay the same base rate, because the coordination problem is roughly the same scale.
The infrastructure cost to run Wethr is very low, under $4 per church per month at any scale, because the stack is entirely serverless and consumption-based. There are no fixed server costs.
At a pricing point of $49 to $99/month per church, gross margins on infrastructure alone would be 92 to 97%. The real cost driver at scale is people: engineering, support, and onboarding. That's a healthy business model, not a precarious one.
SMS is the one variable cost worth watching. At high volunteer opt-in rates, Twilio charges can grow. Wethr defaults to push notifications and email, with SMS as an opt-in layer. This keeps SMS costs proportional to actual usage.
Pilot churches are joining during the product's most formative phase. They're helping shape what Wethr becomes, tolerating rough edges later customers won't have to deal with, and providing feedback that directly influences the roadmap. That contribution matters, and it will be reflected in how pilot pricing transitions to production pricing.
We're committed to treating pilot churches fairly when formal pricing launches. The specific terms will be worked out with each pilot church individually. "You helped build this" is not something we'll forget when the invoice arrives.
The intended model is flat per-church, with no per-seat or per-user fees. Your entire church (all members, all volunteers, all ministry leaders) is included in one subscription. Adding a volunteer doesn't cost more. Growing from 200 to 350 members doesn't trigger a price increase.
Per-seat pricing creates perverse incentives (don't add that volunteer, it costs money) and makes budgeting unpredictable. Flat pricing per church is simpler and more appropriate for the way churches think about software costs.
We'd rather answer them in a real conversation than have you guess. Reach out.
Get in touch →