The problem
The Marco Polo hotel in Dhaka needed a system to run its back office — daily cash across cash, bKash, and bank wallets, purchases, supplier payables, salary advances, loans, expenses, staff attendance, and full accounting reports (trial balance, profit and loss, balance sheet, day book). Nothing like this existed for them off the shelf that matched how a Bangladeshi hotel actually handles cash and mobile wallets side by side. I was the sole developer on this project — there was no team to divide the work with, so every decision about scope, architecture, and UI was mine to make and live with.
Deciding on a desktop metaphor
The first real design decision was how to organize a system that has to serve accounting, HR, inventory, catalog, and reporting from one login, for staff who are not going to read documentation before their shift starts. I chose to build it like a desktop running in the browser — a home screen with app icons, and each function opening in its own windowed workspace. This wasn't a cosmetic choice. Hotel staff already understand "click an icon, a window opens, you can have more than one open at once" from every computer they've used; borrowing that model meant close to zero onboarding for the accounting and HR concepts underneath it.
The home screen: app icons for accounting, HR, inventory, catalog, reports, IAM, the workspace, and the user's profile — the entire system's surface area, visible at once.
Daily cash across three kinds of money
Hotels in Dhaka don't move money through one channel. Cash, bKash, and bank transfers all happen in the same shift, and the daily cash workspace had to reconcile all three without forcing staff to think in accounting terms. A staff member picks a date and a wallet, adds income or expenses, and sees the opening balance, cash received, payments, and cash in hand for that wallet — while every entry silently posts as a journal or receipt voucher against the correct account code underneath. That split — a simple form on top, double-entry bookkeeping underneath — was the core architectural bet of the whole system: front-line staff should never need to know what a journal voucher is, but the books still have to close correctly at the end of the month.
Attendance as its own subsystem
HR needed daily and monthly attendance across departments and shifts — status, check-in and check-out times, lateness, hours worked, and overtime, with a toggle between daily and monthly views rather than two separate screens. Building this as one workspace with a view toggle, instead of two, kept the mental model consistent for HR staff who move between "what happened today" and "how did this month look" constantly.
Reports that have to be right, not just fast
The accounting reports — trial balance, profit and loss, balance sheet, and day book — all read from the same underlying ledger the daily cash workspace writes to. The balance sheet includes a built-in check that assets equal liabilities plus equity, which sounds like a minor detail but was one of the more important things I built: as the sole developer, I didn't have a second engineer to catch a posting-logic bug before it reached a real financial report, so the report itself had to be able to catch its own inconsistencies.
What I'd do differently
Being the only developer meant fast decisions but no second opinion on architecture — in particular, the windowed-workspace model works well for the current set of apps, but I'd want to revisit how workspace state is managed if the system grows to support multiple properties instead of just the one hotel it was built for. I'd also add more automated reconciliation checks earlier — the balance sheet check came from a real near-miss during testing, and I'd rather build that instinct into more reports from the start next time.