What every church gets
- Shared core product access across launch threshold bands
- Migration-aware evaluation help and grounded documentation
- Clear trial, billing, and hardship posture before commitment
Pricing, trial, and demo
Clear pricing for churches, without lock-in or surprise billing.
Transparent launch pricing is built to stay month to month, start with a two-month free trial, and scale by active people with explicit timing when a higher band would apply.
One core product, pricing shaped by active-people thresholds
| Commitment | Month to month at launch |
|---|---|
| Trial | Two months free before any paid conversion |
| Primary pricing driver | Active-people thresholds |
| Billing posture | Separate from church giving truth |
| Demo posture | Optional, available, and not the only serious path |
Final numeric bands can publish later. This first shell locks the structure and explanation model now instead of inventing false precision.
Every church still gets the same core product
The launch model is intentionally not a bloated feature-grid. Pricing changes with active-people thresholds, not with a maze of gated core functionality.
What changes between threshold bands
Launch pricing moves with active-people thresholds, not with a sprawling feature checklist.
What matters most is when a higher band would actually take effect, and this page keeps that timing visible instead of burying it in footnotes.
How active-people pricing works
Active people should be understandable before they ever become a trust problem. The important question is not just where a threshold sits, but what actually happens when a church grows.
Plain-language definition
Active people means the governed launch count used for Transparent pricing. A higher count does not cause an immediate surprise charge. Launch planning uses a 10 percent grace boundary and a three-month notice window before a higher band takes effect when the higher count remains true.
Smaller church example
Current count: 4% above the church’s current threshold
Threshold trigger: above the current band, but still inside the 10% grace boundary
Grace applies: yes
Future timing: no band change while the church remains inside grace.
Growing church example
Current count: 13% above the church’s current threshold
Threshold trigger: beyond the 10% grace boundary
Grace applies: no, because the church moved beyond the grace range
Future timing: a three-month notice window starts before a higher band takes effect, if the higher count remains true.
Seasonal fluctuation example
Current count: temporary spike above the grace boundary
Threshold trigger: notice may begin if the spike moves beyond grace
Grace applies: depends on whether the spike stays within the 10% buffer
Future timing: if the count drops back before the effective date, the pending change should resolve through governed rollback, not ad hoc support judgment.
Two-month trial, explained plainly
Trial expectations should be legible before anyone commits.
During the trial
- The trial begins when the church starts its evaluation path.
- Churches can explore setup, migration questions, and core product fit during the trial window.
- Clear notice should happen before any paid change begins.
- If a church needs more time or more guidance, asking for help remains available during evaluation.
What this page is intentionally not implying
- No hidden billing activation language.
- No automatic promise of extra time without review.
- No vague suggestion that asking for help means entering a sales-only route.
Hardship remains visible and humane
Transparent should make hardship help easy to ask about without turning it into a hidden pricing backchannel. Requests remain manual review, time-bounded, and attributable.
When to ask
- Asking about hardship does not start a hidden sales negotiation.
- Hardship is manual review, not automatic discounting.
- Requests should route through a clear, reviewable intake path.
Launch boundary
Hardship stays separate from standard billing and should route through a reviewable path, not a hidden pricing negotiation.
Choose the path that fits your evaluation style
Self-serve and guided evaluation should both feel serious and supported.
Choose self-serve
- You want to explore quickly.
- Your team is comfortable evaluating software hands on.
- You want setup and migration guidance without waiting on a meeting first.
Choose demo
- You need multiple stakeholders aligned early.
- Your migration questions are more complex.
- You want guided help before changing internal expectations.
Practical AI guidance, with clear boundaries
AI should make evaluation calmer, not fuzzier.
- AI can help explain docs, setup steps, and migration guidance during evaluation.
- AI should escalate when confidence is weak or the question is high risk.
- AI should not act as autonomous authority for billing, records, or church decisions.
FAQ and edge cases
Answer the trust-sensitive questions directly.
When would pricing change after growth?
Not immediately when a count moves. Launch planning uses a 10% grace buffer and a three-month notice window before a higher band takes effect when the higher count remains true.
Is there an annual contract?
No. Launch planning is month to month. The public shell intentionally avoids hidden annual-commitment language.
Can we request a demo before starting a trial?
Yes. The demo path is a first-class option for churches that want guided evaluation or stakeholder alignment before deeper self-serve setup.
Can we ask about hardship before subscribing?
Yes. Hardship should be visible before subscription and should route into a manual review path.
What happens if we need more time?
The public shell should not imply automatic extensions. If more time is needed, churches can ask for help and any exception handling should stay explicit and reviewable.
Will English and Spanish evaluation materials match?
Not fully yet. The current launch shell is still English-first, and Spanish parity remains an explicit launch-readiness task before trust-sensitive EN and ES paths should be treated as equivalent.
Current bilingual launch posture
The current public launch shell is English-first. Spanish parity remains an explicit review and implementation task for trust-sensitive surfaces, so no Spanish path should be implied equivalent until it is rechecked and landed.
- Current live launch shell content is English-first.
- Spanish parity is still in progress for trust-sensitive launch surfaces.
- Do not imply equivalent EN/ES launch readiness until the specific surface is re-reviewed and landed.
English and Spanish must carry the same decision confidence
Pricing-critical language should stay equally trustworthy in both languages.
- Month-to-month commitment and no-lock-in language should mean the same thing in both languages.
- Trial timing, threshold timing, and hardship posture should not become fuzzier in translation.
- Self-serve and demo paths should remain equally serious in English and Spanish.
Clear pricing, no lock-in framing, and help when needed.
Start on your own or ask for guided help. Either way, the launch posture should stay calm, explicit, and easy to review.
Month to month, no hidden annual contract, and help is available if your church needs more guidance.