Life-Up — a habit app

Summary

What

A habit app that turns small daily actions into quests. Log a habit, earn coins, and spend them raising your buddy.

Our role

Planning, design, app, web portal, backend, payments, store release and operation — all in-house

Stack

React Native (Expo) · React · Spring Boot · RevenueCat · Paddle · Kubernetes

Life-Up gives people a reason to keep going instead of relying on willpower. Logging tasks and habits earns coins, and the coins raise a buddy. Alongside that sit a weekly magazine, reminders at the times you choose, and an ad-free subscription. It looks like a small app, but five features with very different rhythms are tangled together, and the structure we chose at the start decided what every later change would cost.

Decision 01

Six services, split by how often things change

Problem

Habits, the buddy game, the magazine, reminders and subscriptions change at different speeds. The magazine gets new articles every week and its features are tweaked often; payments rarely change, but a mistake there is a money problem. With everything in one server, fixing one magazine screen means redeploying the payment code too.

What we did

We split auth, habits, game, magazine, reminders and subscriptions into separate services behind a single gateway. The app and web portal only know the gateway's address, not how things are divided behind it. Each service deploys on its own.

Why

Only what changed gets redeployed, so the payment service stays untouched on magazine days, and a problem in one service doesn't take the others down. The trade-off is more services to run, so we don't recommend this split to every client from day one — we decide based on how many features there are and how fast they change.

Decision 02

In-app and web subscriptions, counted as one

Problem

Selling a subscription inside an app means using Apple's and Google's in-app purchase. Life-Up also sells subscriptions on its web portal. If the two don't talk to each other, someone who paid on the web opens the app and is treated as a free user — ads included.

What we did

The app uses RevenueCat for App Store and Google Play billing; the web uses Paddle. Our backend receives purchase events from both and merges them into one entitlement per account, taking the higher tier if there are two. Purchase events are only accepted with a shared secret — otherwise anyone who found the address could announce that a user had paid.

Why

Wherever someone pays, they should get the same thing. And when the app can't confirm a user's tier, it shows no ads: showing an ad to a paying subscriber is far worse than skipping one for a free user.

Decision 03

One codebase, three languages, from the start

Problem

Build iOS and Android separately and every fix happens twice, and the two apps drift apart over time. Languages work the same way: write screen text straight into the code, and adding a translation later means reopening every screen.

What we did

We built both apps from one React Native (Expo) codebase and moved all screen text into language files from the very first screen, shipping Korean, English and Japanese together. Store listings, release notes and magazine articles go out in all three.

Why

Both decisions effectively mean a rebuild if you change them later. Made up front, they let you decide when to launch abroad without rebuilding the app.

Results

• AppiOS & Android, one codebase (React Native, Expo), KO/EN/JA
• Web portalsubscriptions and account management
• Backendsix services (auth, habits, game, magazine, reminders, subscriptions) plus a gateway, each deployed automatically on Kubernetes
• Sign-inGoogle and Apple, plus a guest mode with no sign-up
• Paymentsin-app subscriptions (RevenueCat) and web subscriptions (Paddle), merged into one entitlement
• Reminders & magazinereminders at times you choose, and a weekly magazine in three languages
• ReleaseApp Store and Google Play. Apple rejected us over sign-in options (4.8), account deletion (5.1.1), missing terms links on the subscription screen (3.1.2) and a price shown in a promotional image (2.3.2); we fixed each and passed.

For your project

If your app has subscriptions or payments

You get the experience of running both in-app and web payments. We decide during planning where to sell, how to merge subscriptions bought in different places, and how to verify payment events.

Before submission we check what Apple looks at in paid apps — terms links on the subscription screen, a restore purchases button, promotional images — and if the app is rejected, we fix and resubmit at no extra cost.

How many services your backend needs depends on the app. Smaller apps usually cost less to run on a single server.