Mobile app for Vietnamese rituals · 2026
I designed a prayer app and shipped it without writing a line of code
Reading a prayer from a phone means stopping mid-ritual to scroll. I designed Thầy Cúng in Figma and built it with Claude Code, acting as founder to an AI product team: a hands-free teleprompter, verified prayer texts and lunar-date reminders, live on Google Play for five months.
- Product strategy
- 0→1
- UX
- UI
- AI-assisted build
- Role
- Solo: product, design, AI-directed build
- Team
- Me + Claude Code
- Timeline
- ~1 month, idea to release · 2026
- Platform
- Android (live) · iOS runs in Expo Go, not released
- Outcome
- Live on Google Play · 17 installs
TL;DR
Summary
A prayer app built around one moment: standing at the altar, phone in hand, reading without touching the screen. I scoped, designed and shipped it in a month, without coding experience, by running Claude Code like a product team. One real ritual changed more than my research did: the default reading speed went up 20%.
- Idea to Google Play
- ~1 month
- Phase 1 core, then reminders as Phase 2
- Lines of code I wrote by hand
- 0
- All code via prompts and skills in Claude Code (VS Code)
- Prayers and offering guides
- 30 + 20
- Prayers from one published book; no AI or user-generated text
- Default reading speed
- +20%
- Changed after two real rituals at home; whole speed range shifted
The prayer is on your phone, and you have to stop praying to scroll it
Before every family death anniversary, I searched for the prayer text and what to prepare. Results were messy, contradictory or buried in ads. Then, mid-prayer, I had to stop and scroll to keep reading.
I asked five friends aged 25–35 whether this was just me. It wasn't, and they had more problems than I did: they forgot the dates, worried about doing rituals wrong, and missed things when buying offerings.
People don't lack information. They lack a source they trust and a reminder that speaks lunar
Five conversations with friends, plus my own rituals, not a formal study. Small sample, so I treated it as direction and checked every decision later in real rituals.
I don't dare follow random websites. For anything ritual-related, I ask my grandparents.
01
Trust beats volume
Spiritual content is everywhere online, but nobody was sure it was right. The fear is doing the ritual wrong, not missing information.
02
Reading is part of the ritual
The prayer is read during a sacred act. Any tap or scroll breaks it.
03
Nothing reminds them in lunar time
They forget the 1st and 15th, death anniversaries, and items for the offering tray. Phone calendars don't count in lunar dates.
What made the cut, and what I left out on purpose
As my own PO, the hardest job was saying no. The test was simple: does it serve the moment at the altar, and can I ship and maintain it alone, for free?
01Shipped · Phase 1
Hands-free teleprompter
02Shipped · Phase 1
Lunar & solar calendar with the year's ritual days
03Shipped · Phase 1
Offering guides & checklists, linked to each occasion's prayer
04Shipped · Phase 2
Personal events with lunar or solar reminders
05Not pursued
Accounts & cloud backup
06Not pursued
AI-generated prayers
07Not pursued
User-submitted content
08Runs in Expo Go · not released
iOS release
Three calls that define the app
01
A teleprompter you can steer without stopping
- Insight
- Readers don't keep one pace. They slow down at names, speed up at familiar lines, glance back.
- Decision
- The prayer scrolls on its own, full screen. Speed and text size change while it runs; a swipe re-reads or skips ahead without changing the overall speed. The screen stays on, and locking the phone keeps the position.
- Trade-off
- The hardest thing in the app to build, and I couldn't read the code. I tested it as a user and described what I saw and felt until it ran smoothly on both platforms. A simple modal reader would have shipped in days.
(Speed, text size and pause, all while it scrolls) 02
One published source. No AI, no user content
- Insight
- The fear was doing the ritual wrong, so every word had to be defensible.
- Decision
- Prayers come from Văn khấn cổ truyền Việt Nam (Hồng Đức Publishing). Offering guides follow long-established ritual-tray businesses. I rejected AI-generated prayers and user submissions.
- Trade-off
- 30 prayers, not 300, and content grows only as fast as I can check it. AI is wrong in confident ways, and moderating user content in a spiritual app would cost more than one person can give, and break the respect the app depends on.
(Prayers filed by occasion, the way people look for them) 
(Each offering guide is a checklist that keeps progress) 03
No account: your data stays on your phone
- Insight
- People open the app to pray, not to sign up, and their family dates are personal.
- Decision
- No login. Favourites, events and reminders live on the device; Supabase serves only public content.
- Trade-off
- Change or lose the phone, and personal data is gone. I accepted that: no sensitive data to protect, no consent flows or store-policy overhead, and no security I couldn't verify myself. That keeps the app free.
(Pick solar or lunar once; the reminder repeats on the right day every year)
I ran Claude Code like a product team and played founder
Claude Code was my BA, PO, developer and QA. I owned the product, the design, and what “done” meant. It was strong at executing a plan, choosing a stack and fixing bugs. It was weak at the details users feel.
I couldn't read a stack trace, so I debugged as a user: reproduce, describe what I saw, check the fix. Console logs, server logs and database logs were all new to me; I learned them alongside the AI.
Stack: React Native · TypeScript · NativeWind · Supabase · TanStack Query · Zustand.
- Design the key screens in Figma
- Write product docs so the AI understands the app
- Choose the stack, set up the database and dependencies
- Connect Figma to Claude through an open-source, plugin-based MCP server
- Build Phase 1: teleprompter, calendar, prayers, offering guides
- Test, then build Phase 2: lunar and solar reminders
Three days fixing AI-drafted UI taught me to draw first
I first had Claude code the UI straight from my text wireframes, then tried to prompt it into shape. It got the structure right and the craft wrong. Bottom sheets, text inputs and line breaks rendered differently on Android and iOS, and each fix misunderstood the last.
After three days I threw that UI away, designed every screen by hand in Figma, and rebuilt in order: UI foundation, key components, then screens. Figma's own MCP needs a paid plan, so I found an open-source MCP server that runs through a Figma plugin and lets Claude read my designs directly. Slower to start, faster to finish, and it looked like I meant it to.
My wife's rituals beat my best guess at reading speed
I set the speed range from my own reading pace, then had friends aged 25–35 try it. The real test was my wife using it at the 1st and 15th of the lunar month.
After two rituals, the default was too slow: I raised it 20%, shifting the whole range from slow to very fast. She also preferred a different typeface, so I added a serif/sans-serif choice.
The app passed Google Play's closed test with 11+ testers and has been live for five months, with 17 installs, mostly family and friends. None of them has reported a bug.
That's a small, Android-only group, and the app has no analytics or crash reporting, so it proves the app works, not that it's wanted. iOS runs in Expo Go but hasn't been tested on a real device.
What I'd carry forward
01
Design first, then let AI build
AI executes a clear spec well and invents a poor one. Next time I'd start with the foundation in Figma on day one.
02
Test in the real moment, early
My pace and my friends' feedback put the default 20% too slow. One evening at the altar fixed it; I'd do that before polishing anything.
03
Measure from day one
“No bugs reported” from 17 installs says little. I'd add crash reporting and track lunar-cycle return and teleprompter completion before launch, not after.
Next case
- Designing a diet app that does the calorie math for people with no time
- —