Home / Product / Consumer App

Affirmology Delivery App, spec v1 (the inner-orbit listening app)

Updated Jun 25, 2026 · Affirmology_DeliveryApp_Spec_v1.md

Summary. Status: PROPOSED. This is the consumer-facing app, distinct from Atlas (the team app) and the Studio (the creation workbench), but riding the SAME cloud system (Render + R2 + Cloudflare). It is the place we send the inner orbit to actually listen, react, and t

Affirmology Delivery App, spec v1 (the inner-orbit listening app)

Status: PROPOSED. This is the consumer-facing app, distinct from Atlas (the team app) and the Studio (the creation workbench), but riding the SAME cloud system (Render + R2 + Cloudflare). It is the place we send the inner orbit to actually listen, react, and talk to their blueprint.

TIMELINE (updated 2026-06-18, Jeff): we are NOT building v1 immediately. First we (a) get more starter audios ready for the launch, and (b) stand up a REAL backend and database designed to track all of this and much more as the user base expands and scales (see section 10, now a first-class pillar, not an afterthought). The 4-to-5-day estimate in section 11 holds for the consumer FRONT END once that backend exists; the backend is the part we invest in properly now so we are not rebuilding it at scale.

Working name for the cohort: The Founding Constellation (the free founding-beta tier from the product ladder). The app itself can just be "Affirmology" to them.

1. What this is, in one breath

A private, invite-only app where 20 to 40 trusted people open a beautiful library of their Affirmology audios, listen, rate and give rich feedback, see their own usage build over time, submit ideas, read their reports (and get them by email), and have a conversation with their own oracles (Sophia and the council) about their blueprint. Every tap they make teaches us what to build, what to charge for, and where the membership lines should fall.

It is NOT the public funnel and NOT the team back office. It is the felt, curated "what it is like to be a member" experience, one rung early, for the people closest to us.

2. Where it sits in the system (so we do not build a fourth silo)

One backend, one media store, one auth layer, three faces. The delivery app is the consumer face.

Suggested address: app.affirmology.ai (keeps demo / studio / app cleanly separated on the same Cloudflare zone).

3. Distribution: skip the App Store for v1, ship a PWA

Recommendation: do NOT use the Apple App Store or Google Play for this version. Reasons that matter on a 4 to 5 day clock:

How we push it to 20 to 40 people: send each invitee a link. They open it on their phone, tap Share, then "Add to Home Screen," and it lives there like an app. We include a 20-second "how to install" card on first visit (with the iOS Share-sheet screenshot, since iOS hides install behind Share).

App Store is a real conversation for the PAID public launch later (trust, discovery, in-app purchase). For the inner orbit, a gated PWA is faster, fully controllable, and right.

4. Login and gating (invite-only, by email, no strangers)

Keep it simple and locked. Two options were on the table, both email-based:

DECISION (2026-06-18, Jeff): go with OPTION B. We build our own magic-link / one-time-code login on our own users table. This is the right call given the scale-ready backend in section 10: we are already standing up a real person and membership model that owns identity, tier, entitlements, and profile, so the auth should live in OUR system, not at the Cloudflare edge. It gives a branded sign-in, a real in-app profile, and a clean path straight into paid signup later (the same login becomes the paid-account login; no migration off Cloudflare Access). Invite-only is enforced by our own invite / allowlist table: only emails we have invited can request a login code, so it stays locked to the inner orbit.

How it works: a person enters their email, we check it against the allowlist, and if invited we email them a magic link (or a 6-digit code) via Resend (already our verified sender). Clicking it (or entering the code) creates a session token tied to their person record. No passwords. Standard, secure, well-trodden pattern; the security work is the usual care around token expiry, single-use codes, and rate-limiting, which we build into the window. Cloudflare Access can still sit in front during the closed beta as a belt-and-suspenders outer gate if we want, but our login is the system of record.

5. The core experience (what a member sees)

Brand language is locked: deep emerald, gold, cream; Cormorant Garamond headlines, Inter body, JetBrains Mono tags; no em dashes anywhere; calm, cinematic, "let it land" pacing. Reuse the Studio/site tokens.

5.1 Home

A warm, personal landing: "Welcome back, [first name]." Their oracle's one-line greeting. Quick continue-listening row (resume the last audio). The category grid below. A subtle nudge to whatever is new since they last came (a freshly added audio, a reply from their oracle).

5.2 The Library, organized by category

The heart of the app. Audios grouped into clear categories (the same category model the Studio already uses, so the catalog flows straight through). Starting categories, drawn from what we already make:

EVERY audio is personal. This is non-negotiable and it is our distinction: there is never a generic audio, never a piece that is not built from the listener's own chart. Everything is custom to the person.

So the right way to think about the catalog is SHARED STRUCTURE, PERSONAL CONTENT (the same rule the whole system runs on):

That is what makes the feedback comparable without ever sharing content: everyone is reacting to the same STRUCTURE (so we can compare "how did the Before-Bed structure land across people"), while each person hears only their own chart-driven audio. Apples-to-apples on the structure, never on the file.

Each audio card: title, category tag, length, a one-line "what this is for," and the person's own state (new / in progress / listened, with their star rating once given). The whole library is "yours," because all of it is.

POSSIBLE LATER, NOT DECIDED (Jeff, 2026-06-18): audios a member shapes themselves through the oracle chatbot. This is NOT a confirmed v1 feature. The likely shape is a time-limited preview (a week or two) of the advanced membership tiers, offered AFTER a member has experienced and given feedback on the first suite, so they get a taste of self-directed custom creation as part of testing the upgrade path. Even then, every such audio is still 100 percent chart-driven. See sections 7 and 9.

5.3 The Player (make it a real experience, not a file)

5.4 Usage cataloging (passive, automatic)

Every play is logged: which audio, when, how far they listened (started / partial / completed), how many times, and listening streaks. The member sees a gentle personal view ("You have listened 14 times this month; your most-returned-to audio is [X]"), which itself is a retention hook. WE get the real signal: what gets replayed, what gets abandoned mid-way, what categories pull people back. This is some of the most valuable data in the whole exercise.

5.5 Offline listening (required)

Each person's audios must be available OFFLINE. This is a core requirement, not a nice-to-have, because the best listening moments (a flight, a walk with no signal, pre-sleep with the phone on airplane mode, the gym) are exactly when people lack connection, and a meditation app that buffers or fails offline breaks the spell.

How it works:

Technical path (consistent with the PWA in section 3): use the service worker plus the Cache Storage / IndexedDB APIs to store the audio files and metadata on-device. R2 stays the source; the device holds a synced copy. This is standard PWA offline-media territory and well within the stack. Native app stores are still NOT required for this; a PWA caches media offline fine.

This is also why the app is a genuinely great LISTENING place, not just a delivery mechanism: instant, reliable, offline-first playback of audios made just for you.

6. Feedback and ratings (detailed, low-friction, from everywhere)

We want rich reactions without making it a chore.

PROACTIVELY SOLICIT THE MISSING FEEDBACK. People listen and forget to rate, and an unrated listen is a hole in exactly the data we are here to collect. The event spine makes this easy: any audio with a play_completed (or a substantial play_progress) but no rating_given is a pending-feedback item. The app then nudges, gently and without nagging:

All ratings and feedback flow into the same store the Studio reads, so the team sees member reactions next to the build report for each audio.

6.5 Shape Affirmology (upcoming features, voting, and suggestions)

A dedicated surface where members help steer what we build. This both deepens their investment (their effort and energy goes into the product, which is exactly the viral, ownership feeling we want from a founding cohort) and gives us a clean, rankable signal of demand.

Two parts, one place:

Each item ties to the person and (where relevant) their chart, so "who wants what" is analyzable alongside the chat and usage data. Voice-note suggestions are welcome (transcribed). This is a lightweight build (a votes table plus a roadmap_item / suggestion table, see section 10) and pays for itself in roadmap clarity. For scale, this is the same pattern paid tools like Canny or Featurebase sell; we build it natively so the data lives in our system, not a third party's.

6.6 Community: WhatsApp now, in-app forum later (recommendation)

Jeff's lean is a WhatsApp channel over an in-app discussion forum, and I agree for this stage. The reasoning:

Two WhatsApp shapes to choose between: a CHANNEL (one-to-many broadcast, great for announcements and "new audio is live," low noise, little back-and-forth) or a GROUP (many-to-many, real community feel, but gets noisy and caps out as it grows). For a founding cohort, a GROUP is the better community feel now; switch to a CHANNEL for broadcast plus smaller groups as the base scales.

Build the in-app forum LATER, when (a) the base is large enough that threads stay warm on their own, or (b) we specifically want that discussion data inside our system for the membership product. Until then it is build cost and moderation we do not need. Decision flagged in section 12.

7. The Oracle chatbot (talk to Sophia and the council about your blueprint)

This is the viral, sticky, and most strategically revealing feature. A member can open a chat and talk to their oracles about their own blueprint.

7.1 What it is

A chart-grounded conversation. The member is talking to Sophia (the synthesist, the default voice) and can be handed to the right specialist oracle for depth: Hermes (Western astrology), Parashara (Vedic), Pythagoras (numerology), Prometheus (Human Design), Athena (Gene Keys), and the relationship lenses (Eros, Concordia, Hestia) when they ask about a relationship and provide the other person. Apollo conducts behind the scenes; the member mostly experiences Sophia plus whichever specialist is relevant.

It is grounded in THEIR computed chart and the tier-walled corpus (A/B sources only), so it speaks to who they actually are, never generic horoscope filler. It leads with recognition, then offers the organized information, the same order the whole product follows.

7.2 Hard guardrails (decide the line here, section 9 expands)

7.3 Why we are doing it (the intelligence flywheel)

Every conversation is logged and analyzable (with the cohort's knowledge; this is a beta of trusted people). We learn, in their own words: what they keep asking about, what they want, what they desire, what revelations land, where they get emotional, what they would pay to go deeper on. That directly answers the membership-design questions Jeff raised:

We should add a lightweight "insight digest" for the team (weekly): top themes, most-wanted audios, standout quotes, emotional hot-spots. (This pairs with Echo, the cultural-listener role, but pointed inward at our own people.)

8. Reports (in-app and pushed to email)

Members can see their reports inside the app and send them to themselves by email.

9. Membership-tier strategy this app is designed to inform

Jeff's strategic questions, framed so the beta produces the answers. The product ladder (draft) is: Starter Kit (~$50 to $88, 10 to 12 audios, steps 1 and 2), Base Membership "Inner Orbit" (~$15 to $22/mo, transit updates plus a chart-grounded chatbot plus a few journeys), Premium "The Constellation" (deeper journeys, a more robust chatbot, a couple of custom audios), and Affirmologists (pro creators).

The chatbot is the clearest lever, so define it as a tiered capability:

Where to draw the custom-audio line (the key decision the beta should settle): custom, chart-driven audio generation is our highest-cost, highest-value act. Lean recommendation, to validate: the chatbot freely TALKS at every tier; it only DELIVERS custom audio at Premium and above, and even there it is metered (a credit count), with single one-off custom audios sold as à la carte upsells from any tier. The beta's chat logs and "I wish there were an audio for X" captures tell us demand, willingness, and the right meter. The app instruments exactly this: it tracks every custom-audio wish and every place a member hits the "talk only, no audio yet" wall, so we can price the wall correctly.

TIME-LIMITED ADVANCED-TIER PREVIEW (Jeff, 2026-06-18, not yet decided): rather than a standing feature, we may give founding members a one-to-two-week TASTE of the advanced tiers (the robust chatbot plus self-shaped custom audio) AFTER they have listened to and given feedback on the first suite. This both rewards their feedback and lets us watch real upgrade behavior (do they use it, what do they make, would they pay) on a fixed clock. Entitlements and metering in section 10 already support a time-boxed grant, so this is a config, not a rebuild. Everything created in the preview is still fully chart-driven.

10. Backend and data architecture (built for scale, the real investment)

This is the part we build properly NOW, before the consumer front end, because it has to carry us from 40 founding members to a paying user base without a rebuild. The Studio's SQLite store is fine for the team workbench; it is NOT the system of record for a scaling consumer product.

10.1 Principles

10.3 Schema (the tables, designed for scale)

10.4 What the backend unlocks beyond v1

Because the schema carries tiers, entitlements, metering, and a full event history from the start, the same backend later powers: paid signup and billing, the Starter Kit and membership tiers, the Affirmologists' member lists (their people create accounts and give email, which is the growth-engine data capture), the team insight digest, and the analytics that tell us what to build and what to charge. We invest once here so the consumer app, the paid product, and the creator economy all read from one place.

Privacy posture for the cohort: these are trusted founding members; we are explicit and warm that the beta is observed so we can build. Keep it clean and respectful, keep the tier-walls and content-never-shared rules absolute, and keep the consumer data cleanly separated and access-controlled from the start (it will hold real customer PII as we scale).

11. Build plan for 4 to 5 days (reusing what exists)

PREREQUISITE (done first, not part of the 4 to 5 days): the scale-ready backend and database from section 10 (Postgres system of record, the schema, the event spine) and more starter audios approved in the Studio. The day-by-day below is the consumer FRONT END once that backend exists. Most hard parts already exist (cloud engine, R2 media, charts, reports, brand UI), so the front end is a curated consumer surface plus the chat and offline layers.

Cut lines if time runs short, in this order to drop: the ambient listening visual (player works without it), voice-note feedback (keep text), and the automated insight digest (we can query the data by hand for the first week). The audio library WITH offline playback and the oracle chatbot are the things that must ship.

12. Open decisions for Jeff (so v1 does not stall)

  1. Login: DECIDED (2026-06-18) - Option B, our own magic-link / one-time-code auth on our own users table, invite-gated by our allowlist. See section 4.
  2. Cohort and catalog: who are the first 20 to 40 (the Founding Constellation list), and which exact audios make the starting suite (the test-suite keepers plus which new ones, per category)? Personal audios per person, or shared suite only at first? (Jeff is readying more starter audios before the build.)
  3. Community shape: confirm WhatsApp GROUP to start (recommended) vs CHANNEL, and confirm the in-app forum is deferred. See section 6.6.
  4. Offline default: auto-download a person's audios + the starter suite on first login over Wi-Fi (recommended), or download-on-demand only? See section 5.5.
  5. Chatbot line for the BETA specifically: talk-only for everyone in the beta (cleanest for learning demand), or let some members trigger a custom audio so we can watch that behavior too?
  6. Observation consent wording: how explicit do we want to be with the cohort that chats and usage are studied to build the product (recommend: clearly and warmly, since they are founders)?
  7. Naming: call the app simply "Affirmology" to members, with the cohort named "The Founding Constellation"? Confirm.
  8. Voice for the oracle chat replies: text-only in v1, or do we want spoken oracle replies (ElevenLabs / the Fish A-B) later? (Recommend text in v1, voice as a fast-follow.)

Bottom line: ship a gated PWA on the existing cloud, reuse the engine, charts, R2 media, reports, and brand, and spend the new build budget on the three things that make it an experience: a real listening library, feedback that is everywhere and rich, and a chart-grounded oracle chat that doubles as our membership-research instrument. No App Store needed for the inner orbit; that conversation belongs to the paid public launch.

Related documents

Affirmology app delivery plan, v1 (Atlas + Affirmology to real iOS apps)Affirmology Atlas - app spec (v1)Affirmology End-User App, v1 Spec (player-first)Affirmology app architecture decision, v1 (native vs wrapper, answered honestly)Affirmology app build briefs, v1 (overnight Claude Code package)