Jobsite check-in is a solved problem on paper and an unsolved one in the dirt. The feature list is identical across every vendor — GPS, geofencing, photo verification, crew rosters — and adoption still collapses in week three, because adoption isn't decided by features. It's decided by what a 47-year-old concrete finisher with cracked hands and a two-generation-old Android does at 6:48 in the morning, in the rain, before coffee.
So this post isn't a feature list. It's the six design decisions that determine whether the thing gets used, and the reasoning for each, which you can apply whether you build it, buy ours, or buy someone else's.
Nobody is installing your app
Start here, because everything downstream follows from it. A construction crew will not install an app. Not because they're technophobic — they'll happily use WhatsApp all day — but because installing means an app store account, a password somebody forgot, storage on a full phone, an OS version that's too old, and a company asking for something on a personal device. Every one of those is a stopping point, and on a crew of twenty you will hit all of them.
The alternative that works: the QR sign already on the job, and the phone's browser. Most jobs already have a card or sign on the gate, the trailer, or the truck. Add a QR code to it. Camera, tap, page opens, done. No install, no account, no password. The phone's browser is the most widely deployed runtime in the world and the crew already knows how to use it.
Two consequences worth naming. First, a browser page can't do true background geofencing — it only knows where the phone is while the page is open. That's fine, because you want a deliberate human action anyway (see the punch section below). Second, you need the page to remember the phone, or you've traded an install problem for a login problem. Remember the device with a token the first time someone identifies themselves, and after that opening the page is opening their page.
For employees, identity is a short PIN — never a name-and-phone form, because an employee is already in your roster and asking again is both slower and an invitation to typos. One number pad, four digits, in.
Subs can't have logins and still have to be tracked
This is the requirement most products quietly duck. On a real job, a meaningful share of the bodies on site don't work for you. They're a framing crew from a sub you hired last week, and they will be gone in nine days. You cannot onboard them. You cannot give them roster entries, PINs, or credentials — the administrative cost exceeds the value, and half of them won't be back.
But you still need to know who was on your site, which is a safety and liability question before it's a payroll one. So the sub path has to be a genuinely different, lighter path:
- Phone number, name, company. Three fields, typed once. Normalize the phone down to its digits so the same person entering it three different ways is still one person.
- A selfie. Not surveillance theater — it's the difference between a name typed on a phone and evidence that a specific human was at a specific place. If there's an incident, that photo is what your insurer asks for.
- Remembered on the device. Fill it in on day one; on day two the page already knows them and it's one tap. This is the whole adoption trick for subs. If day two costs the same as day one, day three won't happen.
- A headcount. One sub foreman often speaks for his crew. Let him say "six of us" instead of pretending you'll get six individual check-ins, because you won't, and a truthful six beats a fictional one.
Keep the paths visibly separate in the interface. An employee should never see the sub form and vice versa. A single "flexible" form that asks employees for their company name is how you teach people the tool doesn't know who they are.
The fence should pick the job, not ask
The lazy implementation shows a dropdown of active jobs. On a company with thirty open jobs, that's a scrolling list of similar-sounding addresses presented to someone standing in mud, which produces exactly what you'd expect: the first item, the last item, or the wrong item. And job selection errors are expensive — they put hours on the wrong cost code, which is precisely the thing you bought this to fix.
The right behavior: take the phone's coordinates, compare them against every job's geofence, and resolve to the nearest one. Not "any fence that contains this point" — nearest. Two jobs on the same block, or a job across the street from your yard, will produce overlapping fences, and "the first fence that matched" is a coin flip. Nearest is deterministic, explainable, and almost always right.
Then show the answer as a confirmation, not a question: "You're at Riverside Field — 2 — correct?" with a small way to change it. One tap on the happy path, an escape hatch on the unhappy one. And when the QR code is scanned from the sign on that specific job, the job is already known and GPS is just a cross-check.
One primary button that changes by state
The instinct is a menu: Check In, Check Out, Switch Job, Submit Receipt, Daily Log. Five equal choices, which means five chances to pick wrong and a screen nobody reads.
Better: figure out what state the person is in, and render one large primary button that is the only thing they almost certainly want.
- Not on a job yet → I'm here
- On a job, still here → Done for the day
- On a job, but the GPS now reads a different job → Moved
Everything else — receipts, the end-of-day log — lives behind a smaller secondary row. The result is a screen that can be used correctly without being read, which is the actual bar for a phone used one-handed in gloves. The state machine is small enough to hold in your head, which is exactly why it works: three states, one obvious action in each.
If you want to see this on your own jobs — your addresses, your fences, your crew's phones — book a demo and we'll set up one job live.
Check-in must write the time clock
The most consequential decision in this whole design, and the easiest to get wrong.
A "site check-in" that is its own record — separate from your time clock — creates a reconciliation job that didn't exist before. Now someone in the office has two lists that describe the same morning and disagree: check-ins say eleven people were at Riverside; timesheets say nine. Who's right? Which one does payroll pay? That comparison is a weekly meeting nobody scheduled, and it's caused by the software.
So: "I'm here" writes an actual clock-in. "Done for the day" writes the clock-out. Changing sites writes an out on the first job and an in on the second, so the day splits between jobs automatically instead of somebody allocating it from memory on Friday. And the assignment board should follow reality — if a person taps in at a job they weren't scheduled for, the truth is the tap, not the plan.
One record, one timeline, one number that payroll and job cost both read. There is nothing to reconcile because there was never a second list.
This is also what makes travel pay tractable. Once you know who tapped in where and when, a drive that ends inside a job's fence can be attributed to the people who arrived there — including passengers, who otherwise never get paid for the ride because nobody was tracking them.
Two things nobody warns you about
Spanish is not a nice-to-have. On a lot of real crews it's the working language. This doesn't mean a translation project — the entire check-in surface is maybe forty short strings ("I'm here," "Done for the day," "Take a photo," "Your name"). Ship both languages from day one with a visible toggle, get a native speaker to read it rather than trusting a machine, and note that the crew member who half-understands the English version will use it wrong and blame himself. An English-only tool quietly excludes the people whose hours matter most to your job cost.
Fence radius needs per-job thought. A default radius around a geocoded street address is fine for a residential remodel and wrong for a 40-acre sports complex, where the address pin lands at a gate and the crew works half a mile from it. Too tight and the fence rejects people who are genuinely on site; too loose and it swallows the gas station across the road. Make the radius per-job and editable, set it when you set up the job, and accept that large sites need a deliberate number rather than a default. Also expect the geocoder to place brand-new construction — a street that didn't exist last year — somewhere approximate, so confirm the pin on a map rather than trusting the address.
You may not need any of this
Plainly: if you run one crew on one job at a time and the foreman texts you the head count, that works. Check-in earns its place when you have several jobs running at once, subs you don't employ moving between them, and a payroll week where "how many hours went to Riverside" is a genuinely hard question.
If that's you, the mechanics are on the site check-in feature page, the wider construction picture — coded receipts, job cost, daily logs — is on the construction solution page, and the job-costing story shows how a tap in a parking lot ends up on a cost report.