Liminal Tarot
A practice, not a prediction.
A private tarot journal for the question that keeps circling back. Daily cards, focused readings, written reflections, and Chapters that hold a period of life together.
The cards do not decide. They give attention a shape.
A reading can stand alone. Liminal Tarot is built for what follows: the reading is saved, notes can attach at the card, reading, and Chapter level, and related readings can gather into a named period of life. Over time, recurring questions and patterns become easier to see.
Built and shipped by Zyane with AI assistance, from the web product to a distributed iPhone app. The product site explains the practice. This casefile shows the shipped surfaces, the public shape of the system, and the decisions behind them.
The decisions are the evidence.
Features show what exists. Decisions show what the product was willing to protect, what it gave up, and which direction had to change.
The installed app stopped depending on the live website
The first native build pointed at the live website. It worked, but it was not ideal: a web deploy could change what was already on someone's phone, while billing, navigation, offline behaviour, and package identity crossed boundaries that should have stayed separate.
The rebuilt app bundles its own assets and calls remote APIs for data. More work to ship. A clearer product boundary.
Free history stopped expiring
Free readings used to disappear from history after seven days. That is a familiar growth lever, but here it missed the product's strongest opportunity: continuity. Someone who wrote something worth keeping should not lose the record because a timer ran out.
Free access is now limited through reading creation and Pro practice surfaces, not by removing what the user already wrote.
Final state follows persistence
A daily card is not shown as finally settled until persistence succeeds. Faster optimistic feedback can look better in a demo. That trade does not fit a product whose promise is that the record will still be there later.
The interface may begin the motion. It waits for the stored result before presenting the final state. The same rule applies anywhere a failed save would make the archive look more reliable than it is.
The product does not predict
Liminal Tarot is a reflective practice, not fortune telling. The cards reflect the question and the spread in front of the user; they do not claim to know what happens next.
The product states its limits, routes crisis language to resources instead of a reading, and does not present itself as medical, legal, financial, or mental-health advice. The same boundary serves product positioning, trust, and compliance.
The product is the thread
A single generated reading can be useful and still end as a one-off. Chapters group related readings around a named period of life, carry the user's notes and history forward, and support synthesis across the thread.
That decision shaped the product's value around continuity rather than claiming a smarter model. It also made persistence, history, and notes part of the core product instead of secondary storage around the reading.
Illustrative Chapter example using fictional readings and synthesis.
The shape, not the internals.
Enough of the system to make the public claims legible. Implementation detail stays with the product repository.
Not claimed: downloads, ratings, revenue, retention, conversion, or market impact. Nothing on this page should be read as traction evidence.
Not disclosed: prompts, database policy, provider configuration, private operational records, or the product repository. The public shape is enough to explain the work.
Not shipped: an iPad-specific layout or a Google Play release. Both remain planned until the release record says otherwise.
What's shipped, newest first.
Appended from source as the product evolves. This is a release record, not a log of every change — and planned items stay marked planned until they ship.