The starting point
Time tracking is the way in, not the product. It is what forces a company to install something, which is why the market is full of tools that record hours and stop there. The problem we cared about starts right after that.
An organization with several branches knows what each one bills and does not know how it works. The pain points we found, repeated across every client we spoke to:
- Records that are hard to defend: unvalidated clock-ins and frequent manual corrections, which turn any inspection into a manual reconstruction.
- HR documentation —payslips, contracts— sent by email, with no read receipt and no way to prove it arrived.
- Operational tasks taken as done because someone says so, with no evidence that they were carried out.
- Branches that are impossible to compare: each one «seems» to work well because there are no homogeneous metrics and no real cost per site.
- Decisions about people —promotions, extra staffing, shift changes— made on impressions, with no measured pattern behind them.
- Anomalies spotted only once they show up in the month's results.
The goal
That daily operations are recorded once and serve both purposes: complying and deciding. Attendance, execution and documentation come in through the employee app as part of their day; they come out through the dashboard as indices that can be compared across branches.
The operational intelligence module is what closes the loop, and what makes this more than a time clock. It builds a reliability index and an operational efficiency index —real cost against historical—, constructs each employee's behavior pattern, which is what beats a one-off report, and on top of it produces an operational assessment with a diagnosis and a promotion-candidate signal. Anomaly detection warns while there is still time to correct.
The design constraint was that none of this could ask anything extra of the person doing the work. Clocking in had to stay a two-second gesture.
What the platform does
The functional scope is split into modules that share the same entity-and-branch structure:
- Time tracking: three validation layers —geofence, schedule and device—, clock-in from the app, remotely with its own time zone or by QR with a token and supervisor validation; breaks with automatic deduction, manual shifts, and a review and approval flow.
- Tasks: creation with custom fields, individual or bulk assignment, photo and video evidence, priorities and deadlines, validation with acceptance or reasoned rejection, and a scoring scale that feeds the worker's efficiency index.
- Document management: payslips and contracts with their monthly cycle and legal retention, private documents with role-based visibility, read receipts and a push notification that opens the document directly.
- Operational intelligence: operations dashboard with the reliability and efficiency indices, behavior patterns, cost analysis with per-branch rates and anomaly detection.
- Entity and branches: tax details and time zone at entity level, propagated to each site; geofence, breaks, tolerance and rate per branch; and a global view that compares them all.
- Employees and security: four roles —worker, supervisor, manager and owner— with a permission matrix, two-factor authentication, biometrics, trusted devices and multi-entity access with a switcher.
- Compliance: time records under Spain's RDL 8/2019 with timestamping, immutability and traceability; data processing in line with GDPR; and reports ready to present in an inspection.
The challenges
The first was trust in the data. A clock-in works as evidence only if it can be reconstructed: where it happened, on which device, at what real time and what was changed afterwards. Hence the three validation layers and an immutable history where every change leaves a trace, so a specific working day can be proven in seconds.
The second was analysis. Comparing is not putting numbers side by side: you have to normalize different realities —shifts, calendars, team sizes, per-site rates— before the comparison means anything. And the interesting signals are not in a single day but in sustained change, so the engine works on patterns rather than isolated incidents.
The third was the organizational structure. Multi-entity and multi-branch at once forces you to decide what is configured at the top and propagated, what is adjusted per site, and what happens to historical records when a branch is deactivated. That decision shapes the entire data model.
The fourth was architectural. A product that is at once a field app, a document manager, a management dashboard and a subscription platform does not fit in a single service without becoming fragile.
How it is built
The mobile app is Flutter with Riverpod for state and injection, GoRouter for declarative navigation and Freezed for immutable models. It leans on Firebase for authentication, Firestore, storage, notifications and Crashlytics, and on Geolocator and Google Maps for location validation.
Behind it there is a monorepo of microservices in Node and TypeScript, with each domain in its own service —clock-in, sync, analytics, reports, tasks, documents and sales— on top of a shared common package. That way the intelligence layer can evolve and deploy without touching the one that records, which is the one that cannot afford a failure.
The management dashboard and the SaaS layer are Next.js with React 19, with Firebase Admin on the server and Stripe for subscriptions.
