Case study
AuxHR
Returned to an abandoned hiring platform at Salesplat, stabilised the frontend, and rebuilt recruiter workflows until the product could be used for hiring again.
- Top
- public contributor, AuxHR frontend repo
- Live
- auxhr.com, used by the hiring team
- Recruiter UI: Applicants table, score ring, screening answers and assessment thread.
- App state: Holds application data and polls while a match verdict is pending.
- AuxHR API: Backend that stores applications and screening answers.
- AI match: Generated once per application. The UI shows the score when the verdict lands.


Context
AuxHR is Salesplat’s AI hiring product. Recruiters post roles, candidates apply, and the system scores fit, runs screening, and moves people through a hiring pipeline. I worked on it during my full-time tenure at Salesplat (Jan 2023 – Mar 2024) and later returned to bring the abandoned project back to an operational state.
Problem
The original frontend had been left in a state the hiring team could not depend on. Recruiter flows around applicants, screening, and match scoring were incomplete or unreliable. The job was not a greenfield rewrite. It was to take ownership of an existing Vite/React codebase, make it stable, and ship the workflows a hiring team actually needs.
My role
I am a top public contributor on the AuxHR frontend (Salesplatpro/frontend). The work covered recruiter-facing hiring UI, application state, screening, and the surrounding UX: loading, empty, and error states, form validation, and layout. I did not claim the whole product — the repository has several contributors — but I owned the revival of the recruiter product surface.
Challenge
Stabilising an existing hiring app means inheriting architecture decisions, incomplete recruiter flows, and a dual audience (recruiters and talent). Changes had to land without breaking apply-wizard or auth paths. Match scoring is asynchronous, so the UI has to poll and remain honest while a verdict is pending.
Approach
The later work focused on the hiring loop: keep the applicants table usable, show CV match percentage on the score ring, load screening answers from the application payload, poll while a match verdict is pending, generate AI match once instead of letting recruiters regenerate endlessly, and present assessment answers as a decision thread. Alongside that: focus the first invalid field after a failed submit, share profile-completion errors with the form, and tighten dashboard layout and loading states.
Outcome
The product is live at auxhr.com. Salesplat markets AuxHR as its hiring platform. I later returned, stabilised the abandoned project, and brought recruiter workflows to a point where the hiring team could use the platform operationally. That operational use is my account of the outcome, not an independently audited usage metric.
Decisions
Stabilise the existing stack
The app is Vite, React, TypeScript, Tailwind, Material UI, Sass, and Redux. Replacing it would have delayed hiring. The decision was to keep the stack and make the recruiter product reliable inside it.
Poll pending match verdicts
AI matching is not instant. Rather than blocking the recruiter on a spinner with no feedback, the UI polls the application while a verdict is pending and then shows the score.
Generate match once
Removing recruiter regenerate reduced noisy re-runs of the AI match. One generated verdict, then a decision. That is slower to “play with” and easier to trust in a hiring workflow.
What shipped
Applicants and match scoring
Recruiter applicants table, CV match percentage on the score ring, and a single generated AI match rather than repeated regenerate actions.
Screening and assessment
Screening answers loaded from the application payload, polling while a match verdict is pending, and assessment answers shown as a chat-style decision thread.
Form and dashboard reliability
Focus the first invalid field after a failed submit, surface profile-completion errors on the form, and keep dashboard loading and layout states usable.
Stack
React · TypeScript · Vite · Tailwind CSS · Material UI · Sass · Redux
This was ownership of an existing system: pick it up, make the hiring loop work, and leave the team with a product they can run — not a demo of a new stack.