<- Featured work
FEATURED / PRODUCT SYSTEM

ReceiptSplit

Receipt-first bill splitting for shared rooms, item-level allocation, and manual UPI hand-off.

Next.jsTypeScriptFastAPIPostgreSQLSQLAlchemy
GitHub repo
The system

Groups need to move from a shared receipt to an agreed split without treating a payment hand-off as proof.

Full-stack product system for shared expenses and explicit settlement state.

Project visuals

See the system before the explanation.

Diagrams and project artifacts, each shown with its current evidence status.

Diagram showing a shared receipt entering an editable OCR draft, confirmed items passing through a deterministic split engine into persistent room state, then a manual UPI hand-off with payer-asserted status.
Room-to-settlement flow Based on the current README and architecture notes; the app does not process, hold, or verify funds.
01 / Build

What exists

Project scope

  • A shared-room product connects receipt OCR, reviewable drafts, and equal or item-wise allocation.
  • Money calculations use integer paise with deterministic residual allocation.
  • Participants coordinate a manual UPI hand-off while payment states remain explicit user assertions.

Architecture

  • The Next.js client sends room, bill, and OCR actions to a FastAPI modular monolith.
  • The backend owns split calculations and persistent room state in PostgreSQL; mutations also append durable room events.
  • Authorized clients replay/refetch room state, then use an external UPI hand-off for settlement coordination.
02 / Ownership

Full-Stack Product Engineer

Built a full-stack bill-splitting product connecting receipt OCR, item allocation, shared rooms, persistent state, and payment coordination.

Contribution

  • Implemented equal and item-wise splits with deterministic integer-paise allocation.
  • Connected OCR drafts to a shared-room workflow, with review before extracted lines become bill items.
  • Built persistent room state and event replay/refetch behavior for collaborative updates.

Collaborative scope

  • Public copy stays at the product and architecture level; no per-file ownership claim is needed for this summary.
  • UPI opens an external hand-off and the app records user assertions; it does not verify a bank transfer.
03 / Decisions

Engineering judgment

Key decisions

  • Represent currency as integer paise and make residual allocation deterministic.
  • Keep extracted OCR lines in an editable draft until a person confirms them.
  • Use durable events as the source of truth and treat process-local SSE as a notification to refetch.

Proof highlights

  • Public repository and current README/architecture notes were checked for this update.
  • The included diagram describes the documented workflow and does not claim a current healthy deployment.
Product workflow

From discovery to coordination.

Create a room

Start a shared bill and invite authenticated participants.

Review OCR

Check and edit the receipt draft before it becomes bill data.

Split items

Allocate items and totals deterministically in integer paise.

Hand off

Open UPI outside the app; payer status remains a user assertion.

Boundary

What this evidence does not claim

The product architecture is documented; current API health and production reliability were not checked in this update.

  • ReceiptSplit does not process, hold, or verify funds; settlement is an external hand-off.
  • Payment statuses are participant and payer assertions, not bank confirmation.
  • Current API health, production reliability, and user scale are not claimed.