Travora

Overview

A seventh-semester project built like a product

Travora is my 7th semester project. I picked the workflow the same way I pick work for the travel agency: find something people genuinely do badly, and make the software carry the parts they get wrong. Here that is money on a trip.

A trip is a budget with dates, a destination and a party size.
Every expense stores the original currency, the NPR equivalent, and the rate used.
Receipts are photographed and read by OCR rather than retyped.

Problem

A spreadsheet stops working the moment you cross a border

A sheet handles one person and one currency well. A trip is neither. Once spending happens in baht against a budget in rupees, a total means nothing unless the rate sits next to the amount, and a rate looked up afterwards is not the rate that was paid.

A converted total with no stored rate cannot be explained later.
Categories that live in one person's head cannot be reported on.
Receipts in a camera roll are not data until somebody types them in.
Reconciliation always happens later, when the details have been forgotten.

What was built

What I built

React 19 and TypeScript on Vite, with Tailwind and Radix primitives through shadcn/ui, Zustand for client state, and Supabase underneath for auth and PostgreSQL. The decisions that matter are in the data model rather than the framework list.

Onboarding is an interview: destination, dates, budget, party size and interests.
A wallet with running balance and expense entry, and a filterable history.
Recharts for the category breakdown, so spending reads as a picture.
Expenses hang off both a trip and a category, so the same spending reads either way.

Diagram

Schema

Five tables, and no way to read someone else's

The schema is deliberately small. users extends Supabase Auth rather than duplicating it, trips belong to a user, and expenses belong to a trip and a category. Categories are the interesting case, because a null user_id means a system default everyone can read.

Row-level security is enabled on all five tables, not only the obvious ones.
Category reads match defaults or your own rows; writes match only your own.
Deleting a user cascades through trips, expenses and chat history.
Seven default categories are seeded at migration, so a new account is never empty.

Database schema

database/schema.sql

Travora, five tables all of them behind row-level security

A small schema on purpose. Users extend Supabase Auth rather than duplicating it, expenses hang off both a trip and a category, and a category with no owner is a system default everybody can read.

Owned by a user, cascades on deleteLinks an expense to its trip and its kindNullable owner, null means a shared default

Row-level security is enabled on all five tables, so 'whose data is this' is answered by PostgreSQL rather than by a filter in the front end. Drag to orbit, and select a table to read its columns.

Tables — select one to inspect it

expenses

The records everything else exists to explain

Each expense stores the amount as it was paid, the NPR equivalent, and the rate that connects them, so a total can be re-derived and explained months later instead of being taken on trust. The receipt image is kept alongside it.

Columns

idtextpk
trip_idtextfk
category_idtextfk
amountnumericas paid
currencytext
amount_in_nprnumeric
exchange_ratenumericthe rate actually used
payment_methodtextcash · card · digital
receipt_imagetextfrom in-browser OCR
expense_datetimestamptz

Foreign keys

trip_id → trips.id, cascade
category_id → categories.id

OCR

Turning a receipt into a record without typing it

Expense entry is where trackers get abandoned, so the entry path had to be shorter than the excuse for skipping it. Tesseract.js runs the OCR in the browser, so the image never leaves the device to become text, and the app keeps the photo beside the parsed figures.

OCR runs client-side. No upload step, no third-party image service.
The image is retained with its format, so the entry stays checkable months later.
Loading state is explicit, because OCR on a phone is slow enough that silence reads as failure.
Payment method is constrained to cash, card or digital rather than free text.

AI

Where the AI earns its place

The assistant does one job: turn a destination, a length of stay, a budget and a list of interests into a draft itinerary worth editing. Groq's hosted LLaMA generates it, the result is stored back onto the trip, and the conversation lives in its own table.

Itineraries are generated from the trip record onboarding already collected.
The result is stored on the trip, so it survives a reload and can be revised.
Chat history is persisted per user, which is what makes a follow-up question work.
No figure in the app comes from the model. Every one comes from a recorded expense.

Outcome

The feature I shipped and then deleted

The most useful thing I did to Travora was take something out. I built live foreign-exchange fetching, shipped it, and removed it, because the fallback behaviour did more damage than the feature did good. A wrong rate applied silently is worse than no automatic rate at all.

The forex module was implemented, shipped, then deleted along with its references.
Currency narrowed to NPR rather than offering a list the app could not honestly support.
Expenses still carry the rate that was used, because that is data, not a live dependency.
A feature that guesses when it fails does not belong in something that counts money.

Reflection

What it taught me that the VAT system did not

The VAT system taught me to enforce invariants in the database. Travora taught me the other half: a system nobody bothers to use has no invariants worth enforcing. Everything hard here was about lowering the cost of entering a record.

The security boundary belongs in the database here too, not in a client filter.
Reduce the effort of correct data entry before adding anything that analyses it.
Ship a feature, watch it fail honestly, and remove it rather than defend it.
Store the inputs to a calculation, not only its result.

What's next

What comes next

Travora sits in the same domain as the agency work, so the natural extensions connect the two. A trip a business books and a trip a person budgets are the same journey from two sides.

Shared trips, so a party of travellers keeps one budget.
Rates pinned at expense time, if it can be done without a silent fallback.
Exports matching the formats the accounting work already produces.
Offline entry, which is the obvious borrow from the VAT system.