Back to portfolio
Case studyRef. HRGECKOS

HR Management Platform

HR Geckos is a US-based HR operations platform that automates HR processes, connects HR systems and runs an HR helpdesk. Working remotely with the US engineering team, I built product interfaces and hardened the authentication and API layer that protects the platform's employee data.

  • React
  • Node.js
  • JWT
  • REST APIs
  • SQL

Particulars

Client
HR Geckos, US-based HR operations platform
Timeline
Jul 2025 – Jan 2026
Role
Full stack engineer, auth and API security
Team
Remote, with a US-based engineering team
Scope
HR workflow interfaces, authentication and REST API security

Note: Some implementation details are omitted for confidentiality. This case study covers my role, public product behaviour and general architecture only.

Exhibit A: HR Platform

Record summary

35%

Faster time to debug

0

Critical regressions

6

Consecutive sprint releases

01The mandate

HR software holds the most sensitive data a company has: identities, compensation, leave and performance records. The platform needed interfaces that made HR workflows easy for employees and HR teams, and a backend that held up against brute-force logins, injection and abuse without slowing anyone down.

It also had to be debuggable. When something failed in production, a team working across timezones needed to find out why, fast.

02What I owned

On the frontend I built and enhanced React interfaces for HR workflows, from reusable components to responsive layouts. I owned the authentication and authorization path end to end: JWT-based sessions, protected routes and access control between the UI and the API.

On the server I drove the security hardening: IP-based rate limiting, input validation and SQL-injection prevention aligned with the OWASP Top 10, plus the structured error handling and centralised logging that made incidents traceable. I also owned validation of the auth and REST API modules across functional, edge-case, integration and regression scenarios.

03Defence in depth

No single control is trusted to stop an attacker. A request is throttled, authenticated, validated and authorised before it reaches a query, and each layer logs what it rejects. Treating security as a pipeline rather than a checklist made it easier to reason about, and to test.

Fig. 01

Client
React appProtected routes
Edge
IP rate limitingJWT verification
Handler
Input validationRole and access checks
Data
Injection-safe queriesSecurity and app logs
Fig. 01 Request path: every layer can reject, and every rejection is logged

04Working flow

The request-level path behind a sign-in and every authenticated call after it. Each check runs before the next layer is touched.

Fig. 02

User
React app
API
Database

  1. 01 Submits credentials

  2. 02 Sends the sign-in request

  3. 03 IP rate limit, then input validation

  4. 04 Looks up the user with an injection-safe query

  5. 05 User record

  6. 06 Verifies credentials, issues a JWT, logs the outcome

  7. 07 JWT

  8. 08 Calls a protected endpoint with the token

  9. 09 Verifies the JWT and checks role and access

  10. 10 Authorised data, or a logged rejection

Fig. 02 Sign-in, then token-gated requests

05Hard parts

  • Adding security controls to a live product without breaking existing user flows.
  • Tuning rate limits to stop brute force without punishing legitimate users.
  • Replacing ad-hoc failures with structured errors and centralised logs the whole team could read.
  • Working asynchronously with a US team, where written context replaced hallway conversations.
  • Keeping releases free of critical regressions while security changes touched shared code.

06Outcomes

  • Mean time to debug production incidents down roughly 35%.
  • Zero critical regressions across 6 consecutive sprint releases.
  • Authentication and API security aligned with the OWASP Top 10.
  • Auth and REST API modules validated across functional, edge-case, integration and regression scenarios.

07How I approached it

  1. 01

    Assume any layer can fail

    Defence in depth means one missed check isn't a breach.

  2. 02

    Logs are a feature

    If production can't tell you what went wrong, the system isn't finished.

  3. 03

    Test the unhappy paths

    Edge cases and abuse are where auth code breaks.

  4. 04

    Write it down

    Remote work across timezones runs on clear written context.

End of case study7 sections

Related work

More projects
Back to all projects