Amwag Attendance

Attendance sounds like a solved problem until it meets a real company: multiple branches, shifting schedules, employees and administrators with very different needs, and records that feed payroll and decisions. Off-the-shelf tools didn’t fit the operation’s rules — so the company needed its own system, and needed it to be dependable.

• Attendance records must be trustworthy — payroll and accountability depend on them.
• Check-ins must provably happen at the right branch, not from a phone at home.
• Administration needed visibility across branches without manual collation.
• Reports had to leave the system in a form managers actually use: PDF, in Arabic and English.

Two very different users share one system. An employee needs check-in to take seconds and to trust that their record is correct. An administrator needs to see anomalies quickly, manage exceptions fairly, and produce reports without exporting to spreadsheets and fixing them by hand.

If either experience fails, people route around the system — and the data stops being true.

• Full bilingual interface — Arabic and English across every screen and every generated document.
• Validation strict enough to prevent abuse, forgiving enough for legitimate edge cases (network changes, branch visits).
• Data loss is unacceptable: backups and restore had to be first-class features, not scripts on a server.
• Runs on pragmatic infrastructure — reliability through design, not through expensive platforms.

I designed and built the platform end to end: the data model and validation architecture, the employee and administration experiences, the reporting and backup subsystems, and the production deployment — plus ongoing product decisions as the operation’s rules evolved.

The strategy: make the honest path the easy path. Check-in is near-instant when you’re where you should be; every exception has a legitimate route through an administrator. Governance features were framed as protecting employees’ records, not surveilling them — which is also simply what the system does.

The platform is really two products on one data model:

• Employee surface — check in/out, personal history, and request flows, optimised for speed on a phone.
• Administration surface — branch dashboards, anomaly review, employee management, report generation, and system settings including backups.

Role-based access control separates what each role can see and change, down to the action level — an administrator of one branch is not an administrator of all branches.

1. Client

   • Next.js app
   • Employee UI
   • Admin UI
   • AR / EN

2. Service

   • TypeScript API
   • Auth & RBAC
   • IP / branch validation
   • PDF generation

3. Data

   • MySQL / MariaDB
   • Attendance records
   • Scheduled backups
   • Restore workflow

• Next.js + TypeScript end to end — one language, typed contracts between UI and API.
• Validation pipeline — identity, branch IP allow-lists, and shift rules evaluated server-side before any record is written.
• Reporting engine — parameterised queries feeding bilingual PDF exports for payroll periods and branch summaries.
• Backup & restore — scheduled database backups with an administrator-facing restore workflow, tested rather than assumed.Shown
• Auditability — administrative changes to records are attributable, so exceptions stay accountable.Stated

Internal tools deserve design too. The interface uses a calm dashboard language with clear status colors, dense-but-readable tables, and bilingual typography that keeps Arabic and English equally legible. Anomalies are surfaced, not buried: the admin home answers “what needs my attention today?” before anything else.

IP validation is a strong signal but not a perfect one — networks change, employees travel between branches. The trade-off: strict automatic validation with an explicit, logged administrative override, instead of loosening the rules for everyone.

Backups that have never been restored are a hope, not a plan. Building a real restore workflow took meaningful extra effort and was worth every hour.