This one's protected

This project covers internal work that isn't public. If you'd like to read it, drop me an email at wiryanaw@gmail.com and I'll send you the password.

Incorrect password. Try again.

← Back to home
HRIS Internal Tool 2026

Saved IDR 676M annually by building a custom HRIS for 1,000+ staff across 165+ outlets

Pantry HRIS, Hero
Outcome IDR 676.2M Saved in 2026 Company Hangry Role Product Manager & Designer (End to end product) Timeline Jan – Mar 2026 Team 1 Product Designer, 1 Engineer Scale 1,000+ staff across 165+ outlet locations

I led the end to end design and product management of Pantry, an internally built HRIS that replaced Hangry's third party subscription. By building a system tailored to our operations across 165+ outlets and 1,000+ staff, we eliminated IDR 676.2M in annual vendor costs while gaining full control over our workforce processes.

01 The Problem

The organization faced three compounding issues that made continuing with the existing vendor unsustainable.

Escalating subscription expenses, projected to reach IDR 761 million, a cost that grew with headcount without delivering proportional value
Vendor dependency that limited customization, forcing the operations team to work around the platform rather than with it
Misalignment between platform capabilities and business requirements, resulting in manual workarounds for core HR processes
02 The Solution

We built Pantry, a custom HRIS designed specifically for Hangry's operational structure. Rather than adapting to a generic platform, Pantry was shaped around the workflows our staff and admins already knew, giving us direct control over workforce processes across all outlets.

Live Features
01
Operations user application: Staff can submit requests and access their payslips directly from the app
02
Outlet attendance portal: Real-time clock-in/out with face-matching verification for accurate attendance tracking
03
Administrative platform: Centralized management of shifts, approvals, and workforce data across all locations
03 The Constraints
01
Tight deadline. All 3 platforms had to ship by end of March, roughly 3 months from kickoff. The constraint was hard: the annual license renewal payment was due April 2nd, with no option to extend on a shorter cycle.
02
Lean team. Two people: me covering product management and design, and one engineer responsible for both front and back-end. A large scope for a very small team.
04 The Approach
The platform we replaced

One platform, three surfaces

Before Pantry, Hangry ran on a third party HRIS (Mekari Talenta) that fanned out across three separate surfaces and two very different audiences. Understanding its full shape came first, so the scope of what we would rebuild in house was clear.

3rd party HRIS
Mekari Talenta
Consumer (User) App
Two audiences
HQOperational
Portal (Outlet) App
Shared outlet device
Outlet live attendance
Admin (Web)
Back office
HR and operational PIC teams
The scope

Dozens of features across the stack

The platform spanned three layers of HR, from day to day core operations to strategic tooling. Rebuilding all of it in house was never realistic in the time we had, which made auditing the full surface area essential.

Core HR
HRIS
Employee database, multi branch transfer, announcements, files, document template
Attendance
Live attendance, time off administration, overtime management
Payroll
Calculation, report, disbursement, benefit reimbursement, employee loan
Self service
Payslip, request time off, overtime, and reimbursement
Employee experience
Recruitment
Manpower planning, applicant tracking
Employee mobility
Portal, liveness, on call management
Expense management
Reimbursement, cash advance, business trip planning
Employee benefits
Earned wage access, flexible benefit, flexible installments
Strategic HR
Talent management
Performance review, individual development plan, succession planning
Analytics
Forms+, report builder, Talenta Insight+

40+ features across 3 HR layers, 3 surfaces, and 2 audiences.

The deciding variable

Where the subscription cost actually sat

The clearest signal for what to prioritize was the third party subscription bill. Operational accounts and the outlet portal dominated the annual cost, while HQ was a rounding error by comparison.

OperationalPortal and Ops accounts
IDR 676Mper year
HQHQ accounts
IDR 85Mper year

Operational cost ~8× more than HQ, and carried the heavier day to day reliance.

The tradeoff

Operational first

With cost and reliance both pointing the same way, I made the call: build the operational surfaces and the admin back office first, and defer only the HQ user app to after launch.

Build for go live
Portal AppOperational User AppAdmin (Web)
Highest cost. Operational drove ~IDR 676M per year of the subscription, the bulk of the savings opportunity.
Heaviest reliance. Operational staff depend on the platform daily for live attendance, overtime, and requests.
HQ could wait. HQ users only checked payslips and requested leave, nothing operationally critical, and only ~IDR 85M per year.
The plan to go live

From requirement to live, then improve

With scope set to operational first, this was the P0 plan to reach go live before April. Everything here shipped for launch. The HQ app and deferred features became P1 and P2 after live.

Build
01
Requirement gathering
Portal, Admin, and Operational user app
02
Concept and design
Including reviews with design team and stakeholders
03
Testing
Internal tech testing and user testing
Pre launch
04
Outlet trial
5 outlets, 7 days in the live environment
05
Socialization
All outlets, walkthrough and QnA over Google Meet
06
Live preparation
Validate and migrate all employee data
Launch and stabilize
07
Go live
Migrated to our own HRIS
08
After live monitoring
Watch the live environment closely
09
Improvement and report
Fixes, learnings, and a wrap up report

Every step above was P0, delivered before and around go live. The HQ app and the features we deferred became the P1 and P2 roadmap after launch.

05 The Portal App

The Portal App runs on one shared device per outlet. Any staff member finds their name, confirms their shift, and clocks in with a face scan. It is the most safeguarded surface in the system, because attendance ties directly to payroll.

Built to prevent abuse
Face matching
Verifies the person clocking in is who they claim to be, closing the door on buddy punching.
Location range
Clock-in only works within 100m of the outlet, including a GPS buffer for outlets inside shopping malls.
No clock tricks
Staff sometimes change the device clock to hide a late clock-in. Attendance runs on server time, so it has no effect, and tampering is detected and blocked.
06 The Operational User App

Operational staff use their own phone to request overtime and leave, check payslips, and keep their profile current. The design leaned into the two things they do most, and cut every step we did not have time to build.

A limited selection of screens is shown. The full app is under NDA.

A design decision, backed by data
99.99%
of 3,941 new joiners
Feb 2023 to Nov 2025
Nearly every new joiner already onboarded with a Gmail account. With no time to build user account provisioning before the deadline, Continue with Google removed an entire onboarding step and matched how staff already signed in. One tap, no passwords to manage.
Requests, front and center
Overtime and leave are what staff open the app for, so both sit at the top of the home screen as prominent cards with a direct New Request action.
Self-service profile
Staff view and edit their own personal, employment, and payroll details, cutting the back and forth with HR and keeping data current at the source.
07 The Trial

Before rolling out to 165 outlets, we trialed live attendance at 5 outlets over 5 days, 6 to 10 March. Three ran with geo-fence restrictions, and two warehouses ran without, since warehouse staff are highly mobile.

5outlets · 5-day trial (6 to 10 March)
3 outlets · geo-fence on
2 warehouses · geo-fence off (mobile staff)
What went wrong
76.7%
of valid check-ins out of range
174 of 227 · first two trial days (6 to 7 March)
  • The Operations team had initially defined both the range and the stored coordinates for every outlet.
  • Some ranges were set as low as 1.9 to 2.5m, below what phone GPS can achieve.
  • Several outlet coordinates were themselves inaccurate.
  • With natural GPS drift of 15 to 30m in malls and shophouses, staff standing at the counter were rejected.

Scale risk: with 165 outlets going live end of March, the same misconfiguration would not stay in the trial. It would multiply platform-wide.

Why: GPS accuracy is not fixed

I dug into GPS accuracy and found the error depends heavily on the environment, so a single tiny threshold could never work everywhere.

Open sky / street facing
Street kiosks, open car parks, outdoor counters
Typical GPS error 3 to 10m
Recommended threshold 15 to 25m
Clean signal with good satellite visibility. A 15 to 25m threshold absorbs natural drift while keeping the boundary tight.
Mall / urban block
Ground floor retail, shophouse, dense city block
Typical GPS error 15 to 30m
Recommended threshold 25 to 50m
Concrete walls and nearby buildings cause multipath reflection. Drift of 20 to 30m is common even inside the outlet.
Indoor / basement / upper floor
Mall basement, upper-floor units, enclosed offices
Typical GPS error 30 to 100m
Recommended threshold 50 to 100m
GPS often fails to penetrate fully indoors. Accuracy degrades sharply, needing a larger threshold or Wi-Fi assisted location.
The fix

The rejections had two root causes, so the fix had two parts.

Fix 1 · Data
Correct the coordinates
Rather than relying on the Operations team's data, we asked each outlet to share their live location, then updated the invalid longitude and latitude so the geo-fence centred on the real spot.
Fix 2 · Range
Set a universal range
50mGPS buffer included
One standard for every outlet, applied as a single admin config change. No development, no manager workload. It covers real GPS drift while still requiring staff to be at the outlet.
Validated in the trial
  • With the coordinates corrected, no further complaints about inaccurate locations, and staff could check in successfully 100% of the time.
  • With the 50m range applied, every clock-in fell within range. Of 22 records on 9 March (15:40 to 23:19), the mean was 7.20m, with a minimum of 1.22m and a maximum of 15.19m, all well under the 50m boundary.
08 Results

Pantry went live on April 21st. These are the results captured from launch to date.

IDR 676M Saved annually by replacing the third party HRIS subscription, with recurring benefits every year going forward
100% Success rate in live attendance with face-matching verification