SaaSERPPM + DesignCRM

HeiGin

An HR and finance ERP that two pilots turned into a CRM — and the access model that survived the pivot.

Role: Product Manager & UX Designer
Timeline: 2025 · solo
Platform: Web, mobile-first
Status: Built and piloted. Not launched — pivoted to CRM after two pilots.

// the problem

Repetitive people operations — or so we thought

HeiGin set out to consolidate HR, payroll, recruitment, finance, and employee self-service into one workspace for the Indian market, benchmarked against Keka. The thesis was clean: growing businesses pour energy into repetitive people operations, so automate that and free HR for the work that needs judgment.

I started from zero — no brief, no designs, no existing system — and delivered a working system across six modules and eight roles. The thesis felt obvious. It was also wrong, and two pilot companies were about to prove it.

// my role

PM and designer, from thesis to pivot

I owned the product and the design. I defined the MVP scope and cut what did not belong, wrote the role architecture and permission model from first principles, mapped every journey across six modules and eight roles, designed all screens and states, and built the design system from scratch.

The hardest decisions here were not visual. They were product decisions — about access, about sequence, and about when to stop.

System architecture: AI layer on top, six modules in the middle, shared employee data spine below, immutable foundation at the base — The architecture that scoping decision produced: six modules on one shared data spine, not six separate systems bolted together.

// the hardest decision

An access model built on separation of duties

The design problem in an HR and finance ERP is not the screens — it is who can see and do what. Salary data, payroll runs, and personal records cannot sit behind one admin toggle.

So the access model is built on separation of duties. The person who edits salaries cannot run payroll. The person who runs payroll cannot open employee profiles. Roles are not assigned by hand — they are implicit, derived from a person’s place in the org chart. And every privileged action lands in an audit log the Global Admin cannot edit.

RBAC diagram: Global Admin sits above three separate permission groups — People operations, Payroll, and Finance — with implicit roles assigned by org-chart position below — The access model, mapped: the person who edits salaries cannot run payroll, and the person who runs payroll cannot open employee profiles.

// what I rejected

The HR thesis itself

We scoped HeiGin as an HR and payroll system and built six modules around that thesis. Two pilot companies killed it. Neither cared about attendance logging or leave marking — those weren’t the expensive problems. Both wanted a CRM that worked properly at a lower price point than they were being quoted. So we stopped, and I rewrote the product: PRD, user flows, sitemap, and user stories for CRM. The access model and the onboarding engine survived the pivot, because they were about trust and data rather than about HR.

Killing your own thesis after building six modules around it is the expensive kind of judgment call. Shipping more of the wrong product would have cost more.

// the work

Six modules, and the CRM that replaced them

The HR build covered Core HR, payroll, recruitment and onboarding, leave and attendance, finance and expenses, and employee self-service — across eight roles, each screen scoped to what its viewer is allowed to see.

The CRM screens are designed, and the PRD, flows, sitemap and user stories are written. heigin.com lists the CRM as planned — the clearest evidence of the product half of the work, not just the design half.

HeiGin HR manager dashboard overview — The HR dashboard. The command centre for an HR manager’s day — every figure scoped to what their role is allowed to see.

Employee roster view with search and filter controls — The roster a manager works from day to day, scoped the same way as everything else — to what their role is allowed to see.

One record for the full employee lifecycle, each tab gated by the separation-of-duties model rather than a single permission flag.

Onboarding flow across HR side, Candidate side, and System swim lanes — Recruitment and onboarding, mapped step by step — who does what, and when the system takes over from a person.

Document engine logic: HR sets Required, Optional, or Do Not Ask per document type, producing different onboarding experiences for full-time engineers, contractors, and interns — One rule set producing three different onboarding experiences — full-time engineers, contractors, interns — instead of three separate flows to maintain.

Goals and OKRs tracking screen showing individual and team objectives — Part of the same six-module surface — a manager sets and reviews goals without leaving the tool the rest of the team already lives in.

CRM dashboard — pipeline, revenue, win rate (designed, not shipped)

The CRM the pilots actually wanted, on the same access model and data spine. Designed and specced; listed as planned on heigin.com.

// outcome

Built, piloted, pivoted

HeiGin was built and piloted with two companies. It was never launched — the pilots redirected the whole product toward CRM, and that is where the work went next.

No analytics were in place at pilot, so the honest measure is not a dashboard number — it is the invalidation itself: two pilots, one clear signal, and a product that changed course before it shipped the wrong thing. If I were instrumenting the CRM now, the first number I would want is how many quotes it wins against the incumbents on price.