The challenge

Many companies had no reliable record of working hours at all. Hours were estimated from the scheduled shift or from what the supervisor remembered. That made it impossible to run payroll on real data, and equally impossible to know who had actually worked, how long they stayed on the job, or whether a shift had been covered.

The classic fix — a card punch clock or a biometric fingerprint reader — solves half the problem and creates another. You buy the hardware, install it and maintain it, and the record still lives separately from wherever wages are calculated. Between attendance tracking and the payslip there is always an export, an intermediate spreadsheet and a person reconciling the two.

The solution

The platform chains six pieces together: a tablet at each company's entrance, the face recognition that identifies the employee, the shift event they select themselves, a multi-tenant backend that receives the record, a payroll engine that turns it into money, and a web panel per company. The data is entered once, on the tablet, and is never touched by hand again before the payslip.

From the employee's side it is three taps. They arrive, stand in front of the tablet mounted at the entrance, and the camera recognises them: no employee number to type, no card to carry, no finger on a reader. With identity already confirmed, the screen offers the four possible events of the shift — in, break in, break out and out — and they tap the right one. The record is stored with its exact timestamp.

Separating identification from event type is what makes the record genuinely useful. A clock that only marks «arrived» forces you to infer everything else; here the employee declares what they are doing on top of an identity already verified by their face, which closes off buddy punching at the root. The device is fixed and shared, so recording doesn't depend on every person owning a phone, bringing it charged, or having signal.

On the other side, each company logs into its own web panel and sees only its own punches and its own employees. That's where the record stops being an attendance mark and turns into money: payroll lives in the same system, with each person's pay type already configured — hourly, daily or other schemes — along with the corresponding rate. The platform takes the hours actually recorded, matches them against that employee's pay scheme, and calculates what they are owed.

This is what separates the platform from a traditional system. In most implementations the clock lives in one place and payroll in another. Here the data is born on the tablet and reaches the calculation without passing through anyone's hands.

Platform architecture

The punching front end runs on React Native, so the same codebase serves the entrance tablet and the mobile clients. The web panel is built with Next.js and persistence is MySQL. Behind them the platform isn't a single block: it is split into independent services, packaged in Docker containers and published behind a load balancer.

That split isn't an aesthetic preference — the shape of the demand imposes it. Face recognition and punch recording have opposite load profiles: storing a record is a minimal write, while comparing a face is compute-intensive work. And both happen at once, because all three hundred companies start their shift within the same half hour. With everything in one process, the eight-o'clock recognition peak degrades the rest of the system. Split apart, the recognition service scales on its own during that window and settles back down without the web panel or the payroll engine ever noticing.

Recognition happens server-side. The tablet captures the image and sends it; the service compares it and returns the identity, and that photo is stored alongside the punch as evidence. Solving it on the server rather than on the device has two concrete reasons. The first is operational: the model and the enrolled faces are updated in one place, without depending on three hundred tablets scattered across the country running the right version. The second concerns disputes: when someone challenges a punch, the evidence is an image held by the system, not a record that lived on the very device being challenged.

That leaves one question open, and it's the one the architecture answers best: what happens when there is no network. The tablet keeps recording punches even when it loses connectivity. Records queue locally and sync on their own once communication returns. That isn't a convenience: shift start is the busiest moment in the entire system, and a ten-minute outage right then would mean, without local queueing, an entire company's day going unrecorded. With the record held on the device, a network failure becomes a sync delay instead of a hole in payroll.

Access control is what keeps 300+ companies coexisting in one system. Using the application requires signing in, and it's the authenticated user — with their permissions — who determines which company they are operating on. A user may have access to more than one and switch between them; what they can never do is see one they have no permission for. Everything the platform returns is scoped to that selection, so isolation between companies isn't an interface convention but a condition of every query.

That isolation is what the handling of the evidence rests on — the most sensitive data the platform stores. The image travels encrypted, is stored encrypted, stays bound to the punch that produced it, and is visible only from the panel of the company that punch belongs to, to users with permission. Access to that evidence is logged, and retention follows a policy rather than indefinite accumulation.

Finally, settlement and visibility run at different speeds, by design. Punches appear in the web panel's sheets as soon as they arrive: anyone looking at today's shift has it right now. Payroll, on the other hand, is resolved at period close, once the set of records is complete. Calculating a settlement on the fly over an open period means calculating on data that is still going to change; separating immediate reading from closing calculation avoids recalculating and reissuing every time a late punch comes in.

The implementation

The structural decision was to build it as a single multi-tenant platform rather than one installation per client. Today more than 300 companies share the same system, each with its own employees, pay types and punches fully isolated from the rest. The alternative — an instance per company — would have been simpler to launch and utterly unworkable two years in: three hundred databases to migrate, three hundred deployments for every fix.

The cost of that decision is paid upfront and repaid forever. Every query, every report and every screen has to be scoped to the company asking for it, and a leak between tenants wouldn't be just another bug: it would be one company's payroll visible to another. In return, onboarding a new company is a signup rather than a project, and an improvement ships once and reaches all three hundred.

Development took two years and the platform remains under corrective and evolutionary maintenance. That «remains» isn't an administrative footnote: a system that calculates wages lives close to rules that change, and the platform keeps adapting as pay arrangements and requirements appear that didn't exist when it was designed.