eduardweb.
Prezentări & ShowcaseIntermediar#react-native#expo#supabase#showcase#mobile-dev

Am lansat un habit tracker în Expo cu 200 useri în prima lună: stack, greșeli și costuri

De Răzvan Matei, 24 aug. 2026 · 25 vizualizări · 2 like-uri

Postat 24 aug. 2026

Am vrut să văd cât de repede pot scoate o aplicație mobilă completă pe cont propriu, fără să-mi prind urechile în Xcode sau Android Studio. Am lansat un habit tracker minimalist, iar în prima lună am strâns în jur de 210 utilizatori activi. Nu sunt cifre de unicorn, dar sunt destui oameni cât să scoată la iveală toate presupunerile greșite pe care le-am făcut în faza de dev.

Stack-ul pe care am mers

Am vrut simplitate și viteză de iterație, așa că am ales un stack destul de standard pentru 2024:

  • Expo (React Native) cu Expo Router — fișierele de rutare seamănă mult cu Next.js App Router, ceea ce mi-a redus mult context switching-ul.
  • Supabase pentru Auth, Postgres și Edge Functions. Free tier-ul e mai mult decât generos pentru faza asta.
  • Zustand + TanStack Query pentru state management și cache de date.
  • RevenueCat pentru in-app purchases (am băgat un paywall opțional pentru analytics avansate).

Trade-off-ul principal? Expo managed workflow merge incredibil de bine până când ai nevoie de module native custom. Din fericire, cu Config Plugins aproape că nu mai ai motive să dai prebuild manual decât în cazuri foarte exotice.

Ce a funcționat și ce am bușit

Partea bună a fost viteza. De la prima linie de cod până în TestFlight și Google Play Internal Testing au trecut fix 3 săptămâni, lucrând cam 10-12 ore pe săptămână după job.

Partea proastă? Am ignorat complet scenariul de offline.

Am crezut că TanStack Query cu persistQueryClient o să fie suficient. Greșeală mare. Utilizatorii vor să-și bifeze obiceiurile când n-au semnal — în metrou la Unirii, la sală la subsol sau în avion. Când aplicația încerca să trimită mutația pe Supabase fără net, UI-ul se bloca sau afișa stări inconsistente după reconectare. A trebuit să rescriu logica de scriere într-o bază de date locală (SQLite via Expo SQLite) și să sincronizez în fundal când revine conexiunea. Dacă aș fi proiectat asta de la început ca local-first, economiseam lejer vreo 20 de ore de refactoring.

A doua problemă a fost cu fusul orar și notificările zilnice de tip push. Dacă utilizatorul își setează reminder la 08:00 dimineața și pleacă în alt timezone, sau dacă trimiți push-ul de pe server fără să calculezi offset-ul local al device-ului, o să trezești oamenii la 3 noaptea. Am rezolvat programând notificările local pe device prin expo-notifications, nu prin trigger-e de pe backend.

Costuri reale și concluzii

Costurile fixe până acum au fost minime:

  • Apple Developer Account: 99$/an
  • Google Play Console: 25$ (one-time fee)
  • Supabase, Vercel, RevenueCat: 0$ (toate pe free tier pentru volumul actual)

Cel mai mare drop-off l-am văzut în onboarding: 38% dintre utilizatorii care au descărcat aplicația au renunțat când le-am cerut să își configureze primele 3 obiceiuri din prima sesiune. Imediat ce am redus onboarding-ul la un singur ecran și un singur habit obligatoriu, rata de activare a crescut semnificativ.

Voi cum gestionați sincronizarea offline-first în React Native? Ați mers pe SQLite manual, WatermelonDB sau soluții gen PowerSync?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.