Walterstone — HR & Workforce Platform
What began as a way to record hours became a full workforce management system: employees, scheduling, absence, documents, payroll inputs and reporting, built as independent modules on a shared authentication and permissions core.
- Role
- Architect and full-stack engineer
- Timeline
- Sept 2025 — Present
- Status
- in progress
The problem
Small organisations run HR on a stack of disconnected tools — a spreadsheet for hours, email for absence requests, a folder for contracts. Each is individually fine and collectively unauditable. There is no single answer to who worked what, when, and under which agreement.
Design
Thirteen modules over one core. Authentication, roles and the employee record are shared; everything else — time logging, scheduling, absence, documents, onboarding, reporting — is a module that reads from that core and can be built, deployed or disabled independently. That boundary is what made it possible to start with time logging and keep adding without a rewrite.
Architecture
Thirteen modules sit on one shared core — Better-Auth sessions and roles, the employee record, departments, and the organisation's working rules. Attendance is drawn in full because it is the module the others were shaped around: time arrives from four different places and has to come out as one defensible figure. Live punches and imported clocking-terminal records are reconciled when a report is read rather than by rewriting either source, so neither can quietly overwrite the other, and every clocking spell survives into the audit trail.
The solution
A React front end against an Express and MongoDB API, with Better-Auth handling sessions and role-based access. Each module owns its own data and surfaces, and shares only the employee identity and permission model.
Result
In active development. Time logging, employee records and the permissions core are working; the remaining modules are being added against the same pattern. A separate premium marketing site is being built alongside it.
What I took from it
The module boundary earns its cost the third time you add a feature, not the first.
Scope growth is not a problem if the architecture anticipated it. The rewrite you avoid is the return on that design work.