Lich An — Phi Dang

About

Lich An is a Vietnamese lunar calendar computed entirely on the device: no network, no ads, no data collection.

Outcome

I ran the whole lifecycle alone: market research, the lunar engine, five screens, the brand assets, then shipping to both Google Play and the App Store with a RevenueCat-based support system. The engine is guarded by its own correctness harness — 73/73 assertions passing, covering Tết anchors from 2000 to 2026, leap months, and a lunar → solar → lunar round-trip across 2000–2030.

Lich An — Today screen with the calendar sheet and auspicious hours

Lich An — lunar-date events for ancestor rites

Problem

Vietnamese households check the lunar calendar daily — full moon and new moon days, death anniversaries, auspicious dates for a wedding or for breaking ground. The incumbents have tens of millions of installs but trade the experience for ad revenue: banners over the calendar, full-screen interstitials, and a permission list nobody can justify for what is, after all, a calendar.

The gap was never a missing lunar calendar app — it was a clean one.

Research

Before writing any code I scanned three origination angles against real market data (SensorTower, RevenueCat's subscription report) to find something one person could actually win:

Global niches (alarms, app blockers) lean on heavy native APIs and pit you against funded studios — the wrong fight for a solo dev.
Vietnam is the lowest-ARPU region in the area: you win on near-zero home-market acquisition cost and a cheap lifetime unlock, not on subscription pricing.
The ritual layer (rằm, mùng 1, ancestor rites, date picking) is culture-specific — foreign apps can localize strings, not customs.

The conclusion: a lunar calendar is fully computable — no content pipeline, no special entitlements — which puts it at the best intersection of shipping speed and home-market advantage.

Product System

At the core is a pure lunar engine: deterministic functions with no reliance on the device timezone — the +7 offset is passed in explicitly. Everything on screen is computed, never fetched.

Solar ↔ lunar conversion including leap months, can chi for day/month/year/hour, the 24 solar terms, auspicious hours and auspicious/inauspicious days.
Five screens: Today (calendar sheet, the hour running now, what to do and avoid), Month, Day detail, Lunar events, More.
Lunar-date events for ancestor rites, with the next occurrence computed and reminded through local notifications — the same mechanism behind the full-moon and new-moon reminders.
Share the day as an image to Zalo or Messenger, rendered on the device.
Voluntary support through RevenueCat, initialized lazily — it only runs when the user taps support, so nothing leaves the device before that.

The "no data collected" promise is enforced at build level: a prebuild plugin strips the storage permissions that libraries drag in, and each release APK is re-checked with aapt2 dump permissions.

Role

Market research and data-driven concept selection
Design and verification of the lunar engine (TypeScript, custom test harness)
UI/UX and brand assets (icon, splash, feature graphic)
Full React Native / Expo development across both platforms
Release work: AAB signing, Play Console, App Store Connect, IAP, Vietnamese ASO

Learnings

The hard part was not the code

The lunar logic landed early and stayed stable. The time went into release infrastructure: closed testing programs, data-safety declarations, in-app purchase products, tax and contract forms — the kind of thing you only learn by going through it once.

Privacy is an architecture decision

"No data collected" is only true if the code makes it true. Moving the payment SDK's initialization to the moment the user taps support was a small code change and a large difference in what the promise means.

Green tests do not replace human eyes

One build passed typecheck and the full lunar suite while still rendering an empty heading on the share image. Since then, an on-device pass comes before every release.