Design decisions
One booking table for online and offline#
Staff were never going to stop taking bookings on the phone. So walk-in and phone bookings go into the same table as website bookings, with a source and a payment state. The database refuses a second booking for the same date, hall and meal, whichever door it came through.
Trade-off: Staff have to enter offline bookings themselves. In return, the calendar is always right.
'Booked' is not 'paid'#
An offline booking can be unpaid, paid another way, or food brought in kind, which is marked 'Not applicable'. Reports keep website money separate from offline money, so the board never sees a pending promise counted as income.
Trade-off: Reports look smaller than the activity really is, but they're honest.
Show the receipt, don't just link it#
Donors kept missing the download link and assumed they hadn't got a receipt. The confirmation page now shows the receipt as an image straight away, with the download beside it.
Trade-off: A heavier confirmation page, for fewer 'did my payment go through?' calls.
A read-only board view instead of admin access#
Board members wanted totals, covered days and shortfalls, not editing tools. They get a separate overview behind a passcode.
Trade-off: A shared passcode is convenient but weaker than individual board logins. That's next on my list.
No donor accounts#
Nobody wants another password to give ₹500. Checkout works as a guest, and donors find past bookings by phone number.
Trade-off: A phone number is weaker proof of identity than an OTP, so edits and cancellations go through staff.
Needs in real units, weekly or monthly#
Kitchens buy in different units than donors think in, and some needs are easier to state per month. Each item has its own unit, requirement period and preset amounts that staff can edit.
Trade-off: More settings for staff, but the progress bars mean something.