Context
I work in Emergency Medical Services (EMS) in Berlin — Rettungssanitäter — and built GoRuiz outside my EMS shifts. I know the domain from daily operations: shift planning, worker availability, documents, and the gap between office tools and what crews need in the field. The goal was a single system — not a demo — that admins and field staff would use every week.
What I built
Admin web app
Dashboard, worker management, Dienstplan, company settings — React + TypeScript.
Worker web portal
Browser access for staff — same API, role-scoped data.
Field mobile app
React Native (Expo): shifts, workday, documents, messages.
Shared backend
Node.js / Express, MongoDB, JWT, multi-tenant companyId scoping.
Architecture
Three clients consume one API. Tenant isolation and auth are enforced in the service layer — including legacy records where companyId may be null.
Key decisions
-
Multi-tenant from the start
Each company scoped by
companyId; admin ops always tenant-aware. - One API for web + mobile No duplicate business logic between clients.
- JWT + role-based access Documents via authenticated routes — not public uploads.
- i18n (DE / EN / ES) Mixed-language teams common in Berlin operations.
- CI · GitHub Actions · Docker Typecheck, tests and consistent MongoDB before merge.
- AI-assisted workflow Cursor, Claude, MCPs for boilerplate — reviewed before production.
Challenges
- Scheduling UX that office admins can trust and adjust quickly
- Mobile flows that work with intermittent connectivity
- Security boundaries for HR/medical documents across roles and tenants
- Shipping incrementally while working full-time in Emergency Medical Services (EMS)
Result
A maintainable codebase with clear module boundaries, typed clients, and delivery habits (Git, CI, review) that match how I would work in a product team.
Code and live access are private. I can walk through architecture, screenshots and technical decisions in an interview or call.