Workmate

Problem

When you work casually for more than one employer, pay depends on the workplace, the day of the week, public holidays, breaks and rates that change over time. Tracking it in notes or spreadsheets makes it hard to know what you'll actually be paid.

Approach

Built first as a React 19 and Firebase app with Google sign-in, Firestore and Firebase Hosting. Now migrating to a modular-monolith ASP.NET Core API on .NET 10 with PostgreSQL, so pay rules and data ownership are enforced on the server instead of the browser — planned through architecture decision records and a staged, reversible migration.

Technical highlights

• Effective-dated rate history with Saturday, Sunday and public-holiday rates, breaks and overnight shifts
• pnpm monorepo with a React web app and a layered .NET API (Api, Application, Domain, Infrastructure)
• Owner-scoped use cases: identity comes only from a verified Firebase token, and other users' records behave as missing
• Four ADRs and a staged Firestore-to-PostgreSQL migration plan with parity checks and rollback
• 64 automated tests — 55 xUnit tests across domain, use cases and DI, plus 9 pay-hours regression tests

What I learned

• Moving business rules out of the client turns implicit behaviour into explicit decisions, such as rate fallbacks and locked shifts.
• Migrating identity and data separately — keeping Firebase Auth first — keeps the risk of each step manageable.
• Writing ADRs before code makes trade-offs like monolith vs. microservices and Firestore vs. PostgreSQL easy to review.