Quartz 4

lora astrology app

7 min read

AI Astrology App — Product & Technical Spec

Version: 0.1 (v1 scope) Platform: iOS (Expo / React Native), Android optional later Stage: Pre-build scoping

1. Product Summary

A solo-experience AI astrology companion for women 20–35 who use astrology as a framework for self-reflection and self-mastery. The app delivers the experience of having a personal astrologer who knows you, remembers every conversation, and connects current transits to your actual life history.

Core differentiation vs. ChatGPT, Claude, and Co-Star: persistent memory anchored to the user’s natal chart and transit history. The product feels like a continuation, never a reset.

Target ICP: NYC-style young professional women, astrology-curious to astrology-committed, already engaged with daily astrology content.

Distribution: Existing 190k web app users, influencer network. Distribution is largely solved.

Monetization: Freemium. Free tier delivers daily horoscopes + limited chat. Paid tier unlocks unlimited chat, deep-dive reports, transit forecasting, and the proactive insights feed.

2. Goals & Non-Goals

Goals

  • Daily engagement equivalent to a journaling habit.
  • A conversational astrologer that remembers user-specific context across months and years.
  • Proactive insights surfaced on transit-driven schedules (the “Wrapped moment” applied to astrology).
  • A defensible memory architecture that gets stronger with usage.

Non-Goals (v1)

  • Multiplayer / synastry features.
  • Android.
  • Native iOS rewrite.
  • Fine-tuned proprietary model.
  • Medical, financial, or legal advice framing.

3. Core Loop

  1. User opens app. Daily horoscope card surfaces, personalized to their current transits and prior conversation themes.
  2. User taps to chat with their astrologer. Astrologer references prior conversations, current chart state, and recent life events the user has mentioned.
  3. Weekly digest: report tying the week’s transits to user’s specific patterns.
  4. Monthly deep-dive: longer-form insight surfacing patterns the user hasn’t articulated yet.
  5. Push notifications on significant transits hitting the user’s natal chart.

4. Tech Stack Decisions

Client: Expo (React Native + TypeScript)

Rationale:

  • Hiring pool is larger and cheaper than Swift.
  • OTA updates via EAS allow rapid iteration on prompts, copy, and astrologer voice without App Store review.
  • Optionality for Android when influencer-driven Android acquisition becomes material.
  • Product is text, cards, chat, notifications. None of it requires native performance.

Tradeoff acknowledged: Co-Star’s design polish ceiling is harder to reach in RN. Acceptable for v1; revisit at scale.

Backend: Node/TS or Python

Pick based on team strength. Either works. No part of the request path requires a specific runtime.

Chart Calculation: Swiss Ephemeris

  • Run client-side via swisseph-wasm or thin native module.
  • Natal chart computed once at onboarding, cached forever.
  • Daily transits computed client-side or in a daily server cron job.
  • No Python service in the request path. Charts are deterministic and fast.

LLM

  • Primary (conversation): Claude Sonnet. Long context window for memory. Quality of voice matters.
  • Extraction (background): Claude Haiku. Cheap, fast, sufficient for structured fact extraction.
  • Embeddings: Voyage or OpenAI text-embedding-3-small. Either works.

Memory Storage

  • Structured facts: Postgres.
  • Semantic memory: pgvector. Do not reach for Pinecone at this scale.
  • Chart-anchored memory: Postgres with indexes on transit signatures.

Notifications

Server-side cron computes daily transits per user, queues personalized push copy generated by Sonnet, delivers via Expo Push or APNs.

5. Memory Architecture

The memory system is the product’s moat. Three stores, queried together at every conversation turn.

5.1 Structured Facts (Postgres)

After every session, a Haiku extraction pass pulls structured records.

Schema categories:

  • Relationships (partner, ex, family, friend, colleague)
  • Career events
  • Family context
  • Recurring emotional themes
  • Life events
  • Stated goals
  • Stated fears
  • Health context (handled with care; no medical framing)

Example record:

{
  "type": "relationship",
  "subject": "Marcus",
  "role": "ex-partner",
  "status": "recent breakup",
  "emotional_valence": "grieving but relieved",
  "first_mentioned": "2026-01-15",
  "last_mentioned": "2026-04-20",
  "mention_count": 12,
  "resolved": false
}

Each record has a relevance score updated on every mention. Decay applied for stale records.

5.2 Semantic Memory (pgvector)

Every user message and astrologer response embedded and stored as chunks. Tagged with timestamp, conversation ID, and detected themes.

On new query: top-k semantic retrieval against this store.

Captures tone, specific phrasings, metaphors that landed — things structured extraction misses.

5.3 Chart-Anchored Memory (Postgres)

Every significant conversation tagged with the active transits at the time:

{
  "conversation_id": "abc123",
  "date": "2026-01-15",
  "active_transits": ["venus_square_natal_saturn", "mars_conjunct_natal_moon"],
  "themes": ["heartbreak", "self-worth"],
  "astrologer_framing_summary": "User framed this as a recurring relational pattern."
}

When the same transit recurs in the future, prior conversations under that signature are retrieved. Enables the astrologer to say: “The last two times Venus hit this point in your chart, we talked about Marcus and then about your father. There’s a pattern here.”

This is the long-term moat. Useless on day one (no history). Critical by month four.

5.4 Retrieval Pipeline (per conversation turn)

  1. Compute or fetch current transits for the user (cached daily).
  2. Pull top structured facts by relevance score (5–10 records).
  3. Vector search against semantic memory for this query (top 3–5 chunks).
  4. Pull chart-anchored memory matching current active transits (top 2–3).
  5. Retrieve relevant interpretive examples from astrologer transcripts (RAG).
  6. Assemble system prompt: persona + transcripts + memory context + current chart state.
  7. Call Sonnet.

5.5 Post-Response Pipeline (async)

  1. Haiku extraction to update structured facts.
  2. Embed and store the exchange in semantic memory.
  3. Tag the conversation with active transits.

5.6 Decay & Consolidation

  • Recency weighting on mention_count.
  • “Resolved” flagging downweights retired topics.
  • Monthly LLM-driven consolidation pass: collapse redundant facts into higher-order patterns (“user has recurring pattern of emotional avoidance in relationships” replaces 15 individual mentions).

6. Astrologer Voice

6.1 Source Material

Transcripts of sessions with the in-house pro astrologer.

6.2 Approach

Not fine-tuning. Volume insufficient and unnecessary.

Yes: RAG over transcripts + carefully constructed system prompt encoding her interpretive framework.

  • Chunk transcripts by topic, aspect, and interpretive move.
  • Embed and store as retrieval corpus.
  • At query time, retrieve relevant interpretive examples and inject into system prompt as few-shot exemplars.

Licensing terms with the astrologer must be signed before any transcript ingestion. Equity, royalty, or buyout — explicit and written.

7. Freemium Structure

Free Tier

  • Daily horoscope tied to actual transits
  • Limited chat (5 messages/day)
  • Basic natal chart view
  • Unlimited chat
  • Weekly deep-dive reports
  • 30/90-day transit forecasting
  • Progressed chart
  • Proactive insights feed (the Wrapped-style retention surface)

Pricing

To be determined. Anchor against Co-Star Premium and Sanctuary.

8. Privacy & Data Handling

This is the most intimate dataset a user will hand over. Treat accordingly.

Requirements

  • Encryption at rest.
  • Strict access controls. No employee browsing of user data.
  • Audit logs for any data access.
  • Airtight data export and deletion. “Forget Marcus” deletes every reference.
  • GDPR / CCPA compliance from day one.
  • No model training on user data without explicit, granular opt-in.
  • Clear in-product disclosure of what is stored and why.

Acknowledged Limitation

End-to-end encryption is impractical given server-side LLM access. Be honest about this in the privacy policy.

9. Cost Model

Per active daily user

  • 1 Sonnet call (~3–5k input tokens with memory context, ~500 output): ~$0.02
  • 1 Haiku extraction call: ~$0.001
  • Embeddings: negligible
  • Vector storage: negligible

At 190k users, 30% DAU

  • ~57k daily sessions
  • ~$1,200/day
  • ~$36k/month inference cost

Optimizations

  • Aggressive prompt caching on persona + RAG portion: 40–60% reduction.
  • Free-tier message ceilings enforced strictly.
  • Batch overnight extraction passes.

10. Build Sequence

Phase 1 (Weeks 0–6): Foundation

  • Expo app scaffold, auth, onboarding (birth data capture)
  • Swiss Ephemeris integration, natal chart computation
  • Basic chat with Sonnet
  • Structured facts memory store + extraction pipeline
  • Daily horoscope generation

Phase 2 (Weeks 6–12): Depth

  • Semantic memory (pgvector) layer
  • RAG over astrologer transcripts
  • Push notifications on transits
  • Weekly digest
  • Freemium gating + paywall

Phase 3 (Weeks 12–20): Moat

  • Chart-anchored memory layer
  • Monthly deep-dive reports
  • Proactive insights feed
  • Memory consolidation jobs

Phase 4 (Post-launch)

  • Refine astrologer voice from production data
  • A/B test insight delivery cadence
  • Evaluate Android via same Expo codebase

11. Key Risks

  1. LLM cost escalation at scale. Mitigated by caching, tier limits, batched extraction.
  2. Memory retrieval quality. Bad retrieval = generic responses = churn. Invest in eval harness early.
  3. Astrologer voice IP. Licensing must be settled pre-build.
  4. Privacy incident. Single breach destroys trust in this category. Security investment is non-optional.
  5. Astrology accuracy / advice claims. Avoid medical, financial, legal framing. Co-Star has been sued; learn from it.
  6. Expo ceiling. If design polish becomes the constraint at scale, native rewrite is a 3–6 month tax. Acceptable v1 risk.

12. Open Questions

  • Astrologer licensing terms.
  • Pricing tier specifics.
  • Onboarding length tradeoff (more birth data = better chart, more friction).
  • Whether the proactive insights feed launches in v1 or Phase 3.
  • Eval methodology for memory retrieval quality.

Graph View

Backlinks