The HR Builder’s Guide

There’s a version of this story at every company, and it usually starts the same way. Someone in HR — a TA partner, a People Ops manager, an HRBP who’s been doing this for a decade — notices the same problem coming up over and over. Employees asking the same leave question. Hiring managers writing interview guides from scratch every single time. A policy document that answers 80% of questions but nobody reads because it’s twelve pages of legalese.

They know exactly what would fix it. They could describe the solution in two sentences. They’ve watched the problem happen fifty times; they understand it better than anyone in the building.

Then they do the thing HR has always done next: they open a ticket.

Six weeks later, someone from IT schedules a discovery call. Eight weeks after that, there’s a scoping document. By the time anything ships — if anything ships — the original problem has changed shape, the person who requested it has moved teams, and the tool that gets built solves last quarter’s version of the issue.

This isn’t a story about IT being slow. IT is usually understaffed, juggling priorities that have nothing to do with HR, and rationally putting “build a tool for the leave calculator problem” behind “keep the payroll system from falling over.” The bottleneck was never effort or intelligence. It was access. HR has always had more understanding of its own problems than anyone else in the company — and, until recently, zero ability to act on that understanding without going through someone else.

That’s the part that changed. Not “AI got smarter.” Something more specific: the distance between understanding a problem and building the fix for it collapsed. A few years ago, closing that gap required years of training, a computer science degree, or a very patient friend who owed you a favor. Today it requires being able to describe, in plain language, what you want a piece of software to do — and having the judgment to know if what comes back is actually right.

That second part isn’t small. It’s the entire reason this guide exists.

The mindset shift, stated plainly

Historically, HR consumed software. Someone else decided what the ATS could do, what fields the HRIS tracked, what the onboarding portal looked like. HR’s job was to work within those decisions — to file the ticket, request the feature, wait, and adapt.

Today, HR can create software. Not “HR can now use AI tools better.” Create. A calculator, a generator, a structured process — built by the person who understands the problem, without a procurement cycle in between.

This is not a small upgrade to how HR uses technology. It’s a different relationship to it entirely. And most HR professionals haven’t been told this is available to them yet, which is a strange thing to sit with, because it’s not a secret — it’s just new enough that permission hasn’t caught up to capability.

Before this guide teaches you how to build anything, it needs to talk you out of building some things. This is the chapter most guides skip, because “here’s how powerful this tool is” sells better than “here’s when you shouldn’t use it.” But the HR builders who last are the ones who ask this question first, every time.

Here’s a test that holds up well in practice: build software for problems that are recurring, structured, and annoying. Don’t build software for problems that are rare, judgment-heavy, or better solved by a conversation.

Walk through it with a real example. Say employees keep asking about parental leave. Is this a good candidate for software?

• Recurring? Yes — it comes up every month, from different people, with the same underlying questions.
• Structured? Yes — the inputs are consistent (tenure, province, salary) and the logic, while detailed, is rule-based rather than judgment-based.
• Better solved by a conversation? No — a calculator gives a consistent, accurate answer faster than a conversation would, and it doesn’t require someone’s emotional bandwidth every time.

Now try a different one: a manager wants software to help decide whether to terminate an underperforming employee. Recurring? Sort of. Structured? Not really — every situation has context that doesn’t reduce to inputs and outputs. Better solved by a conversation? Absolutely — this is exactly the kind of decision that needs a human with full context, not a tool that outputs a recommendation with false confidence.

The second example is not a hypothetical worry. It’s the most common mistake in this entire space, common enough that it gets its own heading in Chapter 8: automating judgment that was never meant to be automated.

A decision framework you can actually use

Notice that “is this technically possible to build” isn’t on the list. Almost everything is technically possible to build now. That’s exactly why this question matters more than it used to — the constraint used to be capability, and now it’s judgment.

Builders — good ones, the kind who ship things that last — see problems differently than the rest of us. It’s worth naming the difference explicitly, because it’s learnable, and because HR professionals already have more of it than they usually give themselves credit for.

Builders think in systems, not incidents. When a hiring manager complains about a bad candidate experience, most people hear a complaint about one candidate. A builder hears: what’s the underlying process that produced this, and how many other candidates hit the same thing without complaining? That’s not coincidentally how good HR process design already works — you’ve been doing this all along, just without calling it “systems thinking.”

Builders separate “what should happen” from “how it happens.” This is the single most useful mental habit in this entire guide. Before you describe a tool to an AI builder, you need to be able to describe what it should do completely separately from how it will do it technically. “When someone submits a leave request, check their tenure against the policy table and show them their eligible weeks” is a “what.” You don’t need to know how a database query works to specify that clearly — and specifying it clearly is 80% of the actual job.

Builders expect to be wrong on the first try, and build for that. The urge to get it perfect before showing anyone kills more first projects than any technical limitation does. A builder ships something rough to three people, watches where they get confused, and treats that confusion as the most valuable data in the whole project — more valuable than anything they could have guessed sitting alone.

Builders know the difference between a demo and a dependency. Anyone can make something look finished in an afternoon. The judgment is in knowing the difference between “this is ready to show someone” and “this is ready for someone to actually rely on” — and not confusing the two, especially under deadline pressure. We’ll come back to this distinction constantly through this guide, because it’s the one that actually protects people.

How engineers think vs. how product managers think — and why you need both hats

If you’ve ever worked with a development team, you’ve probably noticed the two rhythms in the room. Engineers ask: what happens in the edge case? What if this field is empty? What if two people submit at the same time? Product managers ask: does this solve the actual problem? Is this the right thing to build at all, before we worry about how?

As an HR builder, you don’t get to hand either of these off. You are the product manager by default — you understand the actual problem better than any tool does. But you also need enough of the engineer’s instinct to ask “what happens when this goes wrong” before you ship something, because nobody else in the room is going to ask it for you the way a trained engineer would.

The good news: you don’t need to become an engineer to borrow that instinct. You need one habit — before you consider anything “done,” ask what happens when someone gives it bad input, uses it from a different province, or clicks the button twice. That single habit closes most of the gap.

The best HR-built tools rarely start with “I want to build something.” They start with a much smaller, more annoying feeling: I’ve explained this exact thing for the fifth time this month.

That feeling is the raw material. Most HR professionals sit on years of it without noticing, because it’s disguised as normal work rather than as an opportunity. Here’s how to go looking for it deliberately.

Look at what you repeat, not what you’re proud of. The instinct is to build the impressive thing — a sophisticated performance review system, a comprehensive career framework. The better first project is almost always the boring, repeated thing: the same three questions in every offboarding conversation, the same eligibility check, the same “let me pull up the policy” moment. Boring and repeated beats impressive and rare, every time, for a first build.

Notice what only lives in your head. If the honest answer to “where’s the documentation for this” is “it’s kind of just in my head,” that’s not a documentation gap. That’s a product opportunity. The Parental Leave Builder, for instance, didn’t start as an ambitious product vision — it started as knowledge that existed in one person’s head, repeated one conversation at a time, that was worth turning into something anyone could use without booking time on a calendar.

Watch what breaks under scale, not what breaks under stress. A process that works fine for a team of ten often quietly breaks at fifty, not because anything dramatic happened, but because the informal, verbal version of the process — “just ask Sarah” — stops working once there’s no longer one Sarah who knows everyone. That’s usually the moment a good tool idea becomes obvious.

Ask what a new hire would find insane. People who’ve been at a company for years stop noticing its weird workarounds. Someone three weeks in still sees them clearly. If you can, ask a recent hire what part of the HR process confused them most — the answer is usually a better product brief than anything you’d come up with alone.

You don’t need to understand any of this the way an engineer does. You need to understand it well enough to have an informed conversation about what you’re building — the same way you don’t need to understand payroll tax law to know that Payroll needs to be involved before you change a compensation structure.

Here’s the stack, translated.

Claude Code — your senior engineer. This is the tool that actually writes and maintains the code. You describe what you want in plain language — “add a section that asks qualifying questions before the main interview starts” — and it plans the work, writes it, and tests it. Think of it the way you’d think of a strong senior hire: you don’t need to check their syntax, but you absolutely still need to review their work, ask clarifying questions, and catch it when it’s confidently gone in the wrong direction. A great senior engineer still needs a manager. This is that relationship.

Supabase — your filing cabinet and HRIS, combined. This is where the actual data lives — candidate submissions, saved calculator results, policy answers. Think of it as a filing cabinet with a very important lock on the drawer. The lock is the part that matters: Supabase includes a setting called Row Level Security that decides who is allowed to open which drawer. Leave that lock unset, and every drawer is effectively unlocked for anyone who finds the cabinet — which is a bigger deal here than it would be with an actual filing cabinet, because “anyone who finds it” means anyone on the internet, not just anyone who walks into the room. We’ll come back to exactly why this matters in Chapter 9.

GitHub — your version history. Every HR system worth its salt keeps a record of what changed and when — an audit trail for policy documents, a version history for the handbook. GitHub is that, for code. Every change is saved, timestamped, and reversible. If Claude Code makes a change that breaks something, GitHub is how you (or it) can go back to the version that worked.

Vercel — your operations team. Once something is built, it needs to actually run somewhere people can reach it — reliably, quickly, without falling over the moment more than one person uses it at once. Vercel is the team that keeps the lights on: it takes the code, puts it on the internet at a real address, and — usefully — gives you a separate “preview” version every time you make a change, so you can test something before it replaces what your whole team is currently using. That preview-versus-live distinction is the same instinct as testing a policy change with one department before rolling it out company-wide.

Clerk — your reception desk. Somebody needs to check who’s allowed in before they get to the data. Clerk (and tools like it) handles logins, passwords, and “is this actually who they say they are” — the reception desk of your application, so you don’t have to build that from scratch.

Resend — your mailroom. When your tool needs to send an email — a confirmation, a notification, a policy summary — Resend (or a similar service) is the mailroom that actually delivers it, reliably, without ending up in spam.

PostHog — your HR analytics dashboard. Once a tool is live, you’ll want to know if people are actually using it, where they get stuck, and what they click before giving up. PostHog is the equivalent of the reporting dashboard you already use to track time-to-fill or offer-acceptance rate — except it’s tracking how people move through the tool you built.

Stripe — your payroll system. If you ever charge for something you’ve built (a paid tier of a tool, a subscription), Stripe is the infrastructure that actually moves the money safely, the same way payroll infrastructure moves salary payments without you needing to understand the banking rails underneath.

None of these tools require you to understand their internals. They require you to understand what job each one does, well enough to ask a good question when something’s not working — the same relationship you already have with your benefits broker or your payroll provider.

This chapter deserves its own space, because the quality of what you build depends less on the tool than on how well you brief it — the same way the quality of work from a great new hire depends heavily on how clearly you set expectations in their first week.

The difference between a bad prompt and a good one

A bad prompt describes a feeling. A good prompt describes a decision.

This tells Claude Code that something is wrong without telling it what “better” means, what a phone screen currently lacks, or what a good outcome looks like. It will guess — and it will guess based on generic assumptions, not your actual process.

Notice what the second version does that the first doesn’t: it names the exact feature, where it lives in the existing tool, what the two parts are and why they’re different, and — critically — it flags the exact trap (hardcoded jurisdiction) before Claude Code has a chance to fall into it. You’re not just describing the feature. You’re describing the mistake you don’t want, because you already know where the mistake tends to happen.

A repeatable structure for briefing a build

A great example

Here’s a realistic first prompt for building a small piece of the Parental Leave Builder:

Notice the last line. Building that instruction into the brief, every time, is a habit worth having before you ever need Chapter 9’s warnings to sink in the hard way.

Theory only goes so far. Here’s what building three real tools actually looked like — what each one solves, the decisions behind how it was built, and what actually shipped.

Some of these will feel obvious once named. That’s the point — most mistakes in this space aren’t complicated, they’re just invisible until someone points at them.

This chapter is not here to scare you out of building. It’s here because the data an HR tool touches — names, salaries, immigration status, health-related leave details — is exactly the kind of information that has, repeatedly and publicly, ended up exposed by AI-built applications that worked perfectly well from the outside. The goal here is the same as any good HR training: understand exactly what goes wrong and why, so you can prevent it, not just feel generally cautious about it.

What actually happened, documented

Independent security researchers have tracked this pattern closely through 2025 and 2026, and it’s worth understanding the specifics rather than a vague sense that “AI-built apps can be risky.”

A widely used AI app-building platform had a documented, publicly tracked vulnerability where applications it generated connected to a database with a critical security setting — Row Level Security — left off by default. Row Level Security is the setting that decides which rows of a database a given user is actually allowed to see. Without it, the “key” that a web application uses to talk to its own database is often visible in the app’s public code — which is normally fine, because Row Level Security is supposed to be the actual gatekeeper. When that gatekeeper isn’t configured, that visible key becomes a master key. Security researchers identified well over 170 live, public applications exposing their full user databases this way — real names, emails, and in some cases far more sensitive information — to anyone who found the app’s web address, no password required.

A separate, well-documented case involved an application built almost entirely through AI prompts, whose founder stated publicly that he hadn’t written a single line of code himself. Within three days of the app going live, security researchers found its production database exposed — including authentication tokens and tens of thousands of email addresses. The root cause was the same missing setting.

In another documented case, a platform that asked users to upload a selfie and a government ID at signup stored those uploads in cloud storage that anyone could read without logging in. Tens of thousands of images — including a meaningful number of driver’s licenses and passports — were pulled from that storage and posted publicly before anyone at the company noticed.

Why this keeps happening. In every one of these cases, the application worked exactly as intended for its actual users. The setting that would have prevented all three incidents is invisible unless you specifically go looking for it. Fast-building AI tools are optimized to get you a working demo quickly, and security configuration is exactly the kind of step that’s easy to skip when nothing in the interface is flashing a warning at you.

How HR builders actually avoid this

None of the following requires you to become a security expert. It requires a short, repeatable checklist, run every time before real data goes anywhere near a tool you’ve built.

Not a roadmap. A source of ideas — a reminder of the range of things “HR builder” can actually mean.

Hiring & Talent Acquisition (5)

Onboarding, Policy & Employee Experience (9)

Compensation, Compliance & High-Stakes Builds (6)

A pattern worth noticing across these cards: the ones tagged in coral — flagged “careful security,” “high care,” or “rule-based only” — are exactly where Chapter 8’s warning about automating judgment applies most directly. Keep that distinction in mind before you pick your next project, not after.