Can Splitwise be vibe coded?

Build brief — a focused alternative to Splitwise

Verdict: Partly, if you narrow it · Buildability: 49/100 · Category: Personal Finance

Source: https://www.canitbevibecoded.com/splitwise

Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Splitwise. Verify current pricing and capabilities before acting.

Context

Splitwise — Group expense tracker that splits bills and nags everyone until debts are settled. It currently costs $5/mo.

The ledger and the debt math are a solved problem; a link-shared DIY version covers a household or one trip in a focused implementation, no accounts needed. The gap is not code, it is adoption: Splitwise works because the whole group already has it installed, and nobody downloads your homebrew app for one weekend away. Build it for the people who share your fridge; for everyone else, the moat is other people's phones.

This brief describes a focused, single-operator replacement for the part of Splitwise that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

What you are building

Create link-shared groups, log expenses with flexible splits, and settle up via minimum cash flow debt simplification.

Import transactions, categorize spending, and forecast cash flow privately.

A responsive interface with real empty, loading, success, and error states.

Requirements

Non-functional

Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.

Security: server-side secrets, validated input, and no credentials in the client bundle.

Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.

Portability: the operator can export their data and leave without losing it.

Implementation brief

Build a self-hosted group expense splitter: a single web app, no user accounts.

Stack: Node 22, Express, better-sqlite3, server-rendered EJS, htmx for interactivity. No build step, no SPA framework.

Features:

Groups are created with one click and live at an unguessable URL (nanoid, 21 chars). The link is the auth model; say so plainly in the README.

Members are names typed into the group, nothing more.

Expenses: payer, amount, currency, date, note, category, and a split that can be equal, exact amounts, percentages, or shares.

A balances view per group: each member's net position, plus a settle-up plan computed with minimum cash flow debt simplification.

Reimbursements logged as a special expense type.

Multi-currency: amounts stored in their own currency; a per-group manual rate table converts to the group's base currency. No external rate API.

Edit and delete with a simple activity log.

Export any group as CSV and JSON.

Storage: one SQLite file at ./data/app.db; path via .env. Ship a Dockerfile, a docker-compose.yml, and a README covering backups and reverse-proxy setup.

Out of scope, deliberately: accounts and OAuth, push notifications, receipt scanning, live exchange rates, payment integrations, native mobile apps. A PWA manifest so it installs to a home screen is the only concession.

Delivery standard

Inspect the repository first, then write a short implementation plan before writing code.

Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.

Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.

Include responsive layouts plus genuine empty, loading, success, validation, and failure states.

Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.

Add structured logs around every external call and return actionable errors without leaking sensitive details.

Write unit tests for the core logic and one automated test of the main user journey.

Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

Acceptance criteria

A clean install starts the app using only the README and .env.example.

The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.

Invalid input, missing configuration, provider failure, and an empty database each have a usable state.

The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.

Tests, type checking, linting, and a production build all pass with no ignored failures.

No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

Non-goals

Do not build these, and do not claim to have replaced them:

Native iOS and Android apps, push reminders included.

Your friends' existing accounts and muscle memory.

Receipt scanning and itemized splits.

Automatic currency conversion at live rates.

Settle-up integrations with payment apps.

What you still own after launch

Run migrations, backups, restores, and dependency updates.

Test the critical journey after every model, API, or hosting change.

Monitor failures and fix the edge cases a first prompt will miss.

Maintain every third-party integration as APIs and OAuth rules change.

Risk

High consequence. Use this as a prototype or personal aid. Keep a qualified human and an established provider in the loop for consequential decisions.

Editorial confidence in this assessment: high. No reviewed project implementation is linked yet.

Existing alternatives

Before building, compare these checked options:

Spliit — Share a link, split, settle. No accounts, no ads. Use their instance or run your own

Tricount — Free and huge in Europe; closed source and bunq-owned, new signups get a bunq account, and CSV export left with the old Premium

IHateMoney — Around since 2011, proudly boring, in declared maintenance mode; use their free instance or one docker run

Prior art

Working open-source software you can read, fork, or borrow from before starting:

spliit — open-source reference implementation worth stealing ideas from

minimum cash flow algorithm — the debt simplification trick, explained

Generated by Can It Be Vibe Coded? · Full report: https://www.canitbevibecoded.com/splitwise