Manan Arora
← All projectsProduct · mobile · lead developer

Field HRMS

The company’s HR system only worked on a desktop, and many of its people worked remotely or on site. I led a team of four to rebuild it as a mobile app that field staff actually use.

Role
Founder & Lead Developer
Client
A telecom equipment manufacturer
Timeline
Jan – Jul 2024
Team
Me, 1 UX designer, 2 front-end devs
Stack
Flutter · BLoC · Hive
Home screen
HomeClock in, today’s tasks and leave balance, the first thing you see.
Clock-in screen
Clock-inPick office or on tour, then a guided selfie.
Selfie check screen
Selfie checkConfirm the photo is clear before it’s logged.
Manager inbox screen
Manager inboxRequests sorted by type, approve or reject in one tap.
Company calendar screen
Company calendarHolidays, events and birthdays in one shared place.
Real outputScreens from the shipped app. Scroll sideways, or use the arrows.
01Problem

“Everything needs to be handled on the go”

Remote and on-site employees didn’t have laptops, but attendance, leave, travel and expenses all lived in a desktop HR system. So staff sent photos to their managers as proof of attendance, managers verified them by hand, and urgent requests waited until someone got back to a desk.

Managers had a second worry: without verification, people could log attendance they hadn’t earned. And employees kept their daily task lists in the Notes app, one more place to check.

02Product process

Before writing code, find out what people actually do

  1. 01Stakeholder interviewsSponsor, field staff, managers and HR: what worked, what didn’t, what was in scope.
  2. 02Map the desktop systemWalked every existing workflow so the mobile app kept what already worked.
  3. 03BenchmarkStudied leading HR apps: key actions on the home screen, a shared calendar.
  4. 04ReframeHow might we make attendance easy for remote staff while avoiding false logs?
  5. 05Design → test → shipTwo-week sprints: design, evaluate with users, build and deploy.
How we scoped the product, working with our UX designer.
03One feature, two versions

Selfie attendance, and what testing changed

v1 · photo proof, built into the appVersion 1: clock in, take a selfie, confirm, done
v2 · after evaluationVersion 2: choose office or on tour, with selfie guidance
04Architecture

Six modules, one structure

The codebase follows Clean Architecture: every module (attendance, leave, travel, expenses, employee, events) has the same three layers, so features could be built in parallel and new ones follow a known path.

PresentationFlutter UI · BLoC / Cubit
attendanceemployeeeventsexpensesleavetravel
Domainpure Dart, no Flutter
entitiesuse casesrepository interfaces
Datamodels · repositories
REST API clientHive offline cacheshared preferences
Each feature module follows the same three layers. Dependencies are wired with get_it.

Why Flutter: one codebase for iOS and Android with a small team. Why Hive: field sites have patchy signal, so profile data is cached on the device and the app stays usable offline.

05Outcome

Shipped, and still growing

400+employees at launchJuly 2024
1000+internal usersas of February 2026
~30%fewer disputed or incorrect attendance entriesbefore vs after launch

What I took away: keep what already works. The biggest wins came from moving existing workflows to the phone faithfully, then fixing the few that hurt, not from redesigning everything.

Need someone who can talk to users and ship the app? Let’s talk.

Email meLinkedIn ↗GitHub ↗Résumé ↗