Member app
iOS · Android
Announcements, schedules, reservations, attendance, prayer requests, and QT and Bible reading for every member. Released to both stores from one Expo codebase.
TypeScript · React Native · Expo
Member app · iOS & Android
UP-Dream
A place for community, reflection, and the next small step.
A church youth-group service bringing attendance, announcements, schedules, room reservations, prayer requests, personal reflection, and Bible reading into one place. I released the member app on iOS and Android and built and run the shared backend used by the admin web and admin app.
Why I built it
Room bookings lived on a shared Naver calendar and communication in a KakaoTalk open chat, so information was scattered. UP-Dream brings announcements, schedules, reservations, attendance, and prayer requests into one service, with sign-up gated by roster verification and administrator approval.
Real use
Counted across 48 Sunday youth services, 1 December 2025 to 3 November 2026.
- 67.2%
- 41 of 61 regular attendees (24 or more of the 48 services) use the app
- 49.1%
- 56 of the 114 people who attended at least once have signed up
People are counted once each; pastors and test accounts are excluded. Sign-up means required details entered and terms accepted. Attendance comes from records saved in the app, and unrecorded weeks are not counted as absences.
One service, four surfaces
Management work is split by situation between the web and a native app, and every permission decision is made in one place: the server.
Admin web
Browser
Heavier desk work: sign-up approvals, member records, and account merges. Uses two-step verification.
TypeScript · React
Admin app
iPhone · iPad
Quick on-site work such as Sunday attendance. Face ID or Touch ID on entry, showing only the actions the server allows.
Swift · SwiftUI
Shared API
AWS ECS Fargate
Sessions, permissions, and business rules for all three clients in one place. Attendance changes are saved in transactions.
TypeScript · PostgreSQL · S3
I also run the service website, its terms, privacy and child-safety policies, the in-app account-deletion flow, and the copyright permission for the Bible text.
Service websitePublic demo
Try the demo
Explore the app’s main screens with a public demo account.
How to sign in
- Install the app from the App Store. The member app is also on Google Play.
- On the login screen, choose “데모 계정으로 로그인” (sign in with a demo account).
- Enter the login ID and password below.
Things to explore
- Browse gratitude and reflection entries by date
- Check announcements and schedules
Public demo account
You can also select and copy the text directly from either field.
This demo uses shared sample data. Other visitors may change it, and changes may remain. Please do not enter personal information or private prayer requests.
Inside the app
Development and review captures with synthetic demo data. Dates are shown below; later App Store builds may look different.
Screenshot provenance
How it fits together
Engineering details reflect source reviewed on September 17, 2026. App Store releases may contain an earlier subset.
- 01React Native member app · React admin web · SwiftUI admin app
- 02TypeScript API checking authentication and permissions
- 03PostgreSQL · private S3
The member app, admin web, and admin app share one backend. Database records and licensed Bible text have separate storage and access boundaries.
Decisions behind the interface
Recover a session without losing trust
Startup distinguishes temporary connection failures from invalid credentials. Refreshes can retain the last useful screen, while account or permission changes discard old data and invalidate delayed responses.
Make concurrent attendance edits explicit
Attendance writes use an expected version to detect conflicting edits. The server rechecks authority after acquiring a workflow lock, and commits the record, revision, and audit history together.
Refresh through the permission boundary
Realtime messages signal that something changed. Clients fetch the actual records again through the API so current permissions apply. Coalescing and short jitter windows limit redundant requests.
UP-Dream
How I used AI
How I work with AI
- I define the requirement myself, starting from beta feedback and operating needs.
- I set the scope: which screens may change and which logic must not be touched.
- I delegate implementation: scoped frontend work and integration with Claude Code and Codex.
- I verify against data and permission rules, with regression tests and CI.
- I record where the AI was wrong and fix it myself.
- I keep the hard calls: identity, permissions, concurrency, and release scope.
I used Claude Code and Codex for scoped frontend work and integration. In the general-member faith-garden update, Claude Code prepared the initial growth and mission-screen changes; Codex handled the home screen, shared theme, calendar and reading-flow refinements, and integration checks.
ImageGen supplied static garden and mission-letter illustrations. Text, buttons, record indicators, and interactions remain native React Native elements. The screenshots here show the earlier interface for young-adult members. I define the product requirements and release scope.
When the AI was wrong: account merging in the admin web
- 01Situation
- The same member had signed in with two different OAuth providers (for example Kakao and Apple), leaving two accounts. Their roster record already held attendance history, and the admin web had to merge the accounts without losing it.
- 02What I delegated
- The account-merge feature in the admin web was implemented with an AI coding tool.
- 03What failed
- Finding likely duplicate accounts worked. Running the merge did not: the accounts stayed separate, and attendance remained attached to the wrong account.
- 04Cause
- The AI-generated merge treated the OAuth account as the unit and moved data from one account to another. Attendance, however, belongs to the roster record, not the login account. Because the merge ignored where the data was actually attached, account fields moved while attendance stayed behind.
- 05Fix: change the axis
- I rebuilt the merge around the roster record as the single identity for a person. Each OAuth account is merged in as a login method attached to that record. Attendance was already attached to the roster record, so it never has to move or be rewritten.
- 06What changed in how I work
- Account and permission code is hard to undo when it goes wrong, so I no longer accept AI output there as-is; I edit and review it myself. AI handles clearly scoped screen work, and decisions about identity and permissions stay with me.
Bible text: permission and delivery
I handled the copyright review and the work to secure permission for the Korean 개역개정 translation used in UP-Dream. The project checklist records permission confirmation. Copyright remains with the Korean Bible Society, and the supporting documents are retained privately.
The reader provides all 66 books to approved members. The full text stays outside the app bundle and public repository, is delivered from private AWS S3 through an authenticated API, and is checked for integrity. The app displays copyright notices and uses an account-specific temporary cache that is cleared on logout and account changes.
Technical overviewCode and verification
The technical overview documents source boundaries, design trade-offs, and dated test results, including session recovery, cache isolation, concurrent writes, and a fix for a crash during Android’s first layout.