Settlify
Cross-platform expense splitting app — iOS, Android, web, and backend from zero to production.
The Brief
Splitting costs in a group sounds simple. In practice: people pay across currencies, some participants are included in some expenses and not others, and not everyone wants to download yet another app. Settlify needed to handle that complexity cleanly — across platforms, without forcing installation or sign-up on every participant.
Scope
What we delivered:
iOS app in App Store
Android app in Google Play
Web app - accessible without installation or account creation
REST API backend
SEO-optimised marketing and landing pages
From inception to both store approvals: 45 days.
Stack
| Layer | Technology |
|---|---|
| Mobile (iOS + Android) | Flutter |
| Web app | Flutter web |
| Marketing site | Next.js |
| Backend API | Python + FastAPI |
| Database + auth | Supabase (Postgres) |
| Infrastructure | Railway |
Key Technical Decisions
Flutter across mobile and web
A single Flutter codebase targets three deployment environments: iOS, Android, and browser. Flutter web has real limitations compared to a native web framework — that trade-off was worth accepting at this stage to avoid maintaining two separate frontend codebases while the product was iterating fast.
Next.js for the marketing site
The marketing and landing pages are deliberately separate from the app layer. Next.js was chosen for server-side rendering and static generation — the right tool for SEO-critical pages where Flutter web would have been the wrong call.
SQL + JSONB hybrid
Some parts of the schema were stable from day one. Others were actively evolving. Rather than forcing early decisions into rigid relational structure, expense metadata and split configurations use JSONB where flexibility was needed, with structured SQL tables for the stable core: groups, participants, settlements. A practical trade-off for an early-stage product that avoids costly migrations while the data model is still being discovered.
Stateless group participation
Group members can add expenses and view balances without creating an account. That required deliberate session and state design — URL-based group access, ephemeral participation tokens — rather than defaulting to authentication everywhere. It meaningfully reduces friction at the most common point in the user journey.
Testing for rapid iteration
The project includes automated test coverage across three levels: unit, integration, and end-to-end. Maintaining a test suite on a project of this scope and timeline was a deliberate decision to keep the codebase safe to iterate on as features are added post-launch.
The web app is live at settlify.app
Building something similar? Get in touch