Every US-first HR incumbent ships mobile as a reduced subset of the real thing. Emplora on Android is the same product. Same fourteen modules, same Copilot, same permissions, wrapped in a shell that behaves like a native app rather than a web page in a frame.
Six pain points, grouped from review corpora and industry surveys. They are not independent, each one compounds the next.
Research across eight HR platforms found the same pattern: mobile ships as a reduced companion. You can check a balance and approve a request, then you hit a wall and are told to open a laptop. Darwinbox displaced SAP and Workday in Indian conglomerates largely because it did not do this, which is the clearest proof available that mobile parity wins deals.
Two of the three user populations are phone-first. The line manager approves between meetings; the employee has no desktop at all. Both are the users the category serves worst, and 82% of HR-tech rollouts report adoption failure, concentrated exactly there.
So mobile parity became a strategic wedge rather than a delivery detail: identical capability on Android and web, from one codebase, with the phone getting its own layouts instead of a reflowed desktop.
Everyone in the category ships an app. Almost nobody ships the product. Read this table as capability on a phone, not "is there an icon on the home screen".
| On a phone, can you… | BambooHR | Rippling | Darwinbox | Emplora |
|---|---|---|---|---|
| Approve leave & view your own record | ✓ | ✓ | ✓ | ✓ |
| Open the full org chart and reach every node | ~ | ~ | ✓ | ✓ |
| Run analytics and see comp-band outliers | , | ~ | ~ | ✓ |
| Read explainable attrition risk per person | , | , | ~ | ✓ |
| Bulk-import a roster from a spreadsheet | , | , | , | ✓ |
| Ask an AI assistant in plain language | , | ~ | ~ | ✓ |
| Get an answer with no network connection | , | , | , | ✓ |
The gap that falls out of this: the upper-right quadrant of depth versus self-serve is empty. Darwinbox has the depth but needs a sales cycle; BambooHR has the ease but hits a ceiling around a hundred people. Nobody occupies both, which is the 50-500 "graduation gap", and Emplora's beachhead.
Five roles that appear in every 50-500 person company, synthesised from review corpora and industry surveys. Two of them buy; all five live with the result.
The flow the whole product exists to make possible: a 60-day warning that ends in a specific action assigned to a specific person, not a chart.
Four decisions shaped the Android build. The first set the ambition; the rest are what that ambition costs once you leave the browser.
env(safe-area-inset-*) to element height rather than padding inside it.md, tables become card lists, the org chart becomes an
indented tree, short stat tiles go 2-up, and rows with actions stack identity above buttons instead of
sharing a wrapping flex line.Native feel is not one big thing. It is a
finite list of small betrayals, each of which has a fix. All of it is scoped to
html[data-native], which the app shell sets only under Capacitor, so the browser build keeps
normal browser behaviour.
Extracted from Figma via the Figma MCP server and built on Untitled UI primitives. These are the published variables, not approximations of them. The phone inherits the same tokens; only the layout rules change.
Role-adaptive rather than role-gated: one route, three compositions. A promotion changes what Marcus sees without changing where he goes, which matters more on a phone, where there is no sidebar to re-learn.
The mobile build in grey, which is where the cramped screens show themselves.
A desktop HR layout does not become a mobile one by getting narrower. These studies are where the dashboard lost its tile grid and the employee record stopped trying to show every field at once. Grey makes a cramped screen obvious in a way a polished one hides.
Five destinations in the tab bar, the full tree behind More, and a dashboard that recomposes for your role rather than gating you out of it. Nothing here is a mobile-only screen, it is the web app, laid out for a thumb.
This is a design and engineering concept running on demo data, so these are build facts rather than adoption numbers. What the Android app can actually do, verified against the same test suite as the web build.
Design and build were the same loop on this project, so the toolkit spans both.
Five phases, each producing a document the next one is accountable to. The point of writing them down was that later decisions could be checked against earlier reasoning instead of relitigated.
Eight-platform teardown, BambooHR, Rippling, Deel, Zoho People, Darwinbox, Keka, Gusto, Workday, scored on price, real strength and where each one breaks. Positioned the depth/self-serve quadrant and found the empty corner.
Deliverable: market sizing, feature parity matrix, six ranked pain points, four strategic wedges.
Empathy maps for the three daily roles, five field observations, a problem statement, five point-of-view statements, and a How-Might-We set grouped by consolidation, agency, adoption, mobile and trust. Concepts scored on impact × feasibility.
Deliverable: five personas with feature traceability, prioritisation matrix, seven success metrics with baselines and targets.
Organised by employee lifecycle rather than by internal department, under three rules: every screen is a view onto one record; depth capped at three levels for zero-recall; and every node reachable by typing, so hierarchy never becomes a memory test.
Deliverable: sitemap, desktop/tablet/mobile nav models, RBAC matrix, URL scheme, content model, five key flows.
Tokens pulled from Figma through the MCP server rather than transcribed by hand. Colour, type, spacing, radii and the Untitled UI skeuomorphic button ring, which is what stops the buttons reading as flat. Motion specified as a named vocabulary so no component invents its own easing.
Deliverable: token spec, component inventory (primitives, composites, shell), motion spec, accessibility baseline: AA body text, 44px targets, reduced-motion honoured globally.
One Next.js codebase, statically exported and wrapped in Capacitor for Android. Authorisation enforced by Postgres RLS rather than application code, so a query the app never wrote still cannot leak another tenant's roster.
Deliverable: live web app, Android build, 18 RLS checks signed in as real users, 58 end-to-end API checks, deployment runbook.
Asked whether the product would survive procurement at Samsung or Google scale and answered it against the repository rather than from memory. The finding that mattered was not a missing feature: the roster silently truncated at 1,000 rows, so past that point the product displayed a smaller company than the one that existed, with no error anywhere. Reproduced on a throwaway tenant of 1,200 employees before anything was changed.
Deliverable: readiness audit with measured payloads, a prioritised fix list, paging with truncation detection, throttled auth endpoints, and a written decision not to build AI resume screening or individual performance prediction.
TypeError: Failed to fetch. The fix was as much diagnostic as technical: the boot screen now shows the compiled-in API address, the app's own origin, and a button that tests the connection. Error messages are interface."I went into the Android build expecting the hard part to be layout, and it wasn't. Shrinking a dashboard is a solved problem. The hard part was everything the browser does for free that an app is not supposed to do. The overscroll, the selection highlight, the tab bar drifting over the keyboard. None of it is in a spec, and users can't name any of it, but they feel all of it within about four seconds. Writing that list down was the most useful thing I did on this project, because it turned an unwinnable vibe into nine tickets. The parity decision was the other one: committing to zero cut features before designing anything meant I never got to negotiate my way out of a difficult screen."