Cathy CCRMS — Condo Rental Management PWA

I built CCRMS as an offline-first, mobile-first Progressive Web App — designed for one person, my mother, used one-handed on a phone while standing in a hallway. There was no team and no client meeting; the requirements came from watching how she actually worked and asking a lot of questions at the dinner table. The decision that shaped everything was making the device the source of truth, not the cloud. The app runs entirely on IndexedDB through Dexie.js, so it works at full speed whether or not there's a signal — internet is only ever used for backup, never for the app to function. The harder, more interesting work was the rental engine. I wrote a standalone algorithm specification before I wrote the code: deterministic money math where the same inputs always produce the same numbers. Payments always apply to the oldest unpaid period first, automatically. Security deposits are isolated from rent entirely — they never silently get consumed to cover a balance. Due periods are generated up front at contract creation so balances can't drift. Every rule had one north star: my mother must always be able to understand why a number is what it is.

The hardest part wasn't the offline layer — it was the money. Rental accounting looks simple until you actually model it. Partial payments, mid-contract extensions, daily versus monthly versus yearly rentals, deposits that get partly refunded and partly forfeited, periods that need to be waived without being marked paid. Each of these interacts with the others, and a single wrong assumption produces a balance that's quietly off by a few thousand pesos — the exact kind of error that erodes trust in software built for someone who already didn't fully trust software. So I stopped coding features and wrote the logic down as an authoritative spec first — end-date resolution, due-period generation, payment allocation, balance computation as a locked formula. That document became the referee: if the code and the spec ever disagreed, the spec won. Forcing myself to articulate every rule in plain language before implementing it caught contradictions I would never have found by just writing components. It taught me that for anything involving money, the specification is the hard part — the code is almost a formality after that.

I'd design the sync layer from day one instead of treating it as a Phase 2 problem. I made the right call keeping the MVP local-only and shippable, but because I deferred sync, I didn't model records with sync in mind early enough — UUIDs, timestamps, and conflict resolution are far cheaper to bake in at the schema stage than to retrofit. If my mother ever wants this on a second device or a tablet, the merge logic is the part I'd have to be most careful about, and I'd rather that foundation already existed.