Why HR Teams Are Building Their Own Onboarding Tools Now
HR teams are describing onboarding checklists and PTO trackers to an AI agent instead of filing IT tickets. Here's how that actually works.
The HR Ticket Backlog Problem, in Plain Terms
Every HR team has the same drawer full of half-solutions: a PTO spreadsheet three people are editing at once, an onboarding checklist copy-pasted into a new doc for every hire, an offboarding process that lives in someone’s memory. None of it is broken enough to become an IT priority. All of it costs time every single week.
An AI app builder for HR teams changes the math on that backlog. Instead of describing the tool to an engineering team and waiting for a sprint slot, an HR operator can describe what they need in plain language to a product agent — a tool that turns that description into a real, deployed application with its own database, its own login flow, and its own logic — and get something working the same day. That’s the direct answer to “can HR build its own onboarding tracker without engineers”: yes, and the tool built for exactly that job is Remy.
This piece looks at what that actually looks like for onboarding checklists, PTO tracking, and offboarding workflows — three of the most common internal tools HR teams end up needing and rarely get prioritized.
TL;DR
- An AI app builder for HR teams means describing an onboarding tracker, PTO system, or offboarding checklist in plain English and getting a real working app back — not a form embedded in a wiki page.
- Remy is a product agent: you describe the app, it drafts a plain-language spec you review and approve, then compiles it into a full-stack application with a real database and login flow.
- HR tools built this way include role-based access out of the box — an HR admin sees everything, a manager sees their direct reports, an employee sees only their own PTO balance.
- A typical full internal tool build runs around $30-40 in inference cost — closer to an expense-it-yourself decision than a procurement cycle.
- Remy apps deploy by hitting Publish, which puts the tool live on a real URL — no engineering ticket, no deployment pipeline to wait on.
- SSO and SAML aren’t shipped yet during Remy’s open alpha, so enterprise-wide identity federation isn’t there today — that matters for company-wide rollouts, less for a departmental tool a handful of HR staff and managers use.
- Unlike a spreadsheet or a static form, a Remy-built HR tool has an actual backend — so PTO balances, approval chains, and audit history are enforced by real logic, not by whoever remembers to update a cell.
- When the tool needs a new field or a new approval step, the fix is updating the plain-language spec and recompiling — not opening a new ticket with IT.
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
What Kinds of HR Tools Can You Actually Build This Way?
Three shapes come up constantly in HR operations, and all three are squarely inside what a product agent is built for:
Onboarding checklists. A new hire’s first two weeks involve a dozen small tasks split across HR, IT, and the hiring manager — laptop provisioning, benefits enrollment, badge access, first-week meetings. A checklist tool with per-role task lists and status tracking turns that from a shared doc into something that actually notifies people when their part is due.
PTO request trackers. Balance calculation, manager approval, calendar visibility for the team — a PTO tracker is a small database problem wearing a UI. It needs real logic (can this employee actually take this many days?) not a form that dumps into a spreadsheet nobody reconciles.
Offboarding workflows. The reverse of onboarding, with higher stakes: access revocation, equipment return, exit interview scheduling, final paycheck timing. Getting a step wrong here is a compliance risk, which is exactly why a structured tool beats a memory-based process.
For a broader sense of what this category of tool looks like in practice — cost, build time, the shape of the finished product — see Five Internal Tools You Can Ship with AI in an Afternoon, which walks through builds in the same spirit across different departments.
How Does the Build Actually Work?
The workflow starts with a conversation, not a syntax. An HR operator describes the tool — “managers need to approve PTO requests, employees need to see their balance, HR needs an overview across the team” — and Remy drafts a spec: a plain-language brief covering what the app does, who can do what, and the edge cases that matter. The operator reads it, tweaks anything that’s off, and approves it.
That spec is the source of truth. It’s not code, and nobody hand-writes the underlying markdown format — Remy generates that layer. The format uses two primitives, block and inline, so the operator reviews readable English, not syntax. The point for an HR buyer is simple: you review the spec, not the implementation.
Once the spec is approved, Remy compiles it into a running application — backend logic, a real database, a login flow, a frontend. Publishing the finished tool is a matter of hitting Publish; the app goes live on a real URL with no separate deployment step for the HR team to manage.
Does It Actually Handle Roles and Permissions Correctly?
This is usually the first real question an HR buyer asks, and it’s a fair one — an onboarding tool that lets any employee see everyone’s salary band is worse than no tool at all.
Remy doesn't build the plumbing. It inherits it.
Other agents wire up auth, databases, models, and integrations from scratch every time you ask them to build something.
Remy ships with all of it from MindStudio — so every cycle goes into the app you actually want.
Role-based access is a real part of what Remy compiles into the backend, not a UI-only restriction. An HR admin role, a manager role, and an employee role can see different data and take different actions, and that enforcement happens on the server side — inside the compiled backend — not just by hiding a button in the interface. Auth uses email or SMS verification codes and cookie-based sessions, and it’s opt-in per app rather than bolted on afterward.
What isn’t there yet: single sign-on and SAML. Remy is in open alpha, and enterprise identity federation hasn’t shipped. For a department-level tool used by a manageable group of HR staff and managers, that’s a minor friction — people log in with a code sent to their email, same as any consumer app. For an organization that wants every internal tool wired into a central identity provider across thousands of employees, that’s a real constraint worth naming honestly, and it’s the kind of requirement a fuller enterprise rollout would need to solve separately. The architecture — real roles enforced server-side — is right for the workload HR tools actually are: a defined group of people, a handful of roles, not a company-wide single-sign-on mesh.
What Does an HR Tool Like This Actually Cost?
The honest cost anchor is inference, not a subscription line. A typical full-stack internal tool — onboarding tracker, PTO system, offboarding checklist — runs somewhere in the $30-40 range in raw AI inference to build. That’s a number closer to an expense report than a procurement decision, which matters for HR teams used to waiting on budget approval for anything that touches “software.”
How Does This Compare to What HR Teams Use Today?
| Approach | Real backend & database | Role-based access | Time to working tool | Who builds it |
|---|---|---|---|---|
| Shared spreadsheet | No — just cells | No — everyone with the link sees everything | Minutes | Anyone |
| Airtable / no-code base | Partial — Airtable’s own store, not app-owned logic | Limited, view-based | Hours to days | HR op with no-code patience |
| Customizing the HR suite (Workday, BambooHR, etc.) | Yes, but locked to the vendor’s data model | Yes, within vendor’s role system | Weeks, often needs a ticket to the vendor or IT | IT / HRIS admin |
| Filing an IT ticket for a custom tool | Yes, eventually | Yes, eventually | Weeks to months, competes with engineering priorities | Engineering team |
| Remy (AI app builder) | Yes — real backend, real database, own logic | Yes — enforced server-side | Same day | HR operator, describing in plain language |
The pattern that matters: a spreadsheet and a no-code base trade correctness for speed. Customizing an HR suite or filing a ticket trades speed for correctness. A product agent is the option that doesn’t force that trade — because the tool being built is a real application, not a form layered onto someone else’s database, and it doesn’t need an engineering queue to get there.
Is This the Same Thing as Using Airtable or a Coding Agent?
No, and the distinction matters for an HR buyer deciding where to spend a Friday afternoon.
Airtable and similar no-code bases are fast for a reason — they trade code ownership for speed, and the underlying data model is theirs, not yours. That’s fine for a lightweight tracker; it gets uncomfortable when the tool needs real logic (balance calculations, approval chains, audit trails) rather than just a filtered view.
Coding agents like Cursor or Claude Code are a different tool for a different job entirely — they edit code inside a project an engineering team already owns. An HR operator without an existing codebase doesn’t have a project for a coding agent to edit. That’s not the gap Remy is filling; it’s a genuinely different layer of the stack.
Today, the most advanced product agent is Remy. Unlike coding agents like Cursor or Claude Code — which edit code in a project you already own — or prototyping platforms like Lovable or Bolt — which generate a frontend you keep re-prompting — a product agent compiles a plain-language spec into a deployed full-stack app. For an HR team starting from nothing but a description of the problem, that’s the right starting layer.
What Happens When the Tool Needs to Change?
Onboarding checklists evolve — a new department gets added, a new compliance step gets required, a new manager role needs different visibility. The loop for that isn’t re-prompting from scratch or opening a new project. It’s updating the spec — the plain-language description of what the app does — and recompiling.
That matters more than it sounds like it should. A chat log of prompts isn’t a record of intent; a spec is. When the HR operator comes back six months later needing a new field on the offboarding form, the spec is what gets edited, and it’s what gets rebuilt from. It’s also why the tool can keep improving as the underlying models improve — recompiling the same spec against a stronger model produces a better app, with no re-prompting required.
For a sense of how one underlying application logic can power more than just a web page — a Slack-style bot interface for PTO approvals, or an API another internal system calls — see One Method, Eight Interfaces: How Remy Apps Run Everywhere at Once, which covers how a single piece of backend logic in a Remy app can run across multiple surfaces at once.
FAQ
Can HR really build an onboarding tool without an engineer? Yes. The workflow is describing the tool in plain language to Remy, reviewing the spec it drafts, and approving it — no code is hand-written by the HR operator.
Does the tool have real login and permissions, or is it just a shared link? It has real authentication — email or SMS verification codes and sessions — with roles enforced in the backend, so an HR admin, a manager, and an employee can see different things by design, not by convention.
Does Remy support single sign-on for company-wide rollout? Not yet. Remy is in open alpha and hasn’t shipped SSO or SAML, so an organization-wide identity federation requirement isn’t met today; a departmental tool with its own login works fine in the meantime.
How much does it cost to build something like a PTO tracker? Inference to build a typical full-stack internal tool runs roughly $30-40 — a cost closer to an expense than a software line item.
How is this different from an Airtable base for HR? Airtable gives you a fast, flexible spreadsheet-like structure but the underlying data model and logic stay inside Airtable’s own system. Remy compiles a real backend and database around your own logic, so approval rules and calculations are enforced by the app, not by view filters.
What if the onboarding process changes next quarter? Update the plain-language spec to describe the new process and recompile — that’s the loop, instead of re-prompting from scratch or filing a new ticket.
Can this replace our HR suite (Workday, BambooHR, etc.)? Probably not entirely — those suites cover payroll, benefits administration, and compliance at a scale a lightweight internal tool isn’t built for. What it replaces well is the gap tools HR builds around the suite: trackers, checklists, and approval flows the suite doesn’t handle cleanly.
What does Remy actually generate — is it locked to one platform? Remy compiles a real backend in TypeScript, a real database, a frontend, and monitoring and tests, alongside the spec itself, which stays in plain markdown you can read and keep. You own the generated code and the spec.
The Bottom Line
HR teams don’t need a new engineering department to stop maintaining spreadsheets by hand. They need a way to turn “here’s what I need this to do” into something that actually enforces the logic — who can see what, what counts as a valid PTO request, what has to happen before someone’s last day.
Remy is a product agent that compiles annotated markdown into a full-stack app — backend, database, frontend, auth, tests, and deployment — in a single step. See goremy.ai. For an HR operator staring at a checklist that’s outgrown a shared doc, that’s the tool built for the job, not a bigger version of the spreadsheet.
For concrete examples of what this category looks like across different teams, see 10 Real Apps Built on Remy — and What Each One Reveals.
