Idea
We'd tried managing money in a spreadsheet — Google Sheets, an Excel workbook before that — but every transaction was a manual row, and none of the repetitive parts (categorizing, splitting a receipt, rolling everything into a monthly total) went away on their own. Some banks have their own budgeting view, but not every transaction happens digitally, and transfers between your own accounts get logged as spending and income even though moving money from one pocket to another doesn't change what you actually have. Bank apps also don't give you much control after the fact — you can't easily edit an existing transaction, and there's no way to tell one "the annual tax bill isn't a monthly expense." We wanted the convenience a spreadsheet promises without doing all of it by hand, so we built it.
Features
- Automatic transaction categorization
- Receipt capture straight from a LINE chat, with OCR parsing — no manual entry
- Monthly reports and budgets
- Works offline and syncs when you're back online (it's a PWA — install it like a
native app) - English and Thai localization
Tech stack
Backend is Django with a Strawberry GraphQL API on PostgreSQL (CloudNativePG in Kubernetes). Frontend is Vue 3 with Pinia, built as a PWA with offline support and
optimistic UI, so actions feel instant even before the server confirms them. Deployed on Kubernetes, fronted by the Gateway API; CI/CD runs on GitHub Actions.
I'm the sole engineer, in a two-person team — backend, frontend, infrastructure,
and CI/CD are all mine.
How I build it
Local dev runs the same Kubernetes manifests as production, on a Podman-backed `kind` cluster driven by Tilt — so what I test locally is the same shape as what's deployed, no docker-compose stand-in that quietly drifts from prod.
I work on several features in parallel using git worktrees — including LLM coding agents, each working a feature independently in its own worktree. Every worktree gets its own Kubernetes namespace, its own Postgres, and its own set of ports on the same shared cluster; the assignment is derived automatically, so spinning up a new worktree — mine or an agent's — never collides with what's already running.
Every feature starts as a written proposal (openspec) change — requirements, scenarios, a task list) before any code, and the code itself is written test-first: the agent writes the tests, watches them fail, then writes the implementation until they pass — checking its own work against the spec as it goes. Tests run automatically on every push in GitHub Actions — I don't run the suite by hand, and deploying to production is gated on it passing. My part is the functional check before a feature ships: read the diff, make sure the behavior actually matches the proposal. That combination — a spec that's hard to misread, tests the agent has to satisfy on its own, and CI enforcing both — is what makes it safe to hand a feature off to an agent working unsupervised in its own worktree.
Try it
Anyone can sign up and use JodRubJai — the source code itself stays closed. Live in production: JodRubJai.com