Heritage Docs

Appearance

0018 — Pony Express Delivery Network ​

Status: Accepted (2026-06-18 — owner accepted during ADR review)

Date: 2026-06-17

ADO work item: AB#3100

Deciders: Kristopher Turner (platform owner)

Context ​

Heritage Virginia is a geographically dispersed rural community. Members already help one another with practical errands — picking up groceries, dropping off supplies, transporting items between households — but this coordination happens informally, through phone calls and group texts, with no shared record of offers or requests.

The Pony Express Delivery Network (Epic AB#3078; Feature AB#3100) formalizes that pattern as a community coordination layer: members can post delivery or errand offers (I will be in Bristol on Thursday — anyone need something picked up?) and requests (Need a prescription collected from Wise), and the platform facilitates matching. It is a listing and coordination feature, not a logistics or payments product.

This ADR is forward-looking. Pony Express is a Phase 7 signature feature — it will not enter active development until Phases 1–6 (platform, iOS shell, Sermons & Music, Calendar, Messaging, Android) are complete. This record captures intent, the binding constraints that must hold, and the trust-and-safety boundaries that will govern a fuller implementation ADR written before Phase 7 begins. Detailed decisions on routing algorithms, scheduling, and notification flows are explicitly deferred.

Why this needs an ADR now ​

The feature involves real-world, in-person, member-to-member activity — physical handoffs of goods between people. That raises trust and physical-safety concerns (security audit S2) that, if addressed late, could require significant redesign. Recording the governing constraints early ensures every upstream platform decision (RBAC, identity, the account/family model) is compatible with the feature before it reaches build.

Constraints inherited from earlier ADRs ​

  • Closed, minister-approved membership (ADR 0007). Every participant is a vetted, named adult member approved by the minister. This is the single most important mitigation for in-person trust risk: anonymous participation is structurally impossible.
  • API-first, no client business logic (ADR 0008). Coordination logic — offer/request state, matching, status — lives in apps/api; clients consume it via api-client.
  • Server-side RBAC, five canonical roles (ADR 0006). Feature access is gated on platform roles; the feature does not define its own authorization plane.
  • Azure SQL (ADR 0004). Offers, requests, and status records are stored in the platform database; no external data store.
  • Cost: free or cheap (ADR 0004). No third-party paid logistics, routing, or mapping SaaS for the MVP of this feature.

Decision ​

We will implement the Pony Express Delivery Network as a coordination-only, listing-and-matching feature within the closed, minister-approved community: members post delivery offers and errand requests; the platform matches and tracks status; the platform is explicitly not a courier, does not handle payments, and accepts no financial or physical liability. Trust is grounded in the existing vetted-membership model (ADR 0007), supplemented by report/block, a one-time liability/waiver acknowledgement, and clear community-facing framing. Detailed implementation (routing, scheduling, notifications design) is deferred to a Phase 7 implementation ADR.

Governing constraints — non-negotiable ​

These constraints must hold in any implementation. They are not subject to re-decision without superseding this ADR.

  1. Members only. Offers and requests are visible only to authenticated, approved members. No public-facing exposure; no guest participation.
  2. Coordination only — no payments, no liability. The platform connects willing members; it does not broker, insure, guarantee, or transact. Any compensation between members is entirely outside the platform. There is no payment collection, escrow, or dispute mediation.
  3. Liability/waiver acknowledgement. Before a member creates their first offer or request, they must acknowledge a plain-language notice: coordination is community-voluntary; the platform and the church accept no responsibility for loss, damage, or failure to deliver. This acknowledgement is recorded in the platform (a flag on the member record, not a legal contract managed by the platform — legal review is the church's responsibility).
  4. Report/block. Any member can report a user or flag a listing. Reports are visible to platform administrators (Minister/Admin role). Block removes a member from your offers and requests.
  5. No routing or real-time tracking. The platform records offer/request/status; it does not provide turn-by-turn routing, live location tracking, or delivery proof. These are out of scope and out of cost constraint.
  6. Platform composition rules (ADR 0008) apply. Feature logic is an apps/api slice consuming platform auth, RBAC, notifications transport, and audit log. No direct database access from clients.

Safety framing — community-facing ​

The feature is positioned as a natural extension of how this community already helps one another, not as a gig-economy service. Copy and UX must reflect this: "Help a neighbor" not "Request delivery"; "Offer to help" not "Post a job". This framing is a product constraint, not a post-launch consideration.

Alternatives considered ​

OptionProsConsWhy not chosen
Coordination-only listing + matching, members only (chosen)Stays within closed community; no payment complexity; trust grounded in vetted membership; low costPlatform not responsible for fulfillment; requires cultural norm-setting— chosen
Integrate a commercial delivery/gig platform (DoorDash, TaskRabbit, etc.)Handles logistics and payments externallyBreaks closed community (third-party identity, public exposure); adds cost; third-party data exposure; commercial liability model contradicts coordination-only intentRejected — undermines every closed-community guarantee
Add payments or escrowEnables compensation trackingIntroduces PCI compliance scope, payment-processor cost, dispute-mediation complexity, and financial liability; entirely out of cost constraintRejected — out of scope; coordination must remain non-transactional
Open to non-members (public errand board)Larger pool of helpersRe-opens S2 trust and physical safety (unknown participants); destroys the closed-community model; contradicts ADR 0007Rejected — the closed community IS the trust model
Full logistics platform (routing, scheduling, live tracking)Rich delivery experienceHigh engineering cost; maps/routing SaaS cost; real-time tracking raises COPPA and location-privacy concerns; far exceeds scopeRejected — scope and cost constraint; deferred to post-MVP consideration

Consequences ​

Positive ​

  • The vetted, minister-approved membership model (ADR 0007) provides a trust baseline that a public platform cannot match — in-person activity between known, named community members is substantially lower risk than anonymous marketplaces.
  • Keeping it coordination-only eliminates payment compliance (PCI), financial dispute handling, and courier liability — the most complex and costly aspects of delivery products.
  • The feature extends the platform's existing API-first, RBAC, and notification infrastructure (ADR 0008) without requiring a new technical plane.
  • Report/block and the waiver acknowledgement give administrators a safety lever without requiring a dedicated trust-and-safety team at this community scale.

Negative / trade-offs ​

  • The platform cannot guarantee fulfillment — a member who accepts a request may not follow through. The community and minister manage this socially; the platform can only log and report.
  • The waiver/acknowledgement notice requires legal review by the church before the feature ships. The platform records acknowledgement; it does not draft or own the legal language.
  • "Coordination only" will require ongoing product discipline: if payment hints (Venmo links, price fields) creep into the UX, the feature drifts out of scope. The product owner must actively hold the line.
  • A fuller implementation ADR (Phase 7) must revisit notification design, offer/request expiry, and the directory-visibility intersection with ADR 0007's privacy controls.

Risks ​

  • Neighbor dispute escalation. A failed delivery or damaged item could damage community relationships. Mitigation: clear platform framing (coordination only, community-voluntary), a report path to administration, and the minister's existing community-relations role.
  • Feature scope creep toward logistics. Pressure to add routing, tracking, or delivery proof. Mitigation: this ADR's governing constraints are non-negotiable; any extension requires superseding this ADR.
  • COPPA intersection. If a parent-managed child account is a party to a delivery interaction (e.g., listed as a recipient), PII handling must follow the ADR 0007 child sub-account rules. Mitigation: implementation ADR must explicitly scope which account types can initiate offers/requests.
  • Waiver acknowledgement is not a legal contract. The platform records a click; it does not provide legal protection. Mitigation: church legal review before launch; the platform's role is strictly to record that the notice was shown and accepted.

References ​

Heritage Community Hub — Internal. Access restricted via Cloudflare Access + Entra ID.

Heritage Virginia · Owner: Kristopher Turner