TL;DR. You have three viable paths. Open source maximises trust and differentiation in the charity/religious sector but needs guardrails to stop commercial free-riding. Closed source protects the commercial moat but forces you to earn trust the hard way against incumbents who already own it. Open core is the pragmatic middle: open the compliance-critical code (Gift Aid / GASDS engine, donor flow) and close the commercial control plane (Super Admin, billing, analytics, CRM integrations). Whatever you choose, decide before 9 May. Licence reversal after live customers is painful — legally and reputationally.
1. How to use this playbook
Three paths below. Each has the same structure so you can compare like for like: strategic thesis, what you're really selling, pre-launch playbook (now → 9 May), 12-month playbook, licence mechanics, moat protection, what you give up, reversibility, and the KPIs to watch. Section 5 is a decision scorecard you can fill in.
2. The three paths at a glance
|
Path A — Open Source |
Path B — Closed Source |
Path C — Open Core |
| Core thesis |
Transparency is the wedge. Trustees audit the code; HMRC-critical logic is provably correct. |
Code is the asset. Protect it, monetise every deploy, move fast without community overhead. |
Open what builds trust; close what builds revenue. Best of both, more to maintain. |
|---|
| What's open |
Everything in SwiftCause_Web (donor app, compliance engine, SDKs). |
Nothing. |
Donor app, Gift Aid/GASDS engine, campaign config schema, webhook SDKs. |
|---|
| What's closed |
Nothing (but "Enterprise" features live behind auth, not behind licence). |
Everything. |
Super Admin, Stripe Connect orchestration, analytics, CRM/Xero connectors, multi-tenant ops. |
|---|
| Licence |
AGPL-3.0 or BSL 1.1 (change to Apache after 4 yrs) |
All Rights Reserved + commercial EULA |
Open part under Apache-2.0 or BSL; closed part under EULA |
|---|
| Trust signal |
Strongest — unique in sector |
Weakest — same as incumbents |
Strong — "compliance code is public" |
|---|
| Fork risk |
Real but mitigated by licence + ops moat |
None |
Low — fork gets donor app, not control plane |
|---|
| Dev velocity (small team) |
Slower — PR triage, public issues |
Fastest |
Fast — only engine repo needs community management |
|---|
| Investor story |
Mixed — some love it, some fear dilution |
Cleanest |
Familiar (GitLab, Sentry, Posthog pattern) |
|---|
| Reversibility |
Hard — can't un-publish code already released |
Easy — can always open later |
Can tighten open part; opening more is easy |
|---|
The decision isn't binary on day one. You can ship the MVP closed on 9 May and open specific modules in July once you have 5 live charities. What you can't do is ship open on 9 May and pull it back in July — that's a trust blow-up.
3. Path A — Stay Open Source
PATH A · OPEN
Strategic thesis
In a trust-first vertical (mosques, churches, small regulated charities), verifiability beats features. No competitor — Dona, GoodBox, CAF Donate, CollecTin, GiveALittle — publishes their compliance code. You own that positioning for free. You're not selling code; you're selling a compliant, branded, operated service with an auditable core.
What you're actually selling
- Stripe-connected, KYC'd merchant account provisioning
- Hosted, monitored, backed-up donation endpoints
- HMRC R68 monthly batching + Charity Commission compliance ops
- Hardware + branded accessories (card readers, QR plates)
- Support, training, sector-specific playbooks (religious two-pile, events)
- CRM/Xero connectors + Super Admin dashboards (behind auth, not behind licence)
Pre-launch playbook (now → 9 May 2026)
Week 1 (19–25 Apr)
- Confirm licence: BSL 1.1 (recommended) or AGPL-3.0. BSL lets you restrict commercial hosting for 4 yrs, then auto-converts to Apache.
- Legal review of licence with a UK IP solicitor (~£500–£1,500). Flag: YNVSolutions org ownership, contributor assignment.
- Draft Contributor Licence Agreement (CLA) via cla-assistant.io — free.
- Audit all code for hard-coded secrets, PII, internal URLs.
git-secrets + manual pass.
Week 2 (26 Apr – 2 May)
- Publish
LICENSE, CONTRIBUTING.md, SECURITY.md, CODE_OF_CONDUCT.md across SwiftCause_Web and sibling repos.
- Write a
TRUST.md — explains what's in the engine, links to Gift Aid rules, shows how to verify a reclaim locally.
- Set up GitHub issue templates (bug, compliance question, feature request) and pinned "we're a small team" note.
- Decide policy on external PRs: "accept bug fixes and docs; defer feature PRs until post-launch." State it publicly.
Week 3 (3–9 May) — launch week
- Public launch post: "Why our Gift Aid engine is open source." Position it as a sector first.
- Pitch to sector press: Third Sector, Civil Society, Church Times, Muslim News.
- Seed conversation in charity tech forums (CharityDigital, Tech for Good UK).
12-month playbook (May 2026 → May 2027)
- Months 1–3. Trust-capital phase. Publish a public changelog, security.txt, and a "trustee's guide to reviewing our code." One signed release per month.
- Months 4–6. Community phase. Run a "verify your reclaim" workshop with 2–3 tech-literate trustees from pilot charities. Write it up. Their quotes become your best sales asset.
- Months 7–9. Ecosystem phase. Publish integration SDKs (Xero, ChurchSuite, ChMS, Mosque Management Systems). Each becomes a co-marketing moment.
- Months 10–12. Moat-deepening. By now you have customer data, Stripe relationship, HMRC batching track record. The code is open; the operation isn't replicable.
Moat protection (non-code)
- Stripe Connect platform relationship. Rate + approval — not forkable.
- HMRC track record. Clean R68 filings build credibility that can't be copied overnight.
- Data network effects. Benchmarking ("your mosque is top-quartile for Ramadan uplift") needs aggregated data.
- Sector playbooks. Two-pile logic, roaming stewards, madrasah carousel — operational IP, not code IP.
- Trademark "SwiftCause" registration (~£170 for one UK class). Fork can't use the name.
- 485-prospect pipeline. The hardest asset to replicate.
What you give up
- Some enterprise buyers treat open source as amateur (less of an issue in charity sector; very much an issue if you ever sell to councils).
- Competitors can study your compliance logic and match it faster.
- Dev velocity tax — even with a "no feature PRs" policy, issue triage eats ~2–4 hrs/week.
- Future proprietary ML/analytics features need clean IP boundaries.
KPIs to watch
- GitHub stars on SwiftCause_Web (vanity but signals sector awareness)
- Inbound leads citing "I reviewed the code" — track as CRM field
- External contributors (target: 3 by month 12; 0 is fine if trust narrative working)
- % sales calls where transparency is explicitly mentioned as a reason to choose (target: ≥30%)
Red line. If a competitor forks and deploys against your customers within 12 months, you switch to Path C (open core) immediately — that's the BSL "change date" lever in action.
4. Path B — Go Closed Source
PATH B · CLOSED
Strategic thesis
Your asset is the whole stack: compliance engine, Super Admin, Stripe orchestration, CRM connectors. Protect it, monetise every deployment, move at small-team speed without community overhead. You out-execute incumbents on UX, sector fit, and Gift Aid accuracy — not on transparency.
What you're actually selling
- A complete, branded, hosted donation platform
- Proprietary Gift Aid + GASDS engine with HMRC-grade accuracy
- Unique religious-sector features (two-pile, madrasah carousel, roaming steward mode)
- Hardware + accessories bundle
- Dedicated support + compliance ops
Pre-launch playbook (now → 9 May 2026)
Week 1 (19–25 Apr)
- Make all YNVSolutions SwiftCause repos private. Audit who has access. Remove anyone who shouldn't.
- Put contractor/offshore dev contracts through a solicitor — confirm IP assignment clauses are watertight (work-for-hire under UK law).
- Add proprietary header to every source file:
© 2026 YNV Solutions Ltd. All rights reserved. Confidential.
Week 2 (26 Apr – 2 May)
- Draft a Customer Software Licence Agreement (EULA) — grants right to use via SaaS, no redistribution, no reverse engineering.
- Draft a Master Services Agreement for charity contracts — data processing, SLA, IP ownership, termination.
- Trademark "SwiftCause" with UKIPO (~£170 one class; £70 each additional).
- Document internal coding standards so you can defend against "we reverse-engineered a concept" claims later.
Week 3 (3–9 May)
- Prepare a "trust without transparency" story: SOC 2 readiness, HMRC liaison, Charity Commission engagement, public incident reporting.
- Launch messaging: focus on outcomes, not architecture ("the highest Gift Aid reclaim rate in the sector").
- Line up 2–3 third-party security testers for a penetration test post-launch — external attestation replaces code transparency.
12-month playbook (May 2026 → May 2027)
- Months 1–3. Prove compliance through output, not code. Publish monthly stats: "£X reclaimed, 0 HMRC rejections across Y charities." Every clean month compounds.
- Months 4–6. Earn the SOC 2 Type I attestation (~£8–15k). It's the closed-source equivalent of "you can inspect our code."
- Months 7–9. Publish case studies with named charities. Third-party trust beats self-asserted trust.
- Months 10–12. Build the moat the code can't see: Stripe preferred-rate relationship, HMRC liaison programme, exclusive partnerships with Muslim Scout Fellowship, Diocese of Bristol, etc.
Moat protection
- Code is confidential information under every employee/contractor NDA
- Deploy obfuscation on client-side bundles
- Rate-limit and fingerprint API access to detect scraping
- Monitor GitHub/GitLab for leaked repositories
- Full IP ownership (important for future acquisition)
What you give up
- Biggest differentiator vs Dona/GoodBox/CAF evaporates. You compete on execution alone — and they have scale you don't.
- Trustees who want to audit code can't. For a minority (maybe 5–10% of buyers in the religious sector) this is a non-starter.
- Sector PR opportunity lost — "UK's first open-source charity donation platform" is a headline only available once.
- Developer recruitment harder — top juniors want to build a public portfolio.
KPIs to watch
- SOC 2 / ISO 27001 certification timeline
- External pen-test findings and remediation cadence
- Case studies published (target: 5 by month 12)
- Sales cycle length — watch for lengthening due to trust-building friction
- Gross margin vs Path A (should be 3–5 pts higher if this path is working)
Watch-out. In the religious sector specifically, committees sometimes want their IT volunteer to "have a look" before adopting. Closed source doesn't block the sale, but it adds a round trip. Have a standard answer: "We publish a technical white paper and SOC 2 report; happy to NDA your volunteer for a code walkthrough."
5. Path C — Open Core (pragmatic middle)
PATH C · OPEN CORE
Strategic thesis
Open the code that builds trust. Close the code that builds revenue. This is the GitLab / Sentry / PostHog / Supabase pattern — proven at scale in B2B SaaS. For SwiftCause the natural split is: donor-facing + compliance engine = open; platform ops + Super Admin + integrations = closed.
The split
Open (Apache-2.0 or BSL)
- Donor web app (card-tap / QR flows)
- Magic-link flow + consent ledger
- Gift Aid / GASDS rules engine
- Campaign compliance lock logic
- R68 batching + HMRC CSV generator
- Two-pile / madrasah carousel rules
- Webhook SDK + public API client libs
- Reference documentation
Closed (proprietary EULA)
- Super Admin console + charity onboarding
- Stripe Connect orchestration + KYC gate
- Multi-tenant infrastructure + data isolation
- Analytics, benchmarking, donor CRM
- Xero / ChurchSuite / ChMS integrations
- Billing, metering, tiered-fee logic
- ML scoring for prospect discovery
- White-label and agency tooling
Pre-launch playbook (now → 9 May 2026)
Week 1 (19–25 Apr) — repo split
- Inventory current SwiftCause_Web and sibling repos. Tag every module as OPEN or CLOSED.
- Migrate CLOSED modules to new private repos:
swiftcause-admin, swiftcause-platform, swiftcause-integrations.
- Leave OPEN modules in
swiftcause-engine, swiftcause-donor-app, swiftcause-sdk.
- Set up a private monorepo or internal-only meta-repo that imports both.
Week 2 (26 Apr – 2 May) — licence + hygiene
- Apply Apache-2.0 (simpler) or BSL 1.1 (more protective) to open repos.
- Apply proprietary EULA header to closed repos.
- Set up CLA-assistant on open repos.
- Write the public README for
swiftcause-engine: "This is the compliance engine that powers SwiftCause, the UK charity donation platform. It is maintained by YNV Solutions Ltd. Commercial hosting of charity donations requires a SwiftCause account."
Week 3 (3–9 May)
- Launch with a sector post: "Our compliance engine is public. Here's why." Link directly to the Gift Aid logic file.
- Brief the first 5 pilot charities — this is a proof point, not a risk.
12-month playbook
- Q1 (May–Jul). Keep closed repos closed, ship fast. Stabilise the engine API so external eyes feel welcome without destabilising you.
- Q2 (Aug–Oct). Open a second module — probably
swiftcause-sdk — once it has a stable surface. Each open module is a PR moment.
- Q3 (Nov–Jan). Consider an open reference charity (a real mosque or church that runs SwiftCause) publishing their reclaim audit trail. Sector-altering.
- Q4 (Feb–Apr 2027). Investor conversations. Open-core is a familiar story — cite GitLab ($16bn), Sentry ($3bn), PostHog ($3bn) as comps.
Overhead costs (small team reality)
- ~2 hrs/week issue triage on open repos (you, initially)
- ~£500–£1,500 one-off licence/legal review
- Discipline tax: every PR needs an "is this open or closed?" decision. Write it down once.
- Two CI pipelines (public repo + private repo) — ~4 hrs one-off setup
What you give up
- Some engineering elegance — you can't just shove everything in one repo
- "Fully open" purists won't love it (tiny audience in charity sector, so low cost)
- Complexity for future engineers onboarding ("why are there two repos for this feature?")
6. Decision criteria — what should tip you which way
| If this is true for you… |
Lean towards |
| You want the fastest GTM story and religious sector is priority 1–3 | A or C |
| You expect investor conversations in the next 18 months | C or B |
| You're worried about a well-funded competitor cloning you | C or B |
| Team is < 4 engineers and feature velocity is already fragile | B or C |
| You want to differentiate on trust, not price or features | A or C |
| You might sell to councils / government bodies later | C or B |
| You want maximum optionality — can tighten or loosen later | C |
| You want one headline the sector remembers | A |
7. Scorecard — fill in and compare
Rate each path 1–5 on the weighted criteria below. Multiply by the weight (which you can adjust) and compare totals.
| Criterion |
Weight |
Path A (Open) |
Path B (Closed) |
Path C (Open Core) |
| Trust / sector credibility |
__ |
__ |
__ |
__ |
| Moat protection against fork |
__ |
__ |
__ |
__ |
| Dev velocity at small team size |
__ |
__ |
__ |
__ |
| Investor / exit story |
__ |
__ |
__ |
__ |
| Reversibility / optionality |
__ |
__ |
__ |
__ |
| Sales cycle impact |
__ |
__ |
__ |
__ |
| Ops / maintenance overhead (higher = worse, score inversely) |
__ |
__ |
__ |
__ |
| Future proprietary features headroom |
__ |
__ |
__ |
__ |
| TOTAL (weighted) |
— |
__ |
__ |
__ |
8. One-week decision sprint
- Day 1 — self-scoring. Fill in section 7 yourself. Don't overthink.
- Day 2 — friction test. Call 2 pilot charities. Ask: "If I told you our code was public, would that make you more or less likely to buy?" Don't lead.
- Day 3 — competitive read. Check Dona, GoodBox, CAF Donate, GiveALittle — has any moved on openness recently? If so, the window is closing.
- Day 4 — legal. 30-min call with a UK IP solicitor. Cost ~£150. Confirm there's no contractor IP risk either way.
- Day 5 — finance. Revisit the 6-year projection under each path. Path A may have +5–10% win rate and −1–2 pt price ceiling. Path B may have +1–2 pt gross margin but −10% religious-sector win rate. Model it.
- Day 6 — decision. Write a one-page memo with the call + the trigger that would make you switch.
- Day 7 — execution kick-off. Whichever path: start week 1 of the relevant playbook above.
9. Two irreversible mistakes to avoid
- Shipping open then pulling back. You can never un-publish. Do not go open unless you have sat with it for a week and are willing to live with it for 3 years.
- Going closed without registering the trademark and locking contractor IP. Your entire moat rests on this paperwork. £170 + £500 in solicitor time is the cheapest insurance you'll ever buy.