Why I threw generic time clocks in the trash and built my own HR system (Part 1)
If you've ever dealt with attendance tracking in a company, you know the easy solution is always: "Buy a time clock on Amazon, stick it on the wall, and screw it". Sounds nice, but in practice, it's bullshit. Especially if you don't run a traditional company.
A while ago I wrote some ideas about the architecture of my custom HR module for Drupal (rh_mexico). But since development is still alive and I'm still adding features for the future, I decided to rewrite this series from scratch to tell you the real story without limiting ourselves to an exact number of chapters. Let's get straight to the point.
The Problem: We aren't generic office workers
We are an events agency. Our operation isn't about arriving at 9:00 AM, warming a chair, and leaving at 6:00 PM.
The real life of our company includes:
- Scouting days at locations.
- Endless meetings with clients.
- Late-night setups.
- Hybrid days where you start at home and end up at a venue.
What happens when you force these people into a pre-made time clock? The system breaks. A commercial clock only understands "Clocked in at 8:12". It has no idea if the guy is at the office, building a stage three hours out of the city, or working remotely with permission.
Context is King
When a system doesn't understand your operation, the company ends up adapting to the device, and that's the worst design mistake you can make. You end up patching everything with spreadsheets, manual justifications, and a massive headache for the HR staff.
I wanted the system to adapt to us.
I didn't need a clock capturing fingerprints like an idiot; I needed a platform that understood context. That's why I built rh_mexico directly on Drupal.
I implemented a web check-in with operational motives and geolocation. Now it's not a simple timestamp, it's live data: "Clocked in at 9:00 AM from his phone, under the status 'Event Setup'". And since I hate relying on generic stuff, I even threw in an auto check-in system via WiFi using Raspberry Pi for those who actually go to the office.
Instead of having a stupid box, I now have a complete ecosystem that connects attendance, vacations, tardiness, and reports under Mexican law, all automated and centralized.
In Part 2, I'll dive into the guts of the code and tell you about the real architecture of this beast, how I structured the entities, and why Drupal services are the real magic behind it.