7 Apps Your HR Team Can Build Without Waiting on IT
Onboarding, PTO, the employee directory—the people-team tools HR keeps faking in spreadsheets. Here are seven your team can build itself, without waiting on IT.
Your HR team is already running software—it just lives in spreadsheets, shared inboxes, and an HRIS module nobody fully uses. The work that a people team does every day is workflow-shaped: a new hire moves through onboarding tasks owned by three departments, a leave request routes from employee to manager to a balance that has to be tracked, an interview panel files feedback that someone collates by hand. Those are applications. Most HR orgs fake them in a tab of a spreadsheet because the alternative—filing a ticket and waiting two quarters for IT—is worse. The teams pulling ahead have stopped accepting that trade. They build the seven tools below themselves, without waiting on a backlog, by describing what they need.
That matters because HR holds context no engineer can be briefed into. The person who runs onboarding knows exactly which step gets dropped and which approval always stalls. They should own the tool that fixes it.
TL;DR
- Most HR “apps” already exist as spreadsheets, email threads, and unused HRIS modules—the work is software-shaped, it’s just running on the wrong substrate.
- The right builder for a people-team tool is the HR team itself, because it holds the policy and process context an engineer would have to be briefed on—and lose in translation.
- An onboarding tracker, a leave-request workflow, and an employee directory are the three highest-leverage tools to build first, because each replaces a fragile spreadsheet that everyone depends on and no one trusts.
- Generic HR SaaS underdelivers because it was built for a company that isn’t yours—you pay for eighty features to use eight, and still bolt a spreadsheet onto the gaps.
- Building these tools used to mean waiting on an IT backlog; the teams that win now treat the idea-to-tool gap as days, not quarters.
- Each app on this list replaces something manual or over-configured—the test for what HR should build is “what are we currently doing by hand because the tool doesn’t quite fit?”
- The shift isn’t a productivity hack for one HR generalist—it’s an operating-model change for the people org, which stops queuing for tools and starts shipping them.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
Why is HR the right team to build these?
Because HR owns the workflow end to end, and the workflow is the spec. The person who runs onboarding knows which IT request always gets dropped, which document a new hire can’t start without, and which manager forgets the 30-day check-in. An engineer building that tool has to be told all of it—and what gets told is never quite what gets built. When the team that runs the process builds the tool for the process, the context never leaves the room.
The second reason is volume. HR runs dozens of small, recurring workflows that are individually too minor to justify an engineering ticket but collectively eat days every month. No central queue prioritizes “a better way to track policy acknowledgments” over the product roadmap, so HR opens a spreadsheet. That’s not a failure of HR—it’s a failure of the old build model, where the only people allowed to build were the ones with the longest backlog. It’s the same pattern that makes your operations team your most underused engineering org: the team with the deepest process knowledge stuck in the request line. Each of the seven below replaces a specific manual workaround or an over-configured SaaS tool HR pays for and works around.
7 HR apps to build without waiting on IT
1. Onboarding task tracker
What it does: Turns a new hire’s first 30 days into a tracked, owned workflow—every task, its owner, its due date, and its status—across the three or four departments that touch onboarding. The hiring manager, IT, and the new hire each see exactly what’s done, pending, or overdue.
Why HR should build it: Onboarding is a cross-functional sequence only HR sees whole—which laptop request precedes which system access, which form blocks payroll setup, which check-in lands on day 30. That sequence is institutional knowledge, not a feature request.
What it replaces: A master onboarding spreadsheet copied for each new hire, where “complete” is a cell color and follow-up is a reminder someone set once.
2. PTO and leave-request workflow
What it does: Lets an employee request time off, routes it to the right manager for approval, and tracks the running balance—so HR isn’t reconciling accruals in a spreadsheet or fielding “how many days do I have left?” over email.
Why HR should build it: The accrual rules live in HR’s head—how PTO banks, which leave types deduct from which bucket, what tenure unlocks more days. Encode it once and the policy enforces itself.
What it replaces: A leave module in an HRIS that doesn’t match your accrual policy, propped up by a shared “PTO tracker” spreadsheet HR updates by hand.
3. Employee directory and org chart
What it does: Gives the company one searchable directory—name, role, team, manager, location, start date—plus a live org chart that reflects the actual reporting structure, not a slide someone exported last quarter. Employees self-serve; HR isn’t the lookup desk.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
Why HR should build it: HR defines what the directory should show, who can edit which fields, and how the reporting lines actually run after the last reorg. Those definitions are the whole tool, and they’re HR’s to set.
What it replaces: A directory tab in a spreadsheet, a stale org-chart slide, and a Slack channel where people ask “who owns this?“
4. Interview-feedback collector
What it does: Routes a structured feedback form to each interviewer after a panel, collects scores and notes against the role’s rubric, and shows the hiring committee one consolidated view per candidate—so no decision waits on chasing down the last interviewer.
Why HR should build it: Recruiting owns the rubric, the scorecard fields, and the rule that feedback must land before the debrief. A generic ATS form rarely matches your rubric; the team that runs the loop can model it exactly.
What it replaces: Feedback scattered across email, Slack DMs, and an ATS field people forget to fill in, then copy-pasted into a debrief doc by a recruiter.
5. Headcount and open-req tracker
What it does: Tracks every open requisition, its approval status, its budget, and its pipeline stage—so HR, the hiring manager, and finance read the same number for “how many roles are we filling and what’s approved?” without a weekly export.
Why HR should build it: HR knows the real approval chain for a new req—the budget sign-off, the headcount-plan check, the backfill-vs-new-role distinction. That logic is institutional knowledge a generic ATS pipeline field can’t capture.
What it replaces: A “headcount” spreadsheet maintained alongside whatever the ATS half-tracks, reconciled by hand whenever leadership asks how hiring is tracking against plan.
6. Policy-acknowledgment tracker
What it does: Sends a policy or handbook update to the right group, captures each employee’s acknowledgment with a timestamp, and shows HR at a glance who’s signed and who’s outstanding—so a compliance deadline isn’t a manual chase through inboxes.
Why HR should build it: HR knows which policies require acknowledgment, which roles a given policy applies to, and what the audit needs to show. That mapping is HR’s process, not a vendor’s default settings.
What it replaces: A handbook PDF emailed company-wide, replies HR sorts by hand, and a spreadsheet tracking who clicked “I agree.”
7. Employee-referral pipeline
What it does: Lets employees submit referrals, routes each to the right recruiter, tracks it through the hiring stages, and surfaces when a referral bonus is earned—so a referral doesn’t die in an inbox and a payout doesn’t get missed.
Why HR should build it: HR owns the referral policy—which roles qualify, the bonus tiers, the tenure rule before payout. A tool built around those rules tracks referrals to payment cleanly instead of bouncing them between recruiting and payroll.
What it replaces: A referral form, a recruiter’s mental note, and a spreadsheet someone checks at bonus time.
What these apps replace—at a glance
The pattern across all seven is the same: a workflow HR runs is currently held together by something manual or something that doesn’t fit. The tool replaces the workaround, not the team’s judgment.
| The app | What HR does today | What it replaces |
|---|---|---|
| Onboarding task tracker | Copies a checklist per new hire | Spreadsheet with status colors and reminders |
| PTO and leave workflow | Reconciles accruals by hand | An HRIS module that doesn’t match policy |
| Employee directory | Answers “who owns this?” requests | A stale spreadsheet tab and org-chart slide |
| Interview-feedback collector | Chases the last interviewer | Feedback scattered across email and DMs |
| Headcount and open-req tracker | Exports a hiring report on request | A side spreadsheet to the ATS |
| Policy-acknowledgment tracker | Sorts “I agree” replies by inbox | A PDF blast and a sign-off spreadsheet |
| Employee-referral pipeline | Tracks referrals on memory | A form and a payout spreadsheet |
Why hasn’t HR just built these already?
Because until recently, building any of them meant one of two bad options. Option one: file a ticket with IT and wait. Internal people-team tools almost never beat the product roadmap or the security queue, so the request sits in a backlog for quarters, and HR goes back to the spreadsheet to get through the quarter. Option two: buy an HR SaaS product that does roughly this, discover it was built for a company that isn’t yours, pay for the eighty features you don’t use to get the eight you do, and still bolt a spreadsheet onto the parts that don’t fit.
A newer option looked promising and mostly wasn’t: hand HR an AI coding assistant. Tools like GitHub Copilot, Cursor, and Claude Code are genuinely excellent—for engineers. They operate at the code layer and assume you can read, write, and debug what they produce. Pointing them at an HR generalist doesn’t remove the barrier to building; it just relocates it from “wait on IT” to “now you debug TypeScript.” That’s a layer mismatch, not a knock on the tools. The people team doesn’t want to write code—it wants the tool that the code produces.
How an HR team actually ships one of these
This is where the list stops being aspirational. The reason HR can build these seven without waiting on IT—not file tickets for them—is a new category of AI tool called a product agent: software that takes a plain-language description of an app and compiles a real, deployed full-stack application from it, rather than a prototype or a screenshot. Today the most advanced one is Remy.
The workflow fits how HR already works. Someone describes the tool—“a new hire’s tasks route to IT, the manager, and payroll; each owner marks their step done; HR sees every hire’s onboarding status.” Remy drafts that description into a plan in plain language—the spec, essentially the brief you’d hand a developer, except an AI compiler builds from it. The HR lead reads it, corrects the task sequence, and approves it. Remy compiles it into a working app: a real backend, a database, real server-side authentication with actual roles (an HR admin can see every record and edit policy; an employee only sees and submits their own requests), a frontend, and a live URL. A typical full-stack build runs about $30–40 in inference. When the policy changes, you edit the plan and recompile—you don’t hand-maintain code.
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
This is a different layer than the coding assistants above. Unlike coding agents like Cursor or Claude Code—which edit code in a project you already own and assume engineering skill—a product agent compiles a plain-language spec into a deployed full-stack app, no code-reading required (here’s how a product agent differs from a coding agent). It’s also worth being straight about where this is: Remy is in open alpha, and enterprise needs like SSO and SAML aren’t there yet. For the seven internal HR tools above, the fit is right now; the roles are real—an employee and an HR admin genuinely see and do different things—the data is yours, and the spec is the source of truth your team controls.
FAQ
What kinds of apps can an HR team build without engineers? Workflow and tracking tools: an onboarding task tracker, a PTO and leave-request workflow, an employee directory and org chart, an interview-feedback collector, a headcount and open-req tracker, a policy-acknowledgment tracker, and an employee-referral pipeline. These are workflows HR already runs by hand or in spreadsheets, which makes them ideal to rebuild as real apps.
Do these apps replace our HRIS or payroll system? No. They replace the spreadsheets and shared inboxes that fill the gaps around your system of record—the onboarding routing, leave requests, acknowledgment tracking, and referral steps your HRIS doesn’t model the way your team works.
Why should HR build these instead of IT? Because HR holds the workflow context—the accrual rules, the onboarding sequence, the policies that need acknowledgment—that an engineer would have to be briefed on and would likely get wrong in translation. HR building for HR keeps that context in the room.
Is this just giving everyone an AI coding tool? No. Coding assistants like Copilot and Cursor operate at the code layer and assume engineering skill, so pointing them at HR staff relocates the barrier rather than removing it. A product agent operates at the product layer—you describe the app, it compiles the code—so no one on the HR team writes or debugs code.
How much does it cost to build one of these apps? With a product agent, a typical full-stack build runs about $30–40 in inference. That’s the cost to compile the described app into a real backend, database, auth, frontend, and deployment.
Are these real applications or prototypes? Real applications—each is compiled with a real backend, a database, server-side authentication and roles, a frontend, and a live URL. Roles are enforced server-side, so an employee and an HR admin genuinely see and do different things.
How do these apps handle sensitive employee data? Each app ships with real server-side authentication and roles, so access is enforced in the backend rather than hidden in the UI—an employee sees only their own records, an HR admin sees the full set. Note that Remy is in open alpha and enterprise sign-on like SSO and SAML isn’t available yet, so match the tool to internal tools rather than your most regulated systems for now.
What happens when our policy changes? You edit the plain-language plan and recompile. The spec is the source of truth, so a policy change—a new accrual rule, an added onboarding step—is a description edit, not a code-maintenance project.
The bottom line
HR is already building software; it’s just trapped in spreadsheets and email because the only people allowed to build used to be the ones with the longest backlog. The seven tools above—the onboarding tracker, leave requests, the employee directory, interview feedback, headcount, policy acknowledgments, and referrals—are workflows your team understands better than anyone and can now build directly. The operating-model change is the point: HR stops queuing for tools and starts shipping them.
One coffee. One working app.
You bring the idea. Remy manages the project.
If you want to see what describing one of these and getting a real app back looks like, explore Remy →. For the bigger picture, read 7 apps your finance team can build and why your best engineers don’t work in engineering.
