Café Time Tracking

The problem

The business needed a simple way for employees to record start and end times from their phones. The manager also needed a reliable view of attendance, incomplete shifts, adjustment requests, worked hours, and weekly overtime.

The first version had to be affordable, easy to use in a browser, and small enough to validate before operational complexity accumulated.

Discovery and constraints

• The employee flow needed to work well on a phone.
• The manager and employee workflows needed separate views.
• Attendance data and individual access codes could not appear in the public repository.
• Overtime needed to follow a weekly threshold, rather than treating weekend work as overtime automatically.
• The first release intentionally excluded GPS and a native mobile application.

Key decisions

Browser-first, not a native app

A browser workflow removed install and maintenance friction for a small operation.

Separate employee and manager experiences

The daily action stays focused for employees, while management history and adjustment review remain in the manager workflow.

Weekly overtime rules

The application evaluates overtime against the weekly limit, which avoids incorrectly classifying weekend work by itself as overtime.

Public snapshot instead of operational source

The public case uses fictional examples and schema-level documentation. Operational data stays outside version control and outside the portfolio.

Solution flow

Employee identifies themselves
-> records a start or end time
-> Node.js API validates and stores the event
-> PostgreSQL groups events into worked periods
-> calculations produce daily, weekly, and monthly totals
-> manager reviews history, warnings, overtime, and adjustment requests

Engineering and reliability

• Mobile-first web interface.
• Node.js REST API serving the frontend.
• PostgreSQL hosted through Supabase.
• Tests for hour calculation, weekly overtime, daily history, punch alerts, and manager attention.
• Warnings for incomplete or duplicated records.
• Adjustment requests stay outside the calculation until management approval.

Outcome and evidence

• The application is in use in the real workflow, confirmed 27/08/2026.
• The sanitized snapshot documents the product flow, constraints, and public-data boundary.
• Hour, overtime, and alert behavior is covered by nine automated tests in the public snapshot.
• The operational repository kept evolving after the snapshot: in October 2026 it received fixes to confirm saved punches, track failed records, and align hour calculations with alerts. The public repository remains the August snapshot.

The evidence here is operational use and rule-level tests. Time saved, adoption volume, and financial impact have not been measured for this case.

What I learned

A small operational tool becomes trustworthy when its business rules are explicit. The user interface is only one part of the product; the definitions behind overtime, incomplete shifts, and approved corrections determine whether people can rely on it.

What I would improve next

• Confirm the next operational need through observed use before expanding scope.
• Improve authentication and access controls only when the existing lightweight workflow no longer fits the operation.
• Keep public examples synthetic and review every screenshot before release.