Independent product · Full stack · Public beta
Designed, built and operated by me · March 2026 to now · splittez.com
An expense app for personal spending, recurring costs and shared bills. I took it from an empty repository to a public beta on the web, iPhone and Android: the data model, the API, the app, the tests, the phone builds and the server it runs on.
I made the launch film from the app’s own screens, recorded with fictional demo people, so what you see is the product as it runs. It walks through the four things SplittEZ is for.
The film has no narration. Each scene pairs a short headline with a recording of the matching screen in the light Ivory or dark Obsidian theme, and it ends on the beta invitation at splittez.com.
Your bank shows what money moved. It cannot tell you what that money meant. If you pay S$120 for a dinner shared by three people, the bank records S$120 leaving your account, but you only spent S$40. The other S$80 is money you are owed.
Most expense apps pick one side: personal budgeting or bill splitting. People who share flats, eat out in groups and travel together live in both, so their numbers never agree. SplittEZ keeps one ledger that records what moved, what part was yours, who owes whom and how it was settled.
The first market is Singapore (S$, PayNow and PayLah instructions) with India second (INR and UPI). The target user is someone aged roughly 22 to 40 who shares costs often. People who want automatic bank feeds or investment tracking are explicitly not the audience.
SplittEZ never moves money. Payment details such as PayNow, PayLah and UPI are shown as instructions to copy.
One React codebase serves every platform. A Node API owns all business rules and talks to Postgres; the clients never touch the database. Services that hold secrets or money logic sit behind the API.
Clients
HTTPS with bearer-token sessions
API
Server-side only
Data and services
Hosting started on Vercel, Render and Neon. It now runs as a self-hosted Docker Compose stack (API, web server, Postgres) published through Cloudflare, which gave me control over cost, backups and data location.
Migration
The first version ran on Supabase. When I moved to my own API, I wrote a Supabase-shaped client adapter so the existing React screens kept working, and imported users with their existing password hashes so nobody had to reset. Trade-off: the generic query endpoint behind the adapter needed table and column allow-lists, and later a block on re-pointing rows to another owner.
Data model
Home, budgets, categories and insights all call one function for personal spend. Totals are always derived from expense rows, never stored, so an edit or delete cannot leave a stale balance behind. Trade-off: more computation per screen in exchange for numbers that always agree.
Correctness
Splits are allocated in cents and the payer absorbs leftover cents, so shares always add up to the bill exactly. This is tested across SGD, INR and MYR, S$0.05 bills and groups of 7, 9 and 13.
Concurrency
Invite codes are stored hashed and consumed with SELECT … FOR UPDATE inside the account-creation transaction. The daily sign-up cap uses a Postgres advisory lock, so two people cannot take the last place at once.
Offline
Phones queue writes offline with device-generated IDs and replay them in order. Money edits carry the amount they expected, so a stale replay is refused, and a conflict on shared money is shown to the user rather than merged silently.
Privacy
Usage events record an HMAC of the user ID instead of the ID, keep the day but not the time, hide any group smaller than five and can be switched off by the user.
47 test scripts run in plain Node against a temporary Postgres. The ledger suite pins down the rules that matter most: a payer of S$120 for three spends S$40 and is owed S$80; repayments move what you are owed but never count as spending or income; unclaimed money in an open claim belongs to nobody; work expenses never reach personal totals.
An OWASP Top 10 review led to a script that replays real attack requests against a throwaway copy of the API. Before the fixes, 16 of 32 got through. After them, all 32 were blocked.
For what automation cannot judge, I built a small QA cockpit: a local web tool that walks through about 50 manual scenarios (guests, money, offline, install, native) with seeded data and records results per branch.
How I worked
I built SplittEZ with Claude Code as a pair programmer. The product decisions, data model and release calls were mine, and every change went through the tests and QA scenarios above before shipping.
Home showed S$22.03 owed by one person while Friends showed S$0, because only Home counted guests. I replaced the separate calculations with one balance function that every screen reads.
Recording a part payment shrank the share itself, so history no longer added up. I switched the feature off for the beta, made the server refuse part amounts, and wrote up a proper data model before building it again.
On-device Tesseract misread totals. I first turned low-confidence reads into suggestions with per-field undo, then switched reading off entirely, so photos attach without filling in any amounts.
App Store review rules, the iOS UIScene lifecycle change and update prompts for testers each needed native work. iPhone is on build 12 and Android on build 10, and both now prompt testers when a newer build is out.
There is no paid tier yet. The beta is there to learn whether the ledger model holds up in everyday use.
