08·Product·Passion project
House Call
Invitation-only natal-reading practice. Hand-prepared readings synthesise Western, Chinese BaZi, and Vedic Jyotish, backed by per-user accounts, daily astronomy-engine transits, a falsifiable prediction tracker, synastry, and tarot import.
ResultLive at housecallastro.com as an invitation-only private beta, payments off.
Discover
Why it exists.
Most natal-chart software treats traditions as separate islands, pick Western or Vedic or BaZi, get a reading inside that island, never cross. Practitioners who synthesise across traditions in their actual practice have nowhere to host that synthesis as a product.
House Call is that host. Hand-prepared readings that braid Western (Vronsky lineage), Chinese BaZi, and Vedic Jyotish into one document, with the supporting infrastructure underneath: per-user accounts, daily transit forecasts computed against the user's chart, a falsifiable prediction tracker that closes the loop on whether the reading held up, synastry, and tarot import.
Invitation-only on purpose. The practice scales by depth, not by sign-up volume.
StackNext.js · Prisma · Turso · JWT · astronomy-engine · Vercel
Define
The brief.
Host a three-tradition natal-reading practice that scales by depth, not sign-up volume, with intimacy and per-user privacy as preconditions.
Develop
What it took
Skills behind it.
Primary discipline plus the support stack.
Skills demonstrated
- Product StrategyPrimary
Synthesised three-tradition reading practice with falsifiable prediction tracking; invite-only by design.
- Frontend EngineeringSecondary
Next.js app with per-user auth, daily transit forecasts, synastry, and tarot import surfaces.
- Backend EngineeringSecondary
Turso libSQL on Prisma, jose-signed JWTs, astronomy-engine transit cron, Vercel-fronted deployment.
- Web DesignSecondary
Midnight + gold editorial identity with a gold orbital glyph that anchors the landing.
Develop · Build
How it came together.
- 01
Three traditions, one synthesis layer
Each tradition has its own ontology, houses, palaces, pillars, and a Western synthesis on top of all three is the wrong move (it flattens what makes each tradition useful). Built a synthesis layer that holds the readings in parallel, lets the reader weave between them in prose, and never collapses them into a single chart. The user reads three voices, not one diluted voice.
Product Strategy - 02
Daily transits as a separate cron
Transit forecasts run against the user's natal chart every twenty-four hours using
Backend Engineeringastronomy-engine, not at request time, because the calculation is expensive and the result is identical for every viewer of that user's day. Caching by user-day collapses the per-request cost to a database lookup and lets the forecast feed surface instantly when the user opens the app. - 03
Falsifiable predictions, logged
Predictions in the reading get tagged with a time window and an outcome category. When the window passes, the user marks the prediction hit, missed, or partial. The tracker holds the prediction reader accountable to their own forecasts, which is both the trust mechanic and the dataset that improves the next reading.
Product Strategy - 04
Per-user auth + Turso libSQL
Per-user auth was a non-negotiable from the start, readings are intimate, and you cannot share them on a shared session. Built on Next.js with jose-signed JWTs against Turso libSQL via Prisma; the database edge-replicates so transit calculations near the user stay fast. House Call's own migrations run through a custom script because the Prisma CLI does not speak Turso.
Backend Engineering - 05
Midnight + gold identity
House Call's visual language is a midnight ground with a single gold orbital glyph, readable as a logo, expandable into the chart aesthetic, distinct from the cobalt-blue planetary palette every other astrology product uses. The brand identity is the practice identity; the site looks like the readings feel.
Web Design
Develop · Forks
Decisions on the record.
The few calls worth defending. Each one is a fork; the other branch would have been a different project.
Decision · 01
Why vault-on-disk for reading content, not a CMS
Reading markdown lives in an Obsidian vault. The Obsidian app is the only editor; the web app reads. Putting the content in a CMS would have meant maintaining a second editor surface and risking a writeback path that overwrites the practitioner's notes. Plain files on disk + an Obsidian editing flow keeps the artisanal side honest.
Decision · 02
Why per-user access control from day one
Natal readings are intimate; the per-user gate isn't a feature to add later, it's a precondition. Each
natal_userreads only their own reading viagetAccessibleSlugs(user). Building this in from the first commit is cheaper than retrofitting it after a leak, and it sets the trust contract with the founders' cohort up front.Decision · 03
Why AI drafts, the practitioner ships
Every reading is AI-drafted from a curated corpus and human-reviewed before it reaches the user. The DB schema reflects this: questions queue, the practitioner answers, then the user sees the answer. A pure-AI pipeline would have been faster to scale; it wouldn't have been a practice. The constraint is the product.
Deliver
What shipped.
LiveLive at housecallastro.com as an invitation-only private beta, payments off. The public launch and pricing follow once the founders' cohort closes.
Live in private beta since 2026-05, by invitation. Per-user accounts, daily transit feeds, a prediction tracker, synastry, and tarot import all in production. The invitation list grows by referral; the domain (housecallastro.com) is live but invitation-only, with no public sign-up or open launch yet, by design.