The problem
A small restaurant needed one desktop app to run its whole day, menus, orders, billing, offers, and reporting, instead of separate spreadsheets and paper tickets that had to be reconciled by hand at the end of a shift.
What I built
I built it end to end as freelance Java work: a Swing desktop application with role-based dashboards, full CRUD over meals and orders, a billing flow that applies offers and rewards, reporting screens, and binary file persistence for the restaurant’s data.
Role dashboards
Separate dashboards for the roles that run a restaurant's day, from the floor to the back office.
Meals, orders, and billing
Full CRUD over the menu, order entry, and billing in one flow.
Offers and rewards
Promotional offers and a rewards scheme sit alongside the standard billing path.
Reports
Reporting screens summarize the data the app already persists.
This was also the project that made me care about proper data storage. Binary file persistence works, but every schema change meant touching the files that read and wrote it directly, with no query language to fall back on.
Tech stack
- Testing
- JUnit: Unit tests
What I learned
A file you have to parse by hand is a database you haven’t built yet.
Feeling the limits of binary file persistence on a real, changing app is a large part of why I reach for an actual database and an ORM or query layer on everything I’ve built since.