Time-Tracking App with Geo-Fencing for Multi-Location Teams

Time tracking looks like a solved problem: start, stop, total. It gets demanding the moment tracking leaves the office. Hours are booked where the work actually happens – across several distributed locations belonging to the same company. And every entry is not a throwaway log line but a record that still has to be explainable months later: who tracked time, when, and for which location. That answers the data model question before the first screen has been designed.

The second requirement was optional geofencing – technically a good deal more than a point-in-polygon test. A location fix never gives you a point; it gives you a point plus an accuracy radius. Out in the open that radius is small; between tall buildings, inside halls, in underground parking garages or reinforced-concrete environments it grows considerably. Anyone clocking in close to the edge of a zone will, under a naive check, produce both kinds of error: false rejections and false approvals. Then there are the platforms themselves – iOS and Android treat background location differently, each with its own region-monitoring APIs, tiered permission levels and power-saving mechanisms that deliberately throttle background work.

The third requirement was the role and permission model, and that is the real architectural core. The same app serves employees, managers and admins with different views, different slices of data and different permitted actions. The hard part is not showing and hiding buttons but the question behind it: which records may a given role read and write at all, when several distributed locations are involved and responsibilities overlap? An answer that exists only in the user interface is not an answer.

The app is built as a single Flutter codebase for iOS and Android. The domain logic – entries, shifts, role logic, presentation – therefore exists exactly once, and both platforms receive the same change at the same time. What stays platform-specific is essentially whatever genuinely depends on the operating system: location permissions, background behavior, power-saving rules. Those parts sit behind a narrow interface, so the rest of the application never needs to know which platform it is running on.

Data and authentication live in Google Cloud. Identity comes from the authentication layer, and the role assignment belongs to the backend – not to the device and not to a variable set in the client. Server-side rules decide, per request, which entries, shifts and locations a role is allowed to read or modify. The role-dependent interface is therefore a projection of that same permission model rather than its enforcement: whatever the app does not show a role would not be retrievable server-side for that role anyway.

The real-time overview of shifts and entries comes out of the same data layer. Clients subscribe to updated state instead of polling at intervals – that keeps the view current without every open app generating requests by the minute. For a management role this means an overview that moves along with the work; for the architecture it means the permission rules have to hold for live subscriptions as well, not just for one-off reads.

Geofencing sits on top as an optional layer: locations are defined, and wherever the option is active an entry is tied to the matching location. Optional is a deliberate choice here, not a compromise – there are job sites where reliable positioning simply is not available. Having authentication, storage, real-time distribution and scaling come from managed cloud services is precisely what makes it feasible to build an application of this size and keep maintaining it without a large operations overhead: operational effort stays where it can be automated.

• Location-independent time tracking
• Optional geo-fencing per site
• Roles & permissions (employees, managers, admins)
• Real-time overview of shifts & entries
• One codebase for iOS & Android

Delivered and in production use at the client: one app instead of separate silo tools, with role-based permissions and geo-fencing in day-to-day operation. Out of respect for the client relationship we do not disclose internal metrics here – the technical execution speaks for itself.

In projects of this kind the effort rarely sits where people expect it. The tracking itself – start, stop, add up – is the smallest part. What matters is the permission model and the edge cases: what happens when someone forgets to clock out, who is allowed to correct it afterwards, does the correction stay visible, how does the app behave when positioning is imprecise, and what should apply when there is no connectivity on site. These questions belong before the first line of interface code, because they shape the data model. Retrofitted later, every single one of them gets expensive.

When weighing a custom build against off-the-shelf software, the most useful question is not about feature lists but about structure: can the roles, locations and approval paths of the business be expressed in the standard product's model? If they can, standard software is almost always the cheaper choice, and saying so openly is part of the advice. If they cannot, processes end up permanently bent around a tool – and that is the point at which a custom application pays off, one that models role logic, location binding and reporting the way the work is actually done.