Claude and ChatGPT can build almost any HR tool now. So why buy?

Any People Ops leader can now build an HR tool in an afternoon.

A benefits chatbot, a policy assistant, a form that drafts its own responses. All of it is within reach of someone who has never written a line of production code. Claude, Copilot and ChatGPT have moved fast enough that the technical barrier most teams worried about two years ago has mostly fallen away.

So the interesting question is no longer whether you can build. It is what happens after you have.

Building is the easy part now

The models have caught up faster than most people expected. Johannes Sundlo, who writes the Full-Stack HR newsletter and has worked with more than 200 organizations on AI transformation, put it plainly: the technical limits keep shrinking.

One of his early tests was whether ChatGPT could build a coherent staff schedule for 14 people that respected local employment law. It couldn't. Eighteen months later, it can.

He has since built his own applicant tracking system, live and taking real candidates, in something like ten hours. It runs an AI screening interview, stores applications, and does the job of an ATS. On his own admission, it took closer to fifteen hours if you ask his wife.

The building is no longer the hard part. Which is exactly why it is the wrong thing to fixate on.

Can you tell whether what you built is any good?

"I can build it for sure. But is it good? I have no clue, because I'm not a developer. I can't verify what I build."

That gap matters more in HR than almost anywhere else.

A marketing page that renders slightly wrong is embarrassing.

A benefits eligibility tool that quietly returns the wrong answer touches someone's healthcare, their pay, their right to work. You can generate the tool in an afternoon and still have no reliable way to know it handles the edge cases correctly. And that's a challenge.

Who maintains it after you've moved on?

Software doesn't stop needing attention the day you ship it. Models change, policies change, and the person who built the thing eventually leaves.

The question Johannes keeps returning to is longevity. Yes, you can build it. How will you maintain it? Who owns it once you're gone? What happens when it breaks and the one person who understood it has moved to another company?

For most People teams, the honest answer is that maintenance falls to an IT department that is already partnering with revenue, product and engineering. Building the thing was close to free. Keeping it alive is not, and it rarely sits on the People team's own roadmap.

When something goes wrong, can you show what happened?

When a foundational model makes a decision inside a hiring process or a performance review, you are working with a non-deterministic system. It can take a slightly different path each time.

So ask the harder version of the question. If you end up in front of a court, and the court asks you to produce the record of what happened, can you pull that ledger out of Claude or ChatGPT? In many cases, you can't.

"Governance turns out to be the ceiling, not the technology."

As Johannes framed it "the biggest limitation today is usually what your organization allows you to do with the models, not what the models can do."

That holds for good reason. You are handling proprietary and personal data, and "it's stored safely" is a promise you have to take on trust.

Three questions decide whether a build is worth keeping:

• Can you verify it works, edge cases included, without being the developer who wrote it?
• Can someone maintain it after the person who built it has moved on?
• Can you produce an auditable record of what it did when someone asks?

Why it stopped being build versus buy

The instinct is to treat this as a fork. Build it in-house, or buy from a vendor. The more useful framing from the session was that it isn't either/or.

You have to build to understand what is possible. Experimenting internally is how you learn where the limits sit, which use cases matter, and what you would even be asking a vendor to solve. As Jeet Mukerji put it, it is no longer build versus buy, because one informs the other.

The teams getting this right experiment first, then bring in a partner for the parts that need to last: the maintenance, the escalation path for when the AI can't answer, the reporting on what it resolved and where it failed, and the audit trail underneath all of it.

Kinfolk's hot tip: Build to learn the shape of the problem. Buy for the parts that need governance, auditability and someone accountable when it breaks. A model can surface an answer in Slack, but a maintained platform is what gives you the record, the escalation path and the reporting when a routine request turns into a formal one.

What's next

Start building. It is the fastest way to understand what these models can and can't do for your team, and you will make sharper decisions for having tried.

Just go in knowing that the afternoon it takes to build something is not the cost. The cost is everything that comes after: proving it works, keeping it running, and being able to show what it did.

Answer those three before you decide what to keep in-house and what to hand to someone whose job is to maintain it.