CARDY

THE PROBLEM

My cousin loves cardology, a system that maps every date of the year to one of the 52 playing cards, and I worked with her to turn it into an app. The challenge: a reading that sounds like a bare claim is easy to dismiss.

SHOWING THE WORKING

So Cardy shows the maths. It displays the date, the cycle and the card that results, so every reading comes with its working. Onboarding does the same: instead of a feature tour, you enter your birthday, watch the cycle run, and see how you got your card.

HOW IT'S BUILT

SwiftUI on the front end, Supabase for accounts, content and sync. The cardology itself is plain arithmetic, not a model: a date maps to a card through a fixed cycle, and keeping it that way matters, because the app's whole appeal is that you can check it. A model is only used where the output is writing: the check-in reading and the onboarding questions.

PROMPTS IN THE DATABASE

Prompts live in the database, not in the app. Each type has a versioned history with one active version; the edge function loads it and fills in the details at call time, and each reading stores the version that produced it. So I can change the wording without shipping a build, and trace any reading back to exactly what produced it. Sonnet 4.6 writes the check-in reading, and the onboarding questions go to Haiku 4.5, which retries twice on a bad response, because that job is simple and structured and doesn't need the bigger model.

EVERYTHING AROUND THE APP

The iOS app is one of six things I built for Cardy. The others are a web app, the marketing site, an admin site, automated social media creation and posting, and a teleprompter app connected to the same system for filming. Building all six on my own is only possible because of AI tools, and it's the part of this project I learned the most from.

THE APP CLIP

Cardy has an App Clip, because the best demo of the app takes about ten seconds: a birthday goes in, the cycle runs, a card comes out, and none of that needs an install. The Clip does exactly that, so a link from a friend or a code at an event gives someone their reading right away, and only offers the full app once it has worked.

GETTING THROUGH APP REVIEW

Apple treats divination apps as spam by default, so Cardy was blocked because of its category, not its quality. Over six months I redesigned it, wrote appeals, changed how the app described itself, and eventually got on a video call with App Review. It shipped.

THE APP STORE LISTING

The same category problem shapes the listing. Anything that reads like fortune-telling is a risk with App Review and a weak pitch to buyers, so the listing leads with the system and its arithmetic (a date, a cycle, a card) rather than predictions. The honest description and the one that passes review turned out to be the same. I also run the builds and TestFlight, phased releases, subscription products and pricing, and review replies.

THE RESULT

30% of downloads convert to paid, several times the usual rate for a subscription app: 125 paying customers in the first two months.

GROWTH

Social media posts are created and published automatically to keep Cardy in front of new people, and I've started reaching out to content creators. A 30% conversion rate is high enough that paying for installs can make sense, so Apple Search Ads bids on the words people already use for this system (cardology, birth card, destiny card), where intent is high and there's little competition, rather than broad astrology terms.