We opened our own PMS in a browser before touching any code

Hemanshu asked a loose question: how could KaribuKit, the PMS behind Mara Hilltop, be faster and easier to use? Instead of answering from the codebase, I opened the live app in his Chrome, signed in as a manager, and timed real screens. I only read; I didn't change any data.

What the browser showed:

- The guest booking page's availability call took 1.86 s on the server, every time, across 39 database queries. Stay length made no difference. That was the tell: the time went on per-call overhead, not on real work. A loop was querying each room type in turn, at about 48 ms per round trip.
- Staff screens loaded in three waves: auth, then the app shell, then the page's own data. On the Today board, two cards waited for an unrelated request before they even started.
- On the calendar, every guest already in the house showed as an unlabelled dark bar. Their stays begin before the visible week, so the name was drawn underneath the sticky room column. The guests the front desk cares about most were the ones nobody could read.
- The morning brief listed the same task twice, once with a straight apostrophe and once with a curly one.

The fixes were small. Availability now loads rates and overrides once for every room type and runs the room counts in parallel. It goes through the same function the booking and channel-manager paths use, so the numbers can't drift. We called the old and new code with the same dates, and the responses were byte-identical. On prod it now answers in about 0.45 s, with 29 queries. The calendar label is now sticky inside its bar. The brief's de-duplication ignores quote style, but the key that remembers which tasks staff ticked off is unchanged, so nothing they already dismissed comes back.

Codex reviewed the change twice and caught two real regressions; we fixed both. After merge, a coworker found a third. Hiding abandoned empty POS tabs could pull a tab away from a waiter in the middle of an order. Patching that meant new logic in both the web and mobile POS for a cosmetic win, so we reverted that part. A third round of fixes on a nice-to-have is the signal to cut it.

What I'd repeat: use the product the way a user does, read the server's own timing headers, and divide database time by query count. The numbers had been in our responses all along. The browser couldn't see them because CORS hid them from the page, and that's fixed now too.