Work Time HeroTime tracking for teams paid by the hour
Work Time Hero lets hourly staff clock in from a phone or a desktop, and gives their employer the team's live status, correction requests to decide and hours to mark as paid. We built its back end, develop the web application and run the platform in production.
- Client
- Private client
- Sector
- Workforce management
- Year
- 2024 to 2026
- Platforms
- Web app, Mobile web
- Services
- Web development
A time-tracking service for companies that pay staff by the hour. Employees clock in and out against stamp codes such as Work, Break, Sick or Vacation, and employers turn those records into approved, reconciled hours they can pay.
Built for
- Employees, who clock in from whatever device is at hand.
- Employers and managers, who need to know who is working and what to pay.
- Platform administrators, who manage companies, plans, discount codes and translations.
The problem
Hourly pay depends on records made in a hurry. People forget to clock out, start on the wrong code or work past the end of a shift, and the mistake often surfaces only when someone checks a payslip.
The same hour can be worth different amounts. Weekend, holiday and overtime hours follow their own rules, and for a team spread across timezones each person's hours have to be split in their own local time.
Paying people is a step of its own. An employer needs to see how much of each person's month is already paid, pay the rest and hand an export to payroll, without recalculating anything by hand.
Goals
- 01Make clocking in and switching codes quick, with the current code always visible.
- 02Let employees fix their own mistakes through a request the employer approves or rejects.
- 03Split hours into regular, overtime, weekend and holiday time by each employer's own rules.
- 04Reconcile worked hours against paid hours every month, with an export for payroll.
- 05Run as a paid subscription service in eight languages.
Our role
We built the back end from its first commit, have developed the web application since 2025, and run the platform in production.
What we delivered
- Express and Prisma back end on the Bun runtime, with PostgreSQL and Redis
- React web application for employees, employers and administrators
- Clocking, stamp codes, work types, holidays and time-keeping schemes
- Correction requests, overtime confirmation and automatic clock-out
- Paid-hours reconciliation with CSV export
- Subscription plans, Stripe payments, discount codes and PDF invoices
- Two-factor sign-in and scoped API tokens
- Telavox telephony integration for live call status
- Translation system for eight languages, managed from the admin area
- Deployment pipeline, nightly backups and error monitoring
Services
How we worked
- 01
One module per part of the domain
The back end is 24 feature modules: clocking, corrections, overtime, paid hours, subscriptions, translations, Telavox and the rest, each with its own routes and controller.
- 02
Move the data layer to Prisma
In March 2026 the queries moved from a hand-written connection pool to Prisma 7, with the schema split by module and migrations applied as a deploy step.
- 03
Test on staging, then release
Every change deploys to a staging environment where the client tests it before it reaches production.
- 04
Release in a way that can be undone
Each deploy is a new release directory. Migrations run, the health check is called up to five times, and a failed check rolls the server back to the previous release.
- 05
Prove the backups
All three databases are backed up every night, encrypted, to S3. Every Sunday a job restores the latest backup into a temporary database and checks it.
Screens and features
Employers see who is working right now
Team totals, top and under performers, and each colleague's current stamp code.
Paid hours and corrections, reconciled
Worked, paid and remaining hours per person, and correction requests to approve or reject.
A clock that says what you are on
The clock card shows the current stamp code, when it started and for how long. Tapping another code asks once to confirm, then switches.
Corrections as requests
Employees propose new times for a record, and the employer approves or rejects each request with the original times beside it.
Time-keeping schemes
Each employer sets regular hours or day-by-day hours, and switches on overtime, weekend and holiday rules with their own limits and rates.
Overtime needs a yes
Fifteen minutes before a scheduled day ends, an overtime request is raised for confirmation, and a daily maximum caps what counts.
Automatic clock-out
An hourly job clocks out anyone who has passed the hours their scheme allows, and files the time as regular, overtime, weekend or holiday.
Paid hours, reconciled
For each person and month: hours worked, hours paid, hours to pay now and hours remaining. Mark people paid one at a time or all at once, then export to CSV.
Eight languages, edited without a release
English, Danish, German, Faroese, French, Icelandic, Norwegian and Swedish. The wording is held in the database and managed from the admin area, with import and export.
Technical choices
What the product is built with, and why.
- Prisma 7 on PostgreSQL
- The schema is split into one file per module, and migrations run as a step of the deploy, so each release carries its own database changes.
- Stored in UTC, calculated in local time
- Every timestamp is stored in UTC, and hour calculations run in the employee's own timezone. An hour split at the server's midnight would be paid as the wrong kind of hour.
- Deadlock retry with jitter
- Only true deadlocks are retried, with a randomised backoff so two colliding writes do not collide again. Every other error surfaces, so real bugs are not hidden.
- Redis for cache and locks
- Dashboards and coworker lists are cached, and the clock event that changes them clears exactly those entries. Billing changes run under a Redis lock, so two server instances cannot apply the same change twice.
- Socket.IO rooms per employer
- Telavox call status is pushed live into a room for each employer, over sockets that authenticate with the same token as the API.
- Shared query hooks in React
- Requests from the web application go through one HTTP service and shared hooks over TanStack Query, so loading, errors and token refresh behave the same on every screen.
Tracking hours that turn into pay?
Time rules, corrections and payroll exports are detail we like getting right. Tell us how your team works.