Context
Most budgeting apps come with the same requirement: connect your bank accounts through an aggregator. It works, but it means handing over your credentials, while most people simply want to know how much is left at the end of the month.
jibu takes the opposite bet: no aggregation, no sensitive banking data. You enter your income, your fixed costs and your spending, and the app computes what’s left in real time. The trade-off is deliberate: a little manual input in exchange for no dependency on a financial third party.
The project was run solo, from product scoping to operations: design, design system, database, security, billing, marketing pages and production deployment.
Scope
- Disposable income recomputed continuously from recurring income and fixed costs.
- Multiple accounts: current, joint, neobanks, each with its own balance.
- Shared budgeting: household model, invitations, per-member permissions.
- Subscriptions and instalment payments (3×, 4×, 10×) tracked over time.
- Calendar view, day by day, with automatic merchant recognition.
- Statement import (PDF, spreadsheets) to avoid re-entering data.
- Admin area: users, audit log, feedback, communications.
Technical decisions
The app is a Next.js 16 App Router frontend on top of Supabase (PostgreSQL, Auth, Storage). Two decisions shape everything else:
- Every mutation goes through a Server Action. No Supabase writes happen from the client, which concentrates access control on the server and keeps the surface auditable.
- Zod schemas are the single source of truth. Client validation, server validation and TypeScript types all derive from the same schema, so a business rule cannot drift between layers.
The rest follows: PostgreSQL row-level security on every user-facing table, strictly additive versioned migrations (49 so far), MFA and trusted devices, Stripe billing with plan downgrade handling, and an installable PWA with an offline mode.
Compliance and operations
Skipping bank aggregation radically simplifies compliance: no banking credentials are stored, and no third-party aggregator sits in the chain. Internal documentation covers GDPR and follows ISO 27001 practices: audit log, data minimisation, export and deletion on request.
On the operations side: protected main branch, mandatory GitHub Actions CI before merge, local Git
hooks blocking direct pushes, Vitest tests and a React regression check on every batch of changes.
Acquisition
Eight prerendered landing pages target the queries people actually type (budgeting, disposable income, expense tracking, budgeting as a couple, managing subscriptions) rather than a single product page. Each answers one intent and routes to sign-up.
Key deliverables
- Responsive, installable web app (PWA)
- PostgreSQL database under RLS, 49 versioned migrations
- Email authentication with MFA and trusted devices
- Stripe billing and plan-change flows
- Admin area and audit log
- Marketing and legal pages, internal technical documentation