Why Your Astrology App Needs a Timeline View (and How to Build One)

The transit-only era is over

Co-Star did $15M ARR by sending pithy push notifications and showing outer-planet transits. The Pattern crossed 50M downloads with the same single technique plus a psychology gloss. Both apps own the casual end of the market. Both apps have hit the ceiling of what one timing layer can support, and the App Store top charts now show the consequence: every new transit-only launch looks like the last, churn sits at 6-8% monthly across the category, and CAC keeps climbing because differentiation is gone.

There is a reason this is happening. Transits are the lowest-effort timing technique to implement, the easiest to explain in one sentence, and the most commoditized. Every astrology API ships them. Every consumer app shows them. Discounting and influencer marketing eat into margin, and you end up running a paid-acquisition treadmill against a churn rate you cannot fix at the product layer.

What a Timeline view actually looks like

A Timeline view is a horizontal calendar with 4-5 stacked rows. The x-axis is time. Each row is one timing technique, segmented into colored bands that represent active periods.

1today
2                       │
3  Profection  │ 6th house ──────┼── 7th house ──────────────│
4              │ Mercury LOY     │   Venus LOY               │
5  Firdaria    │ Mercury / Venus ┼─ Mercury / Sun ───────────│
6  ZR (Spirit) │ Sagittarius L1  ┼  └── Capricorn L2 ────────│
7  Decennials  │ Sun / Mars ─────┼── Sun / Jupiter ──────────│
8  Transits    │   ⌐── Saturn square LOY ─────┐              │
9              │                                              │
10              └── Jun '25 ────── May '26 ─────── Apr '27 ───┘

Each row has its own rhythm. Annual profections roll once a year on the solar return, so the band is wide and predictable. Monthly profections roll every 28-30 days inside that annual band, which gives you a useful second-tier accent stripe. Firdaria L1 periods last 6-13 years depending on which planet's turn it is, with shorter L2 sub-periods of months inside. Zodiacal Releasing periods are sign-length. Aries L1 lasts 15 years, Cancer L1 lasts 25 years, and L2 sub-periods can be anywhere from a few months to two years depending on the sign. Decennials run 10 years for L1 with shorter L2 inside, computed in Chaldean order and adjusted for the chart's sect. The transit overlay sits on top as discrete arcs. Saturn conjuncts the LOY for roughly 12 weeks. Jupiter trines Mars for roughly 6 weeks. The arcs are short and bright against the slower bands underneath.

The user does not need to know which row is which technique to find the view valuable. They just see "today" as a vertical line, and they can see how many bands are converging on it. Bands converging on today is the entire UX. That is the moment users screenshot and post to TikTok. From a product perspective, the timeline gives you four monetizable surfaces in one screen: tap a band for an explainer, tap "today" for a daily summary, tap a future band for a forecast, tap the transit arc for an electional micro-window. Every consumer astrology app needs that surface area to support more than one in-app purchase.

The before: 4-6 API calls and a stitching problem

Until last week, building this view meant calling four to six endpoints and stitching results in your client.

A typical implementation:

1. POST /v3/profections/annual for the current profected sign and Lord of the Year
2. POST /v3/profections/monthly for the monthly LOY
3. POST /v3/firdaria/periods for L1 + L2
4. POST /v3/zodiacal-releasing/periods for Spirit-anchored L1 + L2
5. POST /v3/decennials/periods for L1 + L2
6. POST /v3/transits/outer-to-natal for the overlay

Six round trips. Six sect calculations that have to agree. Six timezone normalizations. Six places to introduce a bug. If your client is a mobile app on a flaky connection, that is roughly 1.5-3 seconds of network time on a cold launch, and one failed call leaves the view half-rendered. You then build retry logic per endpoint, a partial-render state, an error toast for each timing technique, and a logging story that distinguishes a profections-call failure from a ZR-call failure. The complexity compounds and your timeline view ends up being three files of integration code before you write a line of UI.

There is also a correctness trap. Sect (day chart versus night chart) flips the Lord of the Year math for some traditional rulership schemes, changes the Chaldean rotation in decennials, and determines whether Spirit or Fortune is the default ZR anchor for vocational readings. If any one of your six endpoint calls uses a slightly different sect heuristic than the others, your timeline will show subtly inconsistent lords across rows. That bug is invisible in dev and obvious to any user who knows enough to care.

The endpoint walkthrough

1{
2  "target_date": "2026-05-18",
3  "sect": "diurnal",
4  "profection": {
5    "annual": { "house": 7, "sign": "Libra", "lord": "Venus",
6                "start": "2025-06-15", "end": "2026-06-15" },
7    "monthly": { "house": 11, "sign": "Aquarius", "lord": "Saturn",
8                 "start": "2026-05-15", "end": "2026-06-14" }
9  },
10  "firdaria": {
11    "l1": { "lord": "Mercury", "start": "2023-06-15", "end": "2036-06-15" },
12    "l2": { "lord": "Venus",   "start": "2025-12-01", "end": "2027-02-21" }
13  },
14  "zodiacal_releasing": {
15    "anchor": "spirit",
16    "l1": { "sign": "Sagittarius", "lord": "Jupiter",
17            "start": "2018-04-02", "end": "2030-04-02" },
18    "l2": { "sign": "Capricorn",   "lord": "Saturn",
19            "start": "2026-01-11", "end": "2028-08-22" }
20  },
21  "decennials": {
22    "l1": { "lord": "Sun",  "start": "2020-06-15", "end": "2030-06-15" },
23    "l2": { "lord": "Mars", "start": "2026-03-30", "end": "2027-08-12" }
24  },
25  "transits_to_loy": [
26    { "transiting": "Saturn", "aspect": "square", "exact": "2026-07-04",
27      "start": "2026-05-20", "end": "2026-09-12" }
28  ],
29  "metadata": {
30    "warnings": [],
31    "engine_version": "swisseph-2.10.03"
32  }
33}

The 3-tier UX strategy

The Timeline view is also a monetization wedge. Hide rows behind tiers. Users who want depth will pay for it.

Each row you unlock is a reason to upgrade. Each row you hide is a discoverable upsell. The Timeline view turns into a pricing page that the user actually wants to scroll through.

Subscription wedge math

Here is the math that determines whether you should build this.

Apple CPI for an astrology-vertical install runs $4-8 depending on geo and creative quality. Call it $6 blended. To pay back CAC at a $9.99/month price point with Apple's 15% small-business cut (net $8.49), you need the user to retain for 0.71 months. That sounds easy until you look at the data. Transit-only apps retain Month 1 paid users at roughly 60% and Month 6 at 25-30%. LTV ends up around $35-45 per paid user. Net of CAC, App Store fees, and refunds you make $10-20 per paid user before any content or support cost.

Hellenistic apps with multi-layer timing retain Month 1 at 75-80% and Month 6 at 45-55% based on what operators in this niche report on public podcasts and indie-Twitter threads. LTV moves to $80-110. Same CAC. The net per paid user roughly triples. That is the entire reason the depth tier exists as a business strategy.

Translate to a small indie shop. 10,000 monthly installs from organic + light paid spend. 3% paid conversion = 300 new paid subs per month. At $70 LTV (mid-range Hellenistic) that is $21k of cohort value per month, or about $250k annualized run rate. Same funnel built on transit-only gives you $90k. The Timeline view is worth roughly $160k/year in this scenario before you account for the better word-of-mouth coefficient that depth-first apps see in the App Store reviews.

Time-to-build, hand-stitched vs. aggregator

Engineering cost matters because indie shops have one or two builders. Hand-stitching the six-endpoint approach takes a competent backend developer about 5-7 days of focused work: four to write and test each endpoint integration, one to harmonize sect and timezone handling, one to build the partial-render and retry UX, and a buffer for the bugs that always show up in QA. That is before you write a single line of timeline UI.

There is also a maintenance argument. Each of the six underlying techniques has its own edge cases. When you find a profections bug at age zero or a ZR sign-length question, you debug it once on our side rather than across six client integrations across your iOS and Android codebases.

What you can build in a weekend

A concrete product, scoped to a real Friday-to-Sunday window.

You will not hit those numbers in the first month. You might hit them by month six if the timeline view does what it has done for everyone else who shipped it. The category is small enough that one good launch can move you into the top 10 paid astrology apps in a country and large enough that the top 10 print money.

Beyond Hellenistic

The Hellenistic stack is the most opinionated and the most differentiated right now, which is why I led with it. The same architecture extends sideways to whatever school your audience cares about.

Ship one row first

Pick the single technique with the most narrative punch for your audience. For a general consumer app, that is annual profections. For a career-oriented app, ZR Spirit. For Indian markets, Vimshottari Mahadasha. Ship that one row and the transit overlay. Charge $5/month. Validate that anyone wants this at all.

Then add Firdaria. Then add ZR L2. Then the biwheel. Each addition is a launch and a pricing-page change.