Mess360
A multi-mess SaaS for Bangladeshi messes: daily meals, bazar, deposits and an automatic month-end meal rate and settlement that every member can see.
- Started
- Stack
- 10 technologies
The problem
What needed solving
Shared messes track meals, bazar and deposits in notebooks and spreadsheets, so the month-end meal rate and each member's balance are worked out by hand, error-prone and hard to verify.
My role
Responsibilities
Product design, architecture and full-stack implementation: the settlement and month-locking model, per-mess role-based access control, the nightly meal scheduler, the Angular web app and the Flutter mobile app.
The solution
Architecture summary
A shared ledger built around the settlement month: server-calculated totals, an automatic meal rate and settlement, immutable closed months, an audit trail, per-mess roles and bilingual web and mobile clients.
Case study
In detail
Context
In Bangladesh, students and working people commonly share a mess: a rented flat where members pool money for daily meals. The bookkeeping is usually a notebook or a spreadsheet: who ate how many meals, who bought the bazar, who deposited how much. At the end of the month someone works out the meal rate and every member's due or advance by hand. Mistakes are common, and disputes are hard to settle because nobody can see the same numbers.
Mess360 replaces that with a shared, auditable ledger that every member can open from a phone browser, in English or Bangla.
Design decisions
The month is the unit of truth. Meals, expenses, deposits and bills all belong to a settlement month, which defaults to the month of their date but can be set explicitly, so bazar bought on 30 September can be charged to October. Totals, reports and the month-end settlement are all computed against that month.
Closed months are immutable. Closing a month calculates the meal rate and every member's balance and then locks the period: meals, expenses, payments, requests and recalculation are all rejected with HTTP 423. Reopening requires a specific permission and a written reason, and is audited.
Money is cancelled, never deleted. Financial records move through draft, confirmed and cancelled states. Totals are calculated on the server, and every important change is written to an audit log, so a balance can always be traced back to the entries that produced it.
Automation never overwrites a person. A nightly job runs at each mess's own schedule time and generates the next day's meals from members' weekly schedules, overridden by approved requests. Manually entered meals are never overwritten.
Permissions are evaluated per mess. One account can belong to several messes with a different role in each (mess admin, monthly meal manager or member), and each mess's data is visible only to its own members.
Architecture
- Spring Boot 3.5 on Java 17, with Spring Security 6 (JWT access and refresh tokens, Google sign-in) and Spring Data JPA
- PostgreSQL 16 with Flyway migrations; Redis for caching
- Angular 17 (standalone components and signals) with Tailwind CSS, fully bilingual in English and Bangla
- Flutter mobile app for Android and iOS
- Twelve reports with print view and PDF (OpenPDF) and Excel (Apache POI) export
- Self-service sign-up with Free, Standard and Premium packages, paid manually via bKash, Nagad, Rocket or bank and verified by an administrator
Outcomes
What changed
- Month-end meal rate and every member's due or advance calculated automatically, with a live preview during the month
- Settled months locked against change, so a closed month's numbers cannot drift afterwards
- Every financial change traceable through an audit log; records are cancelled, never deleted
- Next-day meals generated automatically from members' schedules, without overwriting manual entries
- Members check their own meals, deposits and balance from any phone, in English or Bangla