SEED

The instinct behind the idea checks out — but the actual risk is more specific, and more interesting, than "churches are selling your data."

The scandal is real and current. In 2025, a pro-Israel advocacy campaign built digital perimeters around churches and Christian colleges across California, Arizona, Nevada, and Colorado — geofencing worship hours specifically — to serve targeted ads to attendees' phones, without those churches' knowledge or consent. Separately, the FTC has taken formal action against data brokers Gravy Analytics/Venntel and Mobilewalla for unlawfully collecting and reselling precise geolocation data tied to visits to churches, schools, and other sensitive locations.

That's an important nuance for how this product should be pitched. When I checked privacy policies for several church platforms — Church Online Platform, ChurchCast, Church Leadership Resources — each explicitly states it does not sell data or share it with ad networks. Others are murkier: Elevation Church's app documents a third-party "offer wall" ad exchange; ChurchMe's app bundles OneSignal, a third-party push SDK that collects device ID and usage data; ChurchPlus discloses unnamed third-party data collection. None of this is disclosed in a way an average church staffer could audit, and none of it is contractually permanent — a vendor can add an SDK in a future release without most churches noticing.

There's a second, more everyday problem alongside the privacy one: the local vendor ecosystem that churches and schools actually depend on — IT support, networking, AV, websites, payment integrations — is often expensive and unreliable, with nobody accountable when it breaks. This isn't hypothetical: as of this writing, my own kids' school, Seeds of Faith, has no working online payment option and a broken donate link — a paying family can't pay online, and a willing donor can't give. That's not a data-privacy failure, it's a basic-competence failure, and it's the kind of thing a small, local, accountable team can simply fix — because we'd actually answer the phone.

The field in Section 2 is genuinely crowded, and it's worth saying plainly: there are at least four existing church-software products with "Steward" in the name alone — which is exactly why that name got dropped before this went anywhere. "We're local and we care" is a real feeling, but a feeling isn't a moat, and a reader doing real diligence should expect more than that before taking any of this seriously. Five things that actually hold up under pressure:

• The pricing model is structurally hard to copy, not just a feature to add. A publicly traded or PE-owned incumbent — Pushpay's owners, Blackbaud, ACS Technologies — can't simply switch to permanent, published, at-cost pricing without cannibalizing the margin their own investors expect. It's not that they haven't thought of it; it's that their business model can't survive it. That asymmetry is durable in a way a feature is not.
• Skin in the game, not a sales territory. The founder is a member at Indiana Alliance Church and a parent at Seeds of Faith — not a rep assigned a market. The incentive to keep the privacy and pricing promises isn't reputational, it's personal: breaking them would mean facing the people affected on a Sunday morning, not losing a distant account.
• An already-proven trust track record, not a claim on a page. SAMICalls.com is live, in production, today, trusted by doctors' offices, hospitals, and a Catholic diocese with sensitive communications and no PII retained. That's checkable history, not a promise about the future.
• The shared church-and-school data model is a real architectural moat. FACTS, Sycamore, Gradelink, Planning Center, and Breeze all grew as separate businesses — several through acquisition — and none of them share a person record across a church and its school. Building that from one shared model on day one is something an incumbent would have to rebuild from the ground up to match, not bolt on.
• Built for the majority everyone else's pricing ignores. Every incumbent's actual sales motion — enterprise quotes, module upsells, opaque pricing — is aimed at the well-funded minority of large churches. This is built ground-up for the 68%-under-100-people majority that's currently an afterthought to all of them.

"Local" is what makes those five things credible and enforceable at this scale, not the differentiator by itself. Worth holding that distinction clearly before this goes to anyone who'll ask "why not just use Breeze."

Not built for the megachurch with a jumbotron — built for the ordinary congregation and the ordinary church school.

Per the 2025 Faith Communities Today survey, the median U.S. congregation has 70 regular participants, and 68% of churches have fewer than 100 people — most running on volunteer labor and a tight annual budget. Yet attendance is inverted: nationally, the largest 13% of congregations capture 78% of all churchgoers, which is exactly where Pushpay's and Subsplash's enterprise sales motion is aimed. This is precisely the segment national vendors treat as an afterthought — small churches and small Christian schools.

A small, known customer base is a feature, not a limitation, for a product whose entire pitch rests on trust. A national SaaS can promise not to sell data in a privacy policy; a founder who's a member of the church and a parent at the school being served — who can sit across the table, not a distant sales territory — is the accountability mechanism, not just a policy on a page. White-glove onboarding and support are genuinely feasible at this scale in a way they aren't for a platform chasing thousands of anonymous accounts.

This started as a hyperlocal build in western Pennsylvania. Whether it stays that way, or this becomes something with broader reach sooner than expected, is a genuinely open question right now, not a settled default either direction — events have already moved faster than the original plan assumed. The original regional go-to-market plan is preserved intact in the Appendix either way, set aside rather than discarded.

• Per-church data isolation. Strict tenant partitioning (row-level security or per-tenant schema) — no cross-church aggregation, benchmarking, or analytics pooling, even anonymized, without an explicit opt-in.
• No ad or tracking SDKs, anywhere in the stack. First-party, privacy-respecting product analytics only — no ad exchanges, no "offer walls," no third-party behavioral trackers riding along in the member-facing app.
• No data resale, contractually. Written into the Terms of Service and a real Data Processing Agreement — not a blog-post promise a future acquirer can quietly walk back.
• A published subprocessor list. Exactly who touches church data and why (payment processor, video host, SMS/email provider) — nothing else, no exceptions, no surprise vendors added later.
• Data portability by default. One-click full export, one-click full delete. A church that leaves should be able to leave completely.
• Honest scope. We don't claim to stop a congregant's other apps from geofencing the parking lot — we claim, provably, that we are never the leak.
• Homegrown over rented, everywhere it's practical. Our own storage, our own AI inference, on infrastructure we control — not per-seat SaaS tools or big-tech AI APIs. This is both a cost strategy (no rent-seeking middleman markup, which is what makes Option C's economics work at all) and a trust strategy — see below.
• AI that stays home. There's real, reasonable fear in these communities around AI and data — "is this being used to train someone else's model, sold, or read by a stranger." Any AI in the product (sermon transcription, search, tuition-billing follow-ups) runs on self-hosted, open-weight models on our own infrastructure — never a sermon recording or a family's data sent to OpenAI, Google, or another big-tech AI vendor's API. We can say plainly: your data never leaves infrastructure we own.
• Store the minimum, not the maximum. Not a new idea for us — it's how SAMICalls.com already runs in production for doctors' offices, hospitals, and a diocese: message without retaining PII a feature doesn't strictly need. Carry that discipline into SEED's core data design, not just its messaging layer.

The bulletin builder is worth calling out specifically: it's the one thing nearly every attendee touches every single week, it's usually hand-assembled in Word or Canva right now, and it costs almost nothing extra to build — it's just a template pulling data that already lives in Events, Communications, and Volunteer Scheduling. High visibility, low marginal effort, a natural first "wow" for a pilot demo.

The shared-identity point is the one incumbents structurally can't match: FACTS, Sycamore, and Gradelink are school-only systems with no concept of the family's church relationship. A platform built from one people database for both is a real moat, not just a marketing bullet.

FERPA is narrower than it sounds for this specific case, but it's not the whole story. FERPA applies directly to schools that receive funding from the U.S. Department of Education — most fully private Christian schools that take no federal funds aren't directly covered as institutions. Worth confirming this factually with Seeds of Faith and any other target school before assuming either way, since a voucher, ESA, or federal program a specific family participates in can pull funding-adjacent obligations back in. But strict legal applicability isn't really the bar worth building to — parents and schools expect FERPA-equivalent handling regardless, and Pennsylvania layers its own state-level confidentiality requirements (22 Pa. Code §12.31–§12.32) plus PPRA on top for anything survey-adjacent. The practical target: treat every school record as if FERPA's "school official" standard applies, whether or not it's technically required — data used only for the educational purpose it was given for, no re-disclosure without the school's permission, security commensurate with the sensitivity, and the school retaining oversight and control of its own students' records at all times.

COPPA is the other one that matters immediately — kids' check-in and any school-facing tool touching students under 13 collects data from minors. The standard, well-established path here is the "school as parent's agent" doctrine: a school can consent on a parent's behalf for education technology used for a legitimate educational purpose, provided the vendor never uses the data for any commercial purpose beyond that function. SEED's own no-ad, no-resale, no-behavioral-tracking posture already satisfies the hard part of that requirement — the remaining work is making sure the actual data flows and retention match what's been promised, not just the marketing language.

What still needs to exist as an actual document, not a principle: a Terms of Service, a Privacy Policy, and a Data Processing Agreement per organization, all built around the commitments already made in Section 5 — no resale, per-tenant isolation, published subprocessor list, data portability, minimal retention. These should be drafted from those principles and then reviewed by real counsel before any of it touches a signed agreement with a school or diocese — this plan can get the substance right, but it shouldn't be mistaken for the legal document itself.

A pure percentage-of-transactions fee has a real hole in it: a church that never routes giving online — plenty of small, older congregations run entirely on cash and checks in the plate, by choice — would get the full platform, support, and your time for permanently $0. That's not generosity, it's an unpaid-labor trap, and it would make the mission unsustainable rather than protect it. The fix is to stop conflating two different things: the transaction percentage rewards platform adoption and scales with real usage, but it can't be the only way SEED gets compensated for the ongoing work of running and supporting the platform.

Still deliberately not doing: tiered SaaS pricing or per-module add-ons, which charge every organization the same regardless of size or actual usage and invite Planning-Center-style creep. The baseline is different in kind — it's sized to real cost, published, identical for every organization, and exists only because the alternative was quietly asking you to subsidize churches indefinitely out of your own pocket. Both numbers above are pilot hypotheses, not locked figures — what Indiana Alliance and Seeds of Faith actually cost to support well is the real data that sets them.

Worth separating two things that are currently bundled in "streaming is costly." Indiana Alliance's actual current setup likely costs almost nothing to run today: Facebook Live's delivery is free — Facebook bears the CDN cost for every viewer, the church only pays for its own encoder and upload bandwidth it already has — and the in-building TV displays, if they're fed over the church's own local network rather than round-tripping through the internet, cost close to zero marginal dollars per Sunday. The new cost only shows up once SEED hosts delivery — so that's the only piece that needs a billing mechanism at all.

Using Cloudflare Stream's actual published rates — $5 per 1,000 minutes stored per month, $1 per 1,000 minutes delivered, no separate egress fee — a church Indiana Alliance's size is a lot cheaper to stream than the BoxCast/Subsplash comparisons in Section 2 suggest. A 75-minute Sunday service, recorded weekly (~325 min/month stored ≈ $1.63), delivered to a few in-building TVs over the internet (~1,500 min/month ≈ $1.50) plus a modest public embed audience of, say, 50 concurrent viewers (~16,000 viewer-minutes/month ≈ $16), lands around $15–25/month in real pass-through cost — not the $100s/month incumbents charge. The gap is almost entirely because Cloudflare has no egress-tier markup, and SEED isn't adding one on top.

Two practical recommendations that follow directly from this:

• Keep the in-building TVs on the local network, not the internet, wherever possible. There's no reason to pay any per-minute delivery cost for a screen sitting fifty feet from the source — a local AV/NDI setup keeps that piece at effectively zero, permanently.
• Don't try to replace Facebook Live's public reach — multistream instead. Facebook already bears the delivery cost for the broad public audience that's already there; fighting that with SEED's own infrastructure would mean voluntarily taking on a cost Facebook is giving away for free. Push the same encoder feed to both: Facebook Live for free public reach, and SEED's own Cloudflare-hosted feed as the piece that's actually ours — the archive, the source for auto-transcription and the sermon-to-podcast pipeline, and a privacy-respecting embed for anyone who'd rather not watch on Facebook at all.

One infrastructure cost doesn't meter cleanly this way: the self-hosted AI compute (the transcription/LLM box, more in Section 12) is mostly a fixed hardware-and-power cost, not a per-minute one — it doesn't scale down to near-zero the way Cloudflare's usage-based pricing does. For the two pilots, that's small enough to treat as your own overhead, absorbed by the transaction-percentage margin rather than billed to either organization. Worth revisiting only once real usage across more churches would justify a second machine.

Every number below is a labeled assumption, not a locked figure — real pilot data from Indiana Alliance and Seeds of Faith is what actually sets these, the same caveat that's been true everywhere else in this plan. The point of building it anyway is to answer one question plainly: does "small at-cost baseline plus a small percentage" actually produce enough to sustain a small team, without ever needing to behave like a company trying to maximize revenue per church?

Assumptions: $25/mo baseline (midpoint of the $20–30 range), and $40/mo average giving-percentage revenue per church — built from a rough illustrative estimate of ~$4,000/month in giving actually processed online per congregation at 1%, itself a guess pending real pilot numbers. Infra cost scales in rough steps as the shared cluster grows (Section 10's isolation architecture) plus the fixed self-hosted AI box from Section 12 — a second AI machine only gets added once usage genuinely justifies it.

Two things worth reading off that table honestly. First, the pilot phase is a real, out-of-pocket cost — a few hundred dollars a month, plus time, funded personally, which is exactly what "starting free while we prove it works" actually costs to keep the promise. Second, the model doesn't need hundreds of churches to become genuinely sustaining — even at a modest few hundred participating organizations, well short of any national reach, the residual is a modest, real income for a small team, not a fortune, and not nothing either. That's the whole point: the ceiling on this model is deliberately modest, because the pricing was never designed to extract more than what it actually costs to run this well.

With a team that's essentially you plus one or two trusted friends, the honest constraint is time, not ambition — which is exactly why the Rock RMS question was worth asking. It's now answered: ruled out. Rock RMS is an ASP.NET 4.5 / C# / Entity Framework application, historically Windows/IIS/SQL-Server-hosted — a legacy .NET Framework stack, not modern cross-platform .NET. That's disqualifying on its own for a team unwilling to build in .NET, and it also sits awkwardly against the lean, Cloudflare-first, self-hosted-AI stack already decided on elsewhere in this plan. No need to chase the license question further — the stack kills it first. Core build: custom, not on top of Rock RMS.

Decided: Postgres, with Go for the core multi-tenant app and Python as a sidecar for the AI layer. Go over Python for the core app specifically because of the isolation architecture below — a compiled Go binary idles at a fraction of a Python process's memory footprint, which directly determines how many small church workloads can be packed cheaply onto shared hardware. Python stays the right tool for the self-hosted AI orchestration (Whisper-class transcription, LLM inference via something like Ollama) since that ecosystem is strongest there — it runs as its own service the Go app calls internally, not inside the core tenant app.

Security posture, in one place instead of scattered across Sections 5–12: per-tenant database and namespace isolation with network policies preventing any cross-tenant traffic; no third-party ad, tracking, or analytics SDKs anywhere in the member-facing app; AI that never leaves self-hosted, owned infrastructure; Stripe Connect holding payment custody so SEED itself never touches or stores raw payment credentials; data minimization as a default, not an afterthought — store what a feature actually needs, nothing it could merely use. None of this is a roadmap item to build later. It's the architecture already committed to in Sections 5 and 12, restated here as the answer to "what's your security posture" rather than left for a reader to piece together.

Insurance is already in place — cyber liability and E&O coverage through Chubb, an established commercial carrier a diocese's or school's own risk office will recognize without needing an explanation of who they are.

• The field is crowded, and "we're local" isn't enough on its own. Addressed directly in Section 3 — the real differentiators are structural pricing, skin in the game, a proven trust track record via SAMICalls, and the shared church-school data model, not geography alone. Still a live risk if that argument doesn't land with a specific reader; worth pressure-testing it on someone skeptical before it goes out broadly.
• Key-person risk — this is essentially a solo founder. Addressed structurally in Section 13 (automation, documented runbooks, cross-trained collaborators, data escrow), but it's still the single biggest fragility in the plan as written, and worth naming as such rather than assuming the mitigation fully closes it.
• Regulatory risk — FERPA-adjacent obligations, COPPA, Pennsylvania student-record law, evolving state privacy statutes. Section 8 lays out the current understanding and the honest caveats; none of it is finalized without actual legal counsel reviewing the real Terms of Service, Privacy Policy, and Data Processing Agreements before they touch a signed relationship with a school or diocese.
• Adoption and inertia risk — churches are famously slow to switch systems. Sunk cost in an existing ChMS, volunteer training burden, "if it isn't broken, don't touch it." Mitigated by leading with concrete, felt pain (Seeds of Faith's broken donate link) rather than an abstract pitch, and by white-glove onboarding that's only feasible because the customer base stays small and known.
• Competitive response risk — an incumbent could add a "privacy mode" or drop prices. Genuinely possible for a feature. Much harder for the pricing model itself: Pushpay, Blackbaud, and ACS Technologies are owned or backed in ways that make permanent at-cost pricing structurally incompatible with what their owners expect — this is discussed at length in Section 3.
• Self-hosted AI quality risk — open-weight models on lean hardware may underperform big-tech APIs. Real, and worth testing honestly before launch rather than assuming parity. Mitigated somewhat by the actual use cases (sermon transcription for search and captions) having real tolerance for imperfection — this isn't a use case that demands frontier-model accuracy.
• SAMICalls dependency risk — messaging runs through a separate business Jim also operates. Worth a clean API-level separation between the two and a documented internal SLA, even an informal one, so an issue in one business doesn't silently become an outage in the other. The underlying carrier dependency is really on Twilio, not SAMICalls' own code, which limits the blast radius.
• Team bandwidth risk — two parallel product tracks, shared infrastructure, and an already-running separate business, built by one to three people. Real overcommitment risk. Mitigated by the phase sequencing in Section 12 and by a willingness to let the Q1 2027 target slip rather than cut a privacy or security corner to hit it.
• Institutional sales-cycle risk — dioceses and school boards move slowly, with committees and legal review. The individual-congregation and Indiana-Alliance-style pilot path is the faster proof point; diocese relationships via SAMICalls are a longer parallel track, not something the Q1 2027 target depends on.

• Launch wedge: both tracks in parallel — church and Christian school — not sequential.
• Pricing: Option C, permanent, two layers — a small at-cost baseline every active organization pays, plus a published percentage on giving, tuition, and event registration payments on top. Neither moves unless our own costs do.
• Team: mostly you, plus one or two trusted friends. No outside hires or fundraise to get to pilot.
• Go-to-market: Indiana Alliance Church and Seeds of Faith as the intended first pilots — real relationships, but not yet a formal ask. They'll be approached once there's a working product to show, not before; both the baseline and the percentage would be waived for them once a pilot begins.
• Name: SEED — S.E.E.D., Systematic Engagement, Enrollment & Discipleship. Chosen after checking: at least four existing church-software products already use "Steward" in their name, which is why that direction was dropped.
• The ask: feedback, not funding. This isn't a fundraise — the premise is a sustainable business built on honesty and accountability, not a high-growth one built to return investor capital, which was never the shape this was meant to take.
• Insurance: cyber liability and E&O already in place through Chubb.
• Security posture: baked into the architecture already decided elsewhere in this plan — per-tenant isolation, no third-party tracking, self-hosted AI, minimal data retention — not a separate initiative to build later.
• Continuity: data escrow, infrastructure as code, and documented runbooks so no single person is a single point of failure — the only single point in this design is faith that building it this way is worth doing.
• Entity: building under your existing S-Corp LLC — no new entity to stand up before starting.
• Streaming/infra billing: usage-based costs (video, messaging) pass through to each church at cost, itemized, no markup — separate from and never counted toward SEED's own revenue.
• Core build: custom, not on top of Rock RMS — ruled out over its legacy .NET/ASP.NET Framework stack.
• Stack: Postgres, Go for the core multi-tenant app, Python as an AI-layer sidecar.
• Texting/calling: routed through your existing, already-in-production SAMICalls.com — not a new build, not a second messaging stack.
• Shared-cluster cost allocation: storage metered and passed through per GB at cost; CPU/RAM handled as flat, published resource-quota tiers (Standard included in baseline, Plus for genuinely heavy usage) rather than live-metered — keeps church-facing bills simple while an internal tool like OpenCost verifies the tiers stay honestly priced.
• Isolation architecture: dedicated Postgres database + Kubernetes namespace per tenant on a small shared cluster — not a dedicated node per organization by default.
• Catholic parishes & dioceses: sacramental records stay an explicit non-goal — interoperate with whatever specialty system (ParishSOFT or similar) a diocese already runs, never rebuild it. Diocesan rollup reporting only ever happens with each parish's or school's explicit, individually-granted opt-in.
• Growth discipline: prove it with the pilots before approaching anyone else, and never grow for growth's sake — decided and firm. How wide it eventually grows — staying hyperlocal versus something with broader reach — is not decided; see Open Questions.

1. The exact baseline and percentage numbers — $20–30/mo and ~1% are starting points to pressure-test against what Indiana Alliance and Seeds of Faith actually cost to support well, not final figures.
2. Specific self-hosted AI hardware/models (what runs the local Whisper-class transcription and the local LLM, and on what you're actually willing to host and maintain).
3. Realistic pace given this is you and one or two friends working around other commitments — what's a sane timeline to a working Phase 1 pilot at both organizations?
4. Whether Indiana Alliance's in-building TVs are already on a local feed or currently routed over the internet — worth checking before Phase 1, since that alone could remove a real recurring cost.
5. Whether the baseline should scale at all past a certain size (e.g. a large multi-site church) or stay genuinely flat for everyone.
6. Which diocese SAMICalls already has a relationship with, and whether that's a usable warm introduction for the Christian-school track.
7. Which denominational or diocesan statistical reports (e.g. an annual denominational report, if Indiana Alliance is Christian & Missionary Alliance-affiliated, as "Alliance" churches commonly are) are worth building export formats for first.
8. Geographic scope — genuinely open, not a placeholder question. This began as a hyperlocal western-PA build (full plan preserved in the Appendix). That premise is already being tested faster than expected by real conversations in motion. Whether it stays hyperlocal, or this is approached with broader reach in mind from the start, needs a real decision — not an assumption carried over from the original plan.

Feedback, not funding. This isn't a fundraise. The premise is a sustainable business, not a get-rich one — the money is meant to come from being honest and accountable, not from squeezing the churches and schools using it, which means it was never going to be pitched as a high-growth return for investors in the first place. What's actually wanted from anyone this reaches: does the model hold together, is the "sustainable instead of extractive" premise actually credible on paper, and where is the thinking wrong. If you're the kind of person who can look at Sections 12, 13, and 14 and have real opinions — on the stack, on the isolation architecture, on what a solo-plus-friends team should build first, on a risk that's missing — that's the most useful response, more than encouragement.

Worth being precise about the pilots too: Indiana Alliance Church and Seeds of Faith are the intended first two, real and already identified — but that conversation hasn't happened yet. The plan is to approach them once there's a working product to show, not before, so nobody is waiting on anything right now except the build itself.

— Jim  ·  jim@secondrowsolutions.com  ·  412-719-5266

Original market framing. Not a national SaaS play — a service to a specific region's churches and schools, run by someone who can sit in the pew. Rural western Pennsylvania skews smaller and older than the national average — small-town Lutheran, Methodist, UCC, and Presbyterian congregations alongside Catholic parishes and independent/Baptist churches, most running on volunteer labor and a tight annual budget.

Original trust argument. A relatively small, known universe of customers is a feature, not a limitation, for a product whose entire pitch rests on trust. A founder who's known locally, who can meet a pastor or school administrator face to face, who sponsors the same county fair, is the accountability mechanism, not just a policy on a page.

Original expansion sequencing. Prove the model in Indiana County first — no push into Cambria or Armstrong until Indiana County itself is solid. Once proven in the three core counties, the natural next ring — Westmoreland, Jefferson, Clearfield, Blair, Somerset — would extend the same relationship-driven approach outward, rather than pivoting to a colder, more distant go-to-market.