A time clock for employees app is not a button, it is a payroll record.

What the record has to contain

Under the Fair Labor Standards Act an employer keeps a defined set of records for every non-exempt worker, and the list is longer than most people expect. Full name and social security number, address including zip code, birth date if the worker is younger than 19, sex and occupation, the time and day of week when the workweek begins, hours worked each day, total hours worked each workweek, the basis on which wages are paid, the regular hourly pay rate, total daily or weekly straight-time earnings, total overtime earnings for the workweek, all additions to or deductions from wages, total wages paid each pay period, and the date of payment with the pay period it covers.

One of those is a design decision rather than data you collect. The time and day of week when the workweek begins is a setting somebody chooses, not something you infer from the punches, and it is what overtime is measured against. Get that boundary wrong and every weekly total is wrong with it.

Retention splits by record type. Payroll records are preserved for at least three years. Time cards and the other records on which wage computations are based are retained for two years. So a punch is not a row you tidy away once payroll has run. It is evidence with a shelf life, which means edit and delete need different permissions.

None of this requires a clock on a wall. The Department of Labor is explicit that employers may use any timekeeping method they choose, including workers writing their own times, and that any plan is acceptable as long as it is complete and accurate. Complete and accurate is the entire bar, which is why a small custom app is a legitimate answer here.

US Department of Labor, Fact Sheet 21, recordkeeping under the FLSA

A punch is a claim, so make it checkable

A clock in is a claim that a person was somewhere at a time, and everything that lifts a punch clock app above a stopwatch is about how much of that claim the record can support later. One shared tablet by the door means nobody punches in from bed, and it also means no per person location and a queue at shift change. Personal phones remove the queue and raise a policy question about who pays for the phone and the data, which varies by state and is worth asking your own counsel about.

If location is part of your answer, be exact about what the platform offers. The Expo location module supports geofencing that runs a task when a device enters or leaves a region, and the limits are firm: up to 100 active geofences per app on Android, and 20 regions monitored at once on iOS. Background location stops if the user force quits the app. iOS relaunches a terminated app for a geofence event, while on Android a terminated app will not come back for one. Background use also needs the always permission on iOS, background location and a foreground service permission on Android, and a development build rather than Expo Go.

Read those as product constraints, not a setup checklist. Automatic clock in that depends on the app still being alive will miss punches, and a missed punch is a pay dispute. The defensible pattern is a punch the worker taps, with location captured alongside it as evidence, and a geofence used only to nudge somebody who forgot.

Expo Location docs, background location and geofencing

No signal, and a clock the worker controls

Two failures break time apps on real sites and they tend to arrive together: no coverage where people start work, and a device clock that reads whatever the phone says. The offline half is a queue. The punch is written locally, marked unsent, and pushed when the network returns, and the stored record keeps the moment of the punch rather than the moment it synced. Show the worker that it is pending, or they will tap again and you will have two. The mechanics are the same wherever this comes up: clocking in with no signal.

The clock half is trust. A device clock can be changed in settings, so a timestamp written on a phone is a claim rather than a fact. Keep both values: the time the device reported and the time your server received the punch. When the two disagree by more than the offline gap explains, flag the record rather than quietly correcting it.

Then there are the punches that never happened. A missed clock out is not an edge case, it is a weekly event, and the answer is a correction with a reason, a named approver and both values kept. Let people see their own hours and raise the correction themselves, which is what an employee self service app is for.

What to build first, and what to leave out

A staff clock in app earns its place in week one with five things and no more. One large button showing the current state, today's total, this week's total against the workweek start you configured, a history the worker can scroll back through, and an export payroll can actually read. The export is the part to test hardest.

The tempting additions look like features and behave like commitments. Scheduling, leave balances, overtime rules that differ by state, and anything that puts a wage figure on the screen. Paying people is a different system with harder consequences, and a clean export is a better seam than a half-built payroll.

One addition is worth deciding early if it applies to you: time against a job rather than time against a day. Contractors, repair crews and agencies need the hours split by what they were spent on, which is the same ground as a work order management app. Bolting that on later means reshaping every stored record, so choose before the first punch is saved.