Splitto

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Splitto

Inspiration

I built Splitto because I was not consistently recording my own spending. Receipts, shared purchases, cards, e-wallets, investments, and durable things all told different parts of my financial story, but most finance apps still expected repetitive manual entry.

The question behind Splitto is simple: what would personal finance look like if AI removed the tedious entry without taking control away from the user?

What it does

Splitto turns a receipt or payment image into a strict, editable financial draft. The user can correct low-confidence labels, assign items to themselves, a partner, or Shared, and review the exact split before confirming it.

The model never writes money directly. Deterministic server code validates integer MYR sen, discounts, tax treatment, rounding, and allocation before an idempotent transaction updates the balance. Confirmed expenses stay traceable, and settlements reduce what is owed without pretending Splitto moved money.

The wider product keeps four financial domains visibly and structurally separate: Shared receipts, personal Money, Portfolio snapshots, and Things. That separation prevents a shared obligation from silently becoming personal spending or a portfolio value from being mistaken for cash flow.

How I built it

The app uses React, TypeScript, Next-compatible Vinext routing, Cloudflare Workers, D1, R2, Drizzle, Lucide, the OpenAI Responses API, and GPT-5.6.

GPT-5.6 receives the image with a focused extraction instruction and must return a strict JSON Schema. The request disables response storage and uses a hashed safety identifier. The result remains a draft until deterministic validation and human confirmation succeed.

I used Codex throughout Build Week as an engineering collaborator. It helped me turn an SRS into the first vertical slice, implement and review the accounting model, debug real receipt rounding and tax cases, add regression tests, audit mobile behavior, and bound database work after production Worker CPU failures. I reviewed diffs, made the key product and trust decisions, and required typecheck, lint, build, tests, and responsive QA before treating changes as complete.

Challenges

Real receipts exposed details that a polished mockup did not. One receipt was off by one sen until rounding became a first-class adjustment. Printed tax can be included or added, so storing only a tax amount could double-count it. Large phone photos hit framework body limits before application validation. HEIC files, AI timeouts, quota failures, and mobile touch targets all needed explicit fallbacks.

The hardest product decision was refusing an easy shortcut: a shared receipt does not automatically become a personal expense. Without payer accounts and receivables, that would double-count money. Splitto combines the domains in the interface while keeping their sources of truth separate.

What I learned

The core principle became “zero-entry, not zero-control.” AI is most useful here when it proposes structured facts and makes uncertainty visible. Financial correctness, authorization, reconciliation, and final commitment should remain deterministic and reviewable.

What is next

The next step is a short weekly review inbox for statements, screenshots, and eventually authorized financial APIs. Bank sync, automatic card/provider data, and personalized financial advice are future work, not claims about this build.

Built With

• cloudflare-d1
• cloudflare-r2
• cloudflare-workers
• codex
• drizzle-orm
• gpt-5.6
• json-schema
• next.js
• openai-responses-api
• react
• typescript
• vinext