2025 — Present
Kasbon
Cloud-based POS for Indonesian UMKM — profit tracking, debt (hutang) management, multi-device sync via Supabase.
- The problem
- Kasbon was designed around three real personas: a warung owner who has never used a POS and just needs simple, reliable sales tracking; a clothing-shop owner juggling stock across a physical stall and online marketplaces who keeps losing track of cost price and profit; and a café owner who needs a fast checkout and real sales analytics. The product is built around profit tracking — not just revenue — and built-in debt (hutang) management, since informal credit to regular customers is a normal part of how these businesses actually operate, a feature most POS apps ignore entirely. The original plan was an offline-first app with a local SQLite database syncing to a backend, prioritizing reliability on unreliable connections. Partway through, I re-architected the whole app onto a Supabase-only cloud model with Row Level Security — a deliberate trade of "always works with no signal" for "your data follows you across every device," after concluding that was the more valuable guarantee for how owners actually use the app: phone at the counter, tablet for end-of-day reports.
- My role
- Solo developer — product definition, Flutter app (clean architecture, feature-based modules), Supabase schema & RLS policies, deployment
- Outcome
- Live in production
Key decisions
Re-architected from offline-first SQLite to Supabase-only cloud, mid-project
A deliberate trade of "always works with no signal" for "your data follows you across every device" — the more valuable guarantee given how owners actually work: phone at the counter, tablet for end-of-day reports. It touched almost every layer, and doing it deliberately rather than patching around the original design is why the app is materially simpler and more reliable today.
Postgres Row Level Security as the actual enforcement layer
Multi-tenant isolation is enforced in the database rather than by a client-side check that a bug could bypass.
Built around profit and hutang rather than revenue
Cost price and profit, not just sales totals — and built-in debt management, because informal credit to regular customers is a normal part of how these businesses operate. Most POS apps ignore it entirely.
My Role & Impact
I built this from a full business brief — personas, a tiered freemium pricing model, and a multi-month roadmap — down to a working POS a shop owner can use to close a sale in seconds and print or share a receipt over WhatsApp. The mid-project migration from offline-first SQLite to cloud-only Supabase touched almost every layer of the app, and doing it deliberately rather than patching around the original design is the decision I'm most glad I made — the app is materially simpler and more reliable for it today.
What I Learned
- Recognizing when an early architectural bet (offline-first) no longer serves the product, and having the discipline to migrate cleanly instead of accumulating workarounds around it.
- Postgres Row Level Security as the actual enforcement layer for multi-tenant data, not just a client-side check that a bug could bypass.
- Designing for a genuinely low-tech-literacy user — comfortable with WhatsApp, never used a POS — where simplicity is the feature, not a compromise.
Showcase
Screenshots
The app across desktop and mobile, running on demo shop data.
