Geofenced check-ins
Clocking normally happens inside a defined area around the workplace, with a manual fallback the customer must switch on.
Resource / TapInn
How we built TapInn, from geofence to payroll-ready export.
TapInn is the Aprex solution for businesses with employees across multiple locations. The product brings together geofenced check-ins, checklists, HSE routines, deviation reporting and documentation in a single workflow, from the phone in the field to follow-up by managers. This is the story of how we built it, which technical decisions we made, and what we changed along the way.
Last updated: September 26, 2026
- 01
The problem TapInn solves
Many field teams still rely on paper, spreadsheets, messages or several disconnected systems for attendance, time logs, checklists and deviations. That means duplicated work and weak traceability. When management needs to document what was actually done at each location, the answer is scattered across chat logs, spreadsheets and photos on private phones. TapInn attacks this with one simple idea: work is documented where it happens, while it happens.
- 02
Three surfaces with distinct roles
The solution consists of three separate surfaces. Employees use the mobile app or the mobile-friendly web. Managers and customer administrators work in a dedicated portal with an overview of attendance, tasks, deviations and documentation. Internal operations for sales, support and administration sit apart from both. New signups go through a separate open flow.
- 03
Check-in with geofence as the default
Check-in is the core of TapInn, and the architecture is geo-first: clocking in normally happens inside a defined area around the workplace. Manual clock-in outside the geofence exists as a fallback, but only where the customer has explicitly enabled it. Projects can have their own geofence areas, so each stamp attaches to the right project. The client clock is never trusted blindly: the check-in time is clamped against server time within a window of about two minutes, with an absolute cap of 48 hours to catch clocks that have drifted badly.
- 04
Offline clocking without duplicates
Employees often work where coverage is poor: basements, car parks, rural areas. Clock-ins and other actions are therefore queued locally on the phone and sent when the connection returns. A server-side idempotency contract prevents duplicates: write routes accept an optional Idempotency-Key header, the first request with a given key runs normally and the response is cached, while a replay with the same key and the same body receives the original response back without a new row and without re-running side effects such as manager notifications. The same key with a different body returns error code 409. Keys are scoped to tenant, user, endpoint and key value, never global, and only successful responses are cached.
- 05
Modules, HSE and payroll-ready exports
TapInn is built as a module system where functionality is enabled per need: geo time stamping, shift scheduling, AI planning, availability, shift marketplace, absence, tasks, communication, compliance, HSE, cost forecasting, project time and documents. The HSE area covers incident reporting with an offline queue on mobile, inspection tools, competence overviews, chemicals and safety data sheets, equipment, risk assessments and measures, plus whistleblowing with its own handoff flow to case handlers. HSE is switched on per tenant after the business confirms it meets the conditions for use. On the payroll side TapInn delivers payroll-ready CSV, export profiles, pay-type mapping, preflight checks before export, export packages with history, period locking and a pay-cost overview. Direct integrations with payroll systems are explicitly out of scope: the product produces a quality-assured export basis that the customer takes into their own payroll system. TapInn also contains no invoicing.
- 06
Five technical decisions we stand by
First: one codebase for web and API. The Next.js application serves both the user interface and the API routes, with shared validation and a single deploy to relate to. Second: Postgres with Prisma and dedicated tables. The database is Neon Postgres, the schema uses dedicated tapinn_* tables, and migrations can be rehearsed in isolated rehearsal environments before they run against real databases. Third: native apps, not just web. Field work happens on the phone, often with gloves, poor light and weak signal, so the iOS app is built with SwiftUI and the Android app with Kotlin. Fourth: geo-first with strict defaults. Every softening of the check-in rules is a setting the customer switches on, with a strict default. Fifth: events and audit as first-class data. Check-ins, deviations, notifications and export actions are logged so they can be traced afterwards, together with activity logging, export history and period locking.
- 07
What we changed along the way
The product has moved fast. Proximity-based check-in was toned down early in favour of the geofence as the main mechanism. The summer of 2026 went into getting the idempotency and offline contract in place. The HSE area grew from simple deviation registration into a broad compliance area with inspections, competence, chemicals and whistleblowing. In September 2026 we chose email codes over BankID for signing flows, which lowers the threshold for field employees without giving up verifiable identity: each signature binds to document hash, party, timestamp and intent, with a full audit trail. That same autumn an extensive MCP layer was built, machine-readable tool interfaces over scheduling, staffing, HSE, administration and integrations, opening the door to AI-assisted operations on top of TapInn data.
- 08
Quality, operations and privacy
Quality work follows a fixed pattern: define the gate, document the evidence, separate what is tested from what remains. Each finding is classified with a status and exact commit, run and environment, and evidence counts only for the commit and environment it was taken from. Web releases go through a doctor script that checks the host machine, Node version and environment, then a production release with smoke testing against the live environment and automatic rollback on failure. Monitoring runs through Sentry without personal data by default. Privacy is treated as architecture: minimisation, access and deletion are built into the product and agreements. Location data is collected only to the extent check-in requires. For information about employees who use TapInn at work, the employer (the customer) is the data controller and Aprex the data processor under the data processing agreement; Aprex is the controller for its own websites, customer contacts and support requests.
- 09
What we learned
The most important lesson is that trust is the product's real database. Time data that is not trusted will not be used, no matter how elegant the dashboards are. That is why we have invested so heavily in geo rules, clock validation, idempotency and audit trails: each layer removes one reason to doubt the numbers. The second lesson is that offline is not the exception but the norm in field work. An offline queue with server-side idempotency costs more to build than a simple POST, but it is the difference between a tool employees trust and one they work around. The third is that scope discipline is a feature: every time we have said no to building payroll integrations, invoicing or monitoring functions directly into the product, TapInn has become clearer to understand, simpler to maintain and tidier to document.
Overview
Technical building blocks
These are the building blocks the article walks through, from check-in and offline queues to HSE, exports and operations.
Clock validation
Check-in time is clamped against server time within about two minutes, with an absolute cap of 48 hours.
Offline queue
Actions are stored locally on the phone on poor networks and sync when the connection returns.
Idempotency contract
Idempotency-Key prevents duplicate writes on replay, with 409 on incorrect key reuse.
HSE module
Incidents, inspections, competence, chemicals, risk and whistleblowing as part of the daily workflow.
Payroll-ready exports
CSV, export profiles, pay-type mapping, preflight, history and period locking, with no direct payroll integrations.
Native apps
iOS with SwiftUI and Android with Kotlin against the same API base as the web client.
Operations and audit
Scripted releases with rollback, Sentry without personal data by default, and audit trails on actions.
FAQ
How we built TapInn FAQ
- What is TapInn?
- TapInn is Aprex's own product for businesses with employees across multiple locations. It brings together geofenced check-ins, checklists, HSE routines, deviation reporting and documentation in one workflow.
- How does offline clocking work in TapInn?
- Clock-ins and other actions queue locally on the phone and are sent when the connection returns. A server-side idempotency contract with Idempotency-Key stops replays from creating duplicate writes.
- Is a geofence the same as continuous tracking?
- No. The geofence is used for checking in and out around defined locations, and nothing else. Use should be clearly explained, limited to purpose, and handled according to applicable privacy rules.
- Does TapInn integrate directly with payroll systems?
- No. TapInn delivers a quality-assured export basis with payroll-ready CSV, profiles, pay-type mapping, preflight and period locking, which the customer takes into their own payroll system.
Built and run by Aprex
TapInn is an Aprex product in daily operation. We know what happens after launch, because we are the ones who get the call when something stops. Figures and claims are used only where they can be documented.
Want to test TapInn in a scoped pilot?
Send a short note about number of employees, locations, your current time log and which systems TapInn may need to talk to.
Contact Aprex about TapInn →