How Selah gets built

The implementation plan.

Five gated phases, the tasks inside each, and the engineering disciplines that cut across all of them. Test-driven, template-bounded, and honest about what stops the build.

The rules that shape every other rule

Six non-negotiables, applied to every phase.

This is formation software holding the most intimate data a person can write. Everything below is downstream of these.

Humans author every session. The AI only selects among author-approved options and writes bounded framing prose. Templates bound it; doctrine is structurally impossible in a generative slot.

No journal plaintext ever crosses a boundary. Journals are field-level encrypted, and never sent to the model, the audio provider, analytics, or logs.

Every content mutation writes an append-only audit row. The public theology changelog is generated from those records, so transparency is a database property, not a blog habit.

A church leader can only ever see two numbers. The schema simply has nothing else to leak.

The guardrail validator is the most-tested code in the system. On any rejection it falls back to the author's default, never an error, never unbounded text.

The red line holds: no crisis prediction, no biometric inference, no mental-health claims, in code, copy, or marketing.

The five phases

Each phase ends with a gate. A failed gate means stop or re-scope.

The gates were written calm, to be obeyed under pressure. Weeks are focused engineering; the months are elapsed time including advisor work, pilot ramp, and review.

Phase 0 · M0
weeks 1 to 4 · mostly non-code

Foundations

Answer the credibility and content questions before writing expensive code. Advisor recruitment is the long pole, so it starts on day one.

Recruit 2 to 3 credentialed advisors: charter, honorarium, signed.
Write the content standards doc.
Write 15 templates (3 seasons of 5), tone-tested with 10 real people.
Draft changelog v1 and make it public.
Fork the stack skeleton into a clean repo; stand up the CI skeleton.
Write the guardrail test list first (red).

Exit gate

Advisors signed, 15 templates reviewed and approved, changelog v1 public. No advisors, no ship. Personalization does not go live without the credibility floor.

Phase 1 · M1
weeks 5 to 14 · about 320h

MVP build

Guardrail-first and test-first. The validator that makes "AI assembles, humans author" mechanically true is written before anything reaches a user.

Guardrail layer green (its tests written first).
Template compile pipeline plus the versioned template DB.
Session assembly, the TTS adapter, and one provider.
Session player, journal (encrypted), season check-in, Lens Picker, why-drawer.
Onboarding including the guest to account merge.
PWA and offline: cache the next 3 sessions; queue journals offline.
Admin UI v0. Expand the template spine to 45.

Exit gate

You and 5 friendly users complete 14 consecutive days with no friction failures, and guardrail coverage is at least 90%. If offline sync ever loses a journal entry in testing, it does not ship until fixed.

Phase 2 · M2
months 4 to 6 · about 160h + partnership time

Church pilot

Real congregations, manual onboarding, and a tight feedback loop. This is the phase whose gate decides whether Selah scales at all.

Church, group, and code models with member and leader views (counts only).
Analytics events live (retention only, never journal content).
Weekly iteration on pilot feedback; feedback-flag triage loop.
Expand the template spine to 90.
Run 3 to 5 churches, about 200 users.

Exit gate

At least 25% week-4 retention, and at least 2 churches willing to co-promote at launch. Below the retention gate, stop or hold Selah as a ministry project. Do not spend on growth.

Phase 3 · M3
months 7 to 9 · about 120h

Paid launch preparation

The first paid plan, priced honestly, with an ethical paywall and a real cancel flow.

Stripe live: tiers plus the founding-member discount (a discount, not free).
The ethical paywall, and billing and cancel flows.
Install-prompt polish; website waves 2 and 3.
Work the launch checklist to zero.

Exit gate

Launch checklist clear, payments green end to end, the founding cohort priced in. No fake urgency, no dark patterns in the paywall. Decline is a first-class outcome.

Phase 4 · M4
month 7 onward · about 15h/week

Paid launch & compounding

Launch through the pilot and church channel, then compound with seasonal content, on evidence only.

Launch to the pilot list, the church channel, and season-page SEO.
Seasonal drops for Advent and Lent.
Church-tier expansion, built only on pull from real churches.

Exit gate

At least 500 paying subscribers by month 12. Below the threshold, freeze acquisition spend. The plan traces to gates, not to market-size arithmetic.

Cross-cutting

The disciplines that hold the phases together.

These apply to every step rather than sitting inside one. They are what make the marketing claims mechanically true.

Architecture & stack

Fork a proven stack skeleton into a clean repo: Next.js and React, Drizzle on PostgreSQL, Better Auth, Stripe wired for billing and webhooks, and an LLM client. Host on Vercel with Neon Postgres and object storage for audio. The skeleton is roughly 40% of the technical surface, already proven in production shape.

A mobile-first PWA installs to the home screen and caches the next 3 sessions (today and two ahead), text and audio, so the morning ritual survives dead spots and flights. Journals composed offline queue in encrypted local storage and sync on reconnect, so connectivity never loses an entry. Audio is pre-generated behind a swappable provider interface and labeled honestly in-app as synthesized, so human recordings become a new adapter, not a rewrite.

Template-bounded personalization

Templates live in the database, versioned and immutable once published. The model fills explicitly marked slots only: scripture-emphasis and tone are selections from an author-approved whitelist, and the single generative slot writes a short, bounded piece of connective framing that is structurally incapable of carrying doctrine. A guardrail validator checks every output against the slot manifest, and on any rejection it renders the author's default. The user gets a slightly less personalized session, never an error, never unbounded text.

Why this design. It makes the claim "the AI assembles, humans author" a property you can test. You test a validator, not a model.

Privacy engineering

Season selections and journals reveal religious belief, so the lawful basis is explicit, unbundled consent, logged and withdrawable. Journals are field-level encrypted with envelope encryption and a per-user key, so database backups, replicas, logs, and a curious admin all see ciphertext only. There is no plaintext column. Export and delete are self-service, two screens from Settings, and deleting an account destroys the wrapped key (crypto-shredding). Journal content is never sent to the model, the audio provider, or analytics, enforced by tests and a lint rule, not by discipline.

Testing & TDD

Red-green-refactor throughout; the guardrail and privacy code is written test-first without exception. The first tests prove that output outside the slots is rejected, that doctrine-bearing slots accept only whitelisted values, that an explicit check-in always outranks any inference, and that inference never touches crisis or medical territory. Contract tests assert the leader endpoint returns exactly the member count, who practiced this week, and the current series, and nothing else: the privacy boundary as a test. End-to-end tests freeze the clock to prove next-day adaptation, run the church-code redemption flow, and complete a session in airplane mode. The coverage gate is about 90% on the guardrail and personalization modules, not global-percentage theater.

Content operations

Templates are markdown with frontmatter in the repo, compiled into database rows on publish, so git is the versioning and review tool: pull requests, diffs, and history for free. A tiny admin UI handles only review, publish, changelog composition, and feedback triage. Doctrine-bearing changes cannot publish without recorded advisor sign-off, and the public changelog is composed from the same audit records that govern the system.

Analytics, honestly scoped

First-party retention events only: onboarding steps, session started and completed by template family, journal saved as a boolean fact with no content or length, the paywall declined so we can prove it is not coercive. Never journal content, never a season label to a third party. D1, D7, and D28 are derived from completions; the week-4 number is the pilot gate.

The bar

Definition of Done.

Tests written first exist and pass; the guardrail and personalization coverage gate holds.

No journal plaintext crosses a boundary (lint and tests green).

Accessibility passes AA in both day and Compline, with focus states and reduced-motion.

It works offline where the feature promises to.

Any content mutation writes an audit row.

The copy is warm, plain, and honest. When in doubt, quieter.

Verified on a real 360px device, behind a preview deploy.

Nothing in it crosses the red line: no crisis prediction, no biometric inference, no mental-health claims, ever.

The red lines are absolute. No crisis prediction, no biometric inference, no mental-health claims, no covert profiling, no data sales. If any gate or growth number ever appears to depend on one of these, the answer stays no.

Every stage spends the minimum to answer the next question.

Read the roadmap for how the phases sequence, the risks for the kill and freeze conditions, or the theology page for how the guardrail keeps the content honest.