zee360 is how a franchise brand keeps track of every location it has: the contracts, the fees, the accounting integrations, and how all of that changed over time. One app serves many brands, and each brand gets its own subdomain and its own pool of users.
When I joined, the front end was a prototype built fast with an AI editor. It worked for a demo, and it wasn’t going to survive real data or a second developer. I rebuilt it into something a team could keep building on. Now I take the hard problems myself, hand work to the other front-end developer, and make the calls across the stack with the backend team.
Reviewing a bulk upload. Bad cells are flagged before anything saves, and locations missing from the file get called out instead of quietly archived. Demo data.
What I built
- The architecture under the prototype. State moved into Pinia stores, and every screen goes through the same component, store and service layers. That let us swap mock data for the real API one service file at a time instead of touching every screen.
- A local cache that makes screens instant. Data lives in IndexedDB and syncs only what changed since the last visit, so a list of thousands of locations renders immediately and freshens in the background.
- Sign-in for many brands at once. AWS Cognito with PKCE, password reset, silent token refresh and route guards, with the subdomain picking the right user pool.
- Bulk location upload. Upload a spreadsheet, review it in an editable grid with validation, undo and redo, and bulk edits, then save.
- The shared pieces. Comboboxes, drawers, confirm dialogs and a role-based permission gate the rest of the app is built from.
The locations list. Demo data.
How it’s held together
Every change goes through a written plan, tests and code review, and CI runs lint, tests and a build on every pull request. The suite has grown past 270 tests while the app went from prototype to product.
A location’s contract history, showing when each setting changed. Demo data.