The average company runs 6.17 HR systems across one employee lifecycle. Emplora collapses that into a single employee record, wraps it in a copilot that finishes the work rather than suggesting it, and publishes the price. For the 50-500 companies that have outgrown BambooHR and can't justify Rippling.
Six pain points, grouped from review corpora and industry surveys. They are not independent, each one compounds the next.
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.
Parity on the table stakes is assumed. The rows that decide anything are the bottom five.
| Capability | BambooHR | Rippling | Darwinbox | Zoho | Emplora |
|---|---|---|---|---|---|
| Core HRIS & directory | ✓ | ✓ | ✓ | ✓ | ✓ |
| Integrated payroll | Add-on | ✓ | ✓ | Add-on | ✓ |
| People analytics | Basic | ✓ | ✓ | Basic | Predictive |
| Attrition risk scoring | , | , | ✓ | , | Explainable |
| Agentic task execution | , | Partial | Partial | , | Core |
| Natural-language command bar | , | , | , | , | ✓ |
| Mobile capability parity | , | , | ✓ | , | ✓ |
| Published all-in price | , | , | , | ✓ | ✓ |
| Seat floor | $250/mo | Yes | Yes | None | None |
It is short on HR systems people actually use. 82% of deployments report adoption challenges while 45% of HR leaders lose over half their week to admin, which means the category competes on time-to-value and interface quality, not on module count. Everyone already has the modules.
Plot the eight platforms that matter on depth against self-serve time-to-value and one quadrant is empty. Darwinbox has enterprise depth but needs a sales cycle. BambooHR has the ease but hits a ceiling. Nobody occupies both corners at once.
That gap has a name and a size: the 50-500 graduation gap, where companies resolve their needs by accumulating point solutions. Emplora attacks it with four wedges. One record, agents that close the loop, mobile parity, and a published all-in price.
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.
Drawn from five personas, two of whom sign the contract and three of whom live in the product. Every story traces to a shipped module.
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.
Five decisions, each one a fork where the conventional answer was available and cheaper. Together they are the product.
org_id at the database, salary and engagement are stripped server-side before
serialisation, and one isomorphic permission matrix is imported by both the API that enforces and the
UI that hides./hr, /manager,
/me. Explicit, easy to reason about, and each one optimisable in isolation./dashboard route with three compositions. HR sees org
metrics, status and risk; a manager sees team to-dos, approvals and pulse; an employee sees their
balance, tasks and team.Extracted from Figma through the MCP server
rather than transcribed by eye, and built on Untitled UI primitives. The values below are the real tokens
in globals.css, consumed through Tailwind v4's theme layer.
Accessibility baseline: body text meets WCAG AA, focus is visible on every interactive element, status is never encoded by colour alone, charts expose an accessible table equivalent, and ⌘K is reachable from anywhere with Esc closing every overlay.
Greyscale studies of the same screens, used to argue about hierarchy without anyone discussing colour.
Every one of these screens was settled in grey before it was designed. Stripping colour and type weight out of a layout makes a hierarchy problem impossible to hide behind a nice accent: if the eye does not find the primary action in grey, it was never finding it on merit.
The pattern that kept failing here was the dashboard. In colour it looked organised. In grey the risk widget, the headcount tiles and the employee table all carried the same weight, which is another way of saying the screen had no opinion about what mattered. The version that shipped puts attrition risk above the fold and lets the table be a table.
Navigation is organised by employee lifecycle rather than by internal department. Main, Employee Lifecycle, Administration, because that is how all five personas describe their own work. Every screen is a lens onto the same entity; changing route changes the view, never the source.
Three things arrived after this was first written. Compensation Review, which reads the salary bands and shows where a person sits against their own, so a pay conversation starts from the same number on both sides of the table. A notifications feed, because the bell in the header had been promising one for months. And a demo reset, so a visitor can change anything in the live demo without permanently breaking it for whoever opens it next.
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.
An audit I ran on my own product, and the one finding that mattered more than any feature.
The question I set myself after launch was whether this would survive procurement at a company the size of Samsung or Google. The answer came back uncomfortable, and it had nothing to do with AI. Emplora was quietly showing a truncated company.
The roster was fetched whole on every page load, unpaginated. Supabase caps REST responses at 1,000 rows by default and raises no error when it does. So at 1,001 employees the product did not slow down and it did not fail. It displayed the wrong company with complete confidence: headcount short, payroll totals short, branches missing from the org chart, and nothing anywhere saying so.
I reproduced it rather than reasoning about it. A throwaway tenant with 1,200 employees, queried the way the code did: 1,200 rows in the organisation, 1,000 returned, no error raised. Every number on the dashboard is derived from that array, so every number was wrong.
Paging restored the right answer: the same tenant now returns all 1,200. It also took 3.9 seconds, and that number is its own argument. Fixing the truncation did not fix the design that wants an entire company in the browser so the client can add it up. Aggregates belong in SQL, and that is the next piece of work rather than a thing I am claiming to have finished.
The second half of the audit was less about code. Enterprise buyers do not evaluate AI first: SAML SSO and SCIM provisioning are routinely pass/fail items on the security questionnaire that gates the deal, and automatic deprovisioning gets scrutinised because manual deactivation is a compliance gap auditors ask about directly. The honest consequence is that no amount of AI gets Emplora into Samsung. SSO, SCIM, SOC 2 and data residency do. The AI is what wins the bake-off once procurement has cleared.
Three things I decided not to build. The reasoning is the point: a feature you can ship is not the same as a feature you can defend in front of an HR director.
What the audit left standing is worth saying plainly, because it is the part that survives comparison with Workday or SuccessFactors. Tenant isolation here is enforced by the database rather than by application code, and compensation privacy is a column privilege rather than a hidden field. Most of the market enforces both in the application layer, where one missing clause leaks a roster. Emplora's database refuses. That is a narrow wedge, but it is a real one, and it only matters once the product can hold a real company.
Most of the P0 list has since been closed. What is still open is the procurement work rather than the clever work.
Emplora is a design and engineering concept running on demo data, so these are the success metrics the product was designed against. Each with the baseline it is measured from, rather than adoption results from a customer base.
Portfolio work is usually presented as finished. This is more useful, and more honest, as a ledger.
"The research kept pointing at the same thing from different angles: this category is not short on features, it is short on products people will open. That reframed the whole project. The interesting work wasn't designing fourteen modules, it was deciding that the score has to show its factors, that scope belongs in the database, that the assistant's output has to arrive as a draft, and that the price goes on the landing page. None of those are screens. All of them are the reason the screens work. I also learned to distrust numbers that look fine: the salary-band bug returned a perfectly reasonable 50% for everyone, and it took asking why nothing was ever flagged to notice the signal had been silently deleted."
