Onboarding at 300,000-business scale
Three years on an HR and payroll platform serving more than 300,000 businesses and 2.5 million employees. The work I keep pointing at is the digital onboarding checklist, which cut organization setup time in half.
Platform context
300,000+
businesses
Employment Hero platform, 2022 to 2025
2.5M+
employees
Employment Hero platform, 2022 to 2025
My part
I built the digital onboarding checklist, paused and resumed rather than restarted, and worked on the UI standardization effort.
Outcome
-50%
setup time
Employment Hero, internal figure, 2022 to 2025
50+
inconsistencies resolved
Employment Hero, 2022 to 2025
Problem
Setting up a new organization on an HR platform is a long, branching task with real consequences for getting it wrong. It spans company details, people, payroll settings, and compliance, and it is usually done once by someone who has never done it before.
Anything that long tends to be abandoned in the middle, and an abandoned setup is an account that never becomes a customer.
Constraints
The platform serves more than 300,000 businesses, so the flow has to hold up across wildly different company sizes and configurations rather than a happy path.
The interface had drifted. Similar controls behaved differently in different corners of the product, which made every new flow more expensive to build than it should have been.
What I did
I built the digital onboarding checklist: a multi step flow with validation and state that survives interruption, so setup can be paused and resumed instead of restarted. Organization setup time came down 50%.
In parallel I worked on the UI standardization effort, resolving more than 50 inconsistencies across the product and documenting the results in Storybook so the fixes held.
I owned Webpack and build tooling, and worked on CI and test reliability, which is the unglamorous half of making a large frontend safe to change.
On mobile I worked on the React Native app: two factor authentication, biometric login, and a cross platform carousel.
Decisions
| Decision | Why | What I rejected | What it cost |
|---|---|---|---|
| Leave the existing lock logic in place and add a second version beside it, behind a feature flag | The in place rewrite merged and had to be reverted a day later. A second version running alongside could change behaviour for new organizations without changing it for the ones already set up. | Recursion with cycle detection. The second version drops the visited set for a flat lookup with two explicit rules, trading correctness in graph theory terms for something readable that does not move existing behaviour. | The source of truth did not change. Dependencies still arrive as a flat array of codes and the client rebuilds the graph on every render. Treating an unrecognized code as already complete is deliberate fail open, so a customer is never blocked by it, at the cost of not noticing bad data. A lock state changed on the server still only appears on the next fetch. |
Details that mattered
Standardization work is easy to undersell because the output is an absence: fewer surprises, fewer one off components, fewer decisions per feature. It is also the work that made the onboarding flow cheap to build.
Pricing page iterations came from conversion data rather than opinion, which is the habit I kept when I started running my own products and had to own the funnel myself.