# Finly > A personal-finance MVP connecting receipt review, shared bills, realtime item claims, and traceable settlement on a balanced ledger. Everyday money. Shared bills. Clearer decisions. - URL: https://weaveward.com/work/finly-personal-finance-split-bill-app - Stage: Prototype - Year: 2026 - Industry: Finance - Context: Internal product - Capabilities: Mobile apps, Web apps, AI solutions - Technologies: TypeScript, Expo, React Native, Fastify, PGlite (PostgreSQL), Drizzle ORM, Socket.IO, zod, tesseract.js, Playwright ## The challenge Shared spending needs more than a calculator. People need to review receipt items, agree on discounts and charges, understand who owes whom, and correct a mistake without losing the history behind a balance. Finly is an internal personal-finance and bill-splitting MVP for that workflow. It records money and shared obligations; the current scope does not hold funds or initiate a payment through a provider. ## What we built One Expo and React Native app connects to a typed Fastify API, with Indonesian as the default language and English available. - **Accounts and transactions.** Personal accounts, expenses, income, and transfers connect to a balanced double-entry ledger - **Capture with review.** A Review Inbox lets users check captured information, correct fields, and manage duplicates. Current source formats are synthetic DEMO formats; real bank and e-wallet formats remain unverified - **Flexible bill splits.** Equal, custom-amount, percentage, and item-based splits handle agreed discounts, service charges, taxes, and rounding - **Realtime item claims.** Participants can claim items and see shared bill activity across open screens - **Receipt-to-bill workflow.** Receipt images feed an editable review screen through configurable hosted vision providers or Tesseract and rule-based fallback. Model output is validated before it enters a bill - **Controlled payment-detail sharing.** Circle permissions, masking, and PIN step-up govern access to stored payment details. Settlement is recorded through participant and payer confirmation - **Correction and history.** Bill changes, reversals, and adjustments retain a traceable relationship to the original records The responsive interface targets phones and larger screens from one codebase. The documented local validation is for the web; a shared codebase does not establish that native behavior has been tested on a device. ## How it works ### Shared TypeScript money logic The TypeScript workspace shares Zod schemas, parsers, and pure money logic between the app and API. Integer minor-unit arithmetic and allocation rules keep the bill total and its shares consistent. ### Ledger, API and live updates PGlite and Drizzle provide the current MVP data layer. Ledger corrections use new postings rather than silently changing posted history. Fastify owns authorization and validation, while Socket.IO carries live item-claim and notification updates. ### Reviewed receipt processing Receipt processing has an explicit review step and a fallback path. Hosted AI providers are configurable, and their replies are checked against the expected structure. This implementation does not imply verified extraction accuracy on real customer receipts. ## Current stage Project documentation records 372 critical tests passing on 9 October 2026. Earlier MVP verification notes record 15 web journeys passing against the local API and synthetic demo data. These are historical project reports; the tests and finance database were not rerun or inspected for this portfolio update. Finly remains an internal prototype. The current API rejects its development-only OTP provider in production mode, so real authentication requires further implementation. Native Android and iOS device checks, production push, managed secrets, and real financial-source integrations remain open. The hosted receipt AI path was documented as tested with stubbed provider replies; no live-model accuracy or commercial result is claimed. The gallery shows synthetic DEMO receipts used to exercise parsing and review. They are test inputs, not customer financial records or screenshots of the application. ## Where this fits Apps that manage shared obligations need understandable totals, reviewable changes, and clear access rules. We connect [mobile apps](/services/mobile-apps), [web applications](/services/web-apps), and [AI-assisted processing](/services/ai-solutions) around that foundation. [Talk to our team](/contact) about your product.