2026 — Present
Rinciku
AI-powered finance companion for mixed IDR/USD income — chat & photo expense logging, real-time purchase advice grounded in your budget.
- The problem
- Most budgeting apps assume a single currency, a stable paycheck, and that the user will diligently categorize every transaction. Real life for a young Indonesian earning across a local job and USD freelance income is messier: income arrives in two currencies, expenses swing month to month, and the question that actually matters — "can I afford this right now?" — usually gets answered after the money is already spent, if at all. Rinciku's core idea is to make both sides of that problem frictionless. An essentials planner establishes a monthly baseline of non-negotiable costs, expenses get logged through natural-language chat ("spent 45k on lunch") or a photo of a receipt read by a vision model, and an AI purchase-consultation feature answers "can I buy this?" grounded in the user's actual income, essentials baseline, spending so far, and days left in the month — not generic financial advice.
- My role
- Solo developer — product definition, database schema, shared TypeScript domain layer, the web app, the mobile app, and the AI integration
- Outcome
- Live in production — shipped on the App Store, web app live, Android in progress
Key decisions
One shared TypeScript domain layer across web and native
A pnpm/Turborepo monorepo where the Vite web app and the Expo native app import the same domain logic, Zod schemas, formatting and i18n through dependency-injected Supabase client factories. The same query and mutation code runs on both platforms instead of being written twice and drifting apart.
Grounded the AI in structured budget state rather than chat context
Purchase advice is answered against real income, the essentials baseline, spend-to-date and days left in the month. That is the difference between advice that is trustworthy with money and advice that merely sounds confident — and it is what lets the answer show the numbers it used.
Calibrated the vision model for Indonesian financial documents specifically
Dot-separator IDR notation, local bank transfer layouts and e-wallet screenshots each needed real prompt work. An AI feature still needs domain-specific engineering; it is not just an API call.
My Role & Impact
I own the entire stack end to end. The architecture is a pnpm/Turborepo monorepo where a Vite web app and an Expo native app share one portable "brain" — domain logic, Zod schemas, formatting, and i18n — through dependency-injected Supabase client factories, so the same query and mutation code runs on both platforms instead of being duplicated. Building this as a real, shipped product rather than a demo forced product decisions a tutorial never asks for: what data model lets one query answer "can I afford this" without the user doing mental math, and how much of the AI's reasoning needs to be visible so the user trusts a financial answer from a chatbot.
The app is in active use today, starting with myself as the first user, and is published on the App Store under my own account.
What I Learned
- Grounding an AI feature in real, structured state (income, essentials, spend-to-date, days remaining) rather than free-floating chat context — the difference between advice that's actually trustworthy with money and advice that merely sounds confident.
- Building a domain layer that is genuinely shared, not copy-pasted, between a web SPA and a native mobile app.
- Calibrating a vision model's prompt specifically for Indonesian financial documents — dot-separator IDR notation, local bank transfer layouts, e-wallet screenshots — a reminder that AI features still need real domain-specific engineering, not just an API call.
Showcase
Screenshots
Web app
Mobile app (iOS)
