Overview
A new business started in collaboration with a perfume studio. The studio runs an offline blind-date model in which singles who share faith values meet during perfume-making sessions, and I took on developing the iOS and Android app that handles this model from application and screening through matching.
Problem
In the offline pilot, applications, screening, and matching were handled on paper by hand. Dating apps can’t verify faith, and 1:1 blind dates come with awkward silences and the pressure of rejection. On top of that, the app handles sensitive data such as religion along with contact details, so I had to prove safety and legality before building out features.
Approach
I finalized the BLUEPRINT (written with design thinking), the PRD, and the DB schema before any code, then built with Claude Code and finished 11 milestones (M0–M10) in 6 days. The core rules are operator review of profiles, 4:4 rotation, and revealing contact details only on a mutual choice; participants and operators use the same app with separate roles. During development, I found an information-leak flaw: “If only matched users get a notification, the notification itself gives away the match.” I changed the design so everyone’s result is decided at once at the deadline. After reviewing whether the app would count as a marriage brokerage business, I repositioned it as “offering a chance to date, not arranging marriages,” and locked 7 red lines into the PRD, such as never building individual recommendations or marriage management.
Results
Flutter (iOS, Android) + Supabase (RLS, Edge Functions, pg_cron) + FCM, about 17,800 lines of code and 33 screens. All 605 tests pass, 6 rounds of security audits (OWASP MASVS v2), pre-review defects down from 24 to 0, and 32/32 on-device QA checks passed. A Google Play closed test (13 testers) is underway, and for the App Store I prepared a build that addresses a rejection requesting more information. It hasn’t been officially released, so there are no user or revenue metrics yet.
Lessons Learned
After building every feature, I spent 3 weeks checking “Is what I built safe and legal?” Regulatory risk is managed when it is translated into the product’s red lines, not into legal documents. And fast implementation was only possible because the documents came first.