Operations Dashboard / 2026
UMS
Laundry and uniform-room operations system
Case study
The project at a glance
Overview
UMS is a focused internal operations app for laundry and uniform-room workflows, built around billing, guest laundry tracking, handovers, account controls, audit history, and revenue reporting.
Problem
Operational laundry and uniform-room work can spread across manual notes, bills, room records, staff handovers, and revenue summaries, making it hard to audit and manage cleanly.
Solution
Build a local web app with structured billing flows, guest laundry itemization, handover notes, admin account controls, audit logs, CSV revenue exports, and a database path that can move from SQLite to PostgreSQL.
Outcome
The app has a documented local-operation baseline, validated PostgreSQL migration path, stress-test evidence, and public-safe portfolio copy that avoids publishing operational databases, employer-branded screenshots, or internal records.
Tools used
Stack and proof
Public evidence boundary
Local validation notes cover SQLite integrity, PostgreSQL migration, authenticated stress testing, revenue rendering, hardening checks, and database-neutral UI behavior.
Role
Product architecture, Python web app, database workflow, QA
Case study system
What this project proves
UMS is the strongest operations case study: a real internal workflow app shaped around billing, guest laundry, handovers, account controls, audit logs, revenue reporting, and database migration readiness.
Stress check
800
authenticated requests at 50 workers with zero request errors
Database
2 paths
SQLite local fallback and validated PostgreSQL migration path
Scope
Ops
billing, guest laundry, handovers, audit logs, and revenue
Privacy
Safe
employer-branded screenshots and operational data stay local
Process
Build path
- 01
Map daily operating flows
The app models practical laundry and uniform-room work: bills, guest laundry records, handover notes, staff account controls, and reporting.
- 02
Harden storage and access
SQLite stays available for local use while PostgreSQL is documented for heavier internal use and multiple simultaneous users.
- 03
Add audit and reporting surfaces
Account changes, billing, guest laundry, handovers, system activity, revenue charts, and CSV export are treated as first-class workflows.
- 04
Sanitize for public presentation
The portfolio uses code-native previews and public-safe copy instead of publishing employer-branded screenshots or operational records.
Evidence
Source map
What can be shown publicly, what stays local, and what still needs proof before launch.
Sanitized portfolio preview
Public-safePublic-safe visual asset now shows the operations workflow without employer branding or operational records.
Migration notes
Local-onlyPublic-safe summary of the SQLite-to-PostgreSQL migration, orphan-row check, startup check, and stress baseline.
Presentation capture set
PrivateLocal screenshots and presentation files exist, but they contain internal/employer branding and stay out of the public site.
Sanitized demo assets
PendingA real non-employer demo screenshot set is still needed beyond the current portfolio-safe visual asset.
Next
What needs to happen before this is final
- Create a fully sanitized public screenshot set using non-employer demo data.
- Write a focused operations case study around the billing and handover workflows.
- Document the production hardening path separately from the public portfolio story.
Visual evidence
Public-safe presentation assets