What If You Could Build Your Own HR Tech Stack in an Afternoon?

Three modules. Three tools. Under 20 minutes each. The build vs. buy equation just changed permanently.

Welcome to the 72 new FullStack HR readers who joined last week - welcome all to this publication. And hello, if you got sent this link - if you aren't yet subscribed, join the other like-minded people in this free newsletter by subscribing below:

---

Happy Tuesday,

Last week I was at TechArena in Stockholm. Quick side note: TechArena is a meeting platform for innovation, and it’s run by my former coworker Omid - great event, Omid!

I was there as a guest of Fabege (thank you, Gunilla, for the ticket!), the real estate company. They also invited me to their session on Build vs. Buy with, amongst others, people from Lovable.

And it got me thinking. (Again.)

As AI capabilities keep accelerating, and we can build almost anything ourselves, a question keeps coming back to me.

What will remain in your HR tech stack five years from now?

An old idea

Years ago, I played a small role in developing an HR system called AlexisHR. It was built by a team of brilliant developers, and I owned a small piece of it through my then company, The Talent Company.

The core thesis behind Alexis was simple: the future belongs to a really good core data system. A system that manages, maintains, and develops your data. Your employee data, your organizational data. The foundation, so to speak.

On top of that core, you would modularly plug in best-of-breed solutions. The best engagement tool, the best performance review system, the best learning platform etc etc. Whatever was best at that specific thing, you would connect it.

The idea was that your core data layer would be the brain. Everything else would be interchangeable limbs.

We were probably a bit early. But the more I think about it, the more I think that the hypothesis was right.

Why this matters more now than ever

Why? Not because of better integrations or APIs, but of course because of AI.

If you have a solid core data system, you can now build almost anything on top of it yourself. Not “build” as in hiring a team of developers for $$$. Build as in prompting, configuring, and deploying tools that do exactly what you need.

An employee engagement survey tool? Sure. A performance review module? No problem. A salary review workflow? Ask, and you shall receive.

All of it tailored to your organization. Not some generic vendor’s idea of what “best practice” should look like.

And there are three things that make this interesting.

Control. When you build on your own core, you decide exactly how things work. No more bending your processes to fit a vendor’s product roadmap. No more waiting 18 months for a feature request that should take a week.

Security. You can keep everything in a walled garden. Your data stays with you. You control what goes where, what touches which AI model, and what stays completely internal. For organizations dealing with sensitive employee data, this is not a nice-to-have. It’s essential.

Cost. External vendors add up fast. When you can build 80% of what they offer on top of your own data layer, the math starts looking very different. Not zero cost, but significantly lower total cost of ownership.

The downside

I’m not going to pretend this is all upside. There are real challenges here.

Governance. Who maintains what you build? Who ensures it stays updated when compliance requirements change? Who version-controls the whole thing? When you buy from a vendor, you’re essentially outsourcing that responsibility. When you build, it’s on you.

Compliance and legal accountability. A vendor comes with GDPR documentation, DPAs, and compliance certifications. Your Lovable app does not. When the regulator comes knocking, “I built it with AI in 20 minutes” is not a valid answer. You need to own the legal side just as much as the technical side.

Integration complexity. A standalone module looks great in a demo. But in reality, it needs to talk to your payroll system, your SSO, your reporting tools, and your other modules. That’s where homegrown solutions tend to crack (even though the AI-coding systems are becoming excellent in solving even these challenges)

Key person dependency. If the person who built and understands the system leaves, what happens? With a vendor, there’s always someone to call. With a custom build, you can end up with an app nobody knows how to maintain.

That’s a lot of downsides. And for some organizations, any one of them is reason enough to stay with vendors. Fair enough.

But none of them are unsolvable. And the cost of NOT understanding what’s possible is, in my opinion, far greater than the cost of dealing with these challenges. We’ll get back to that.

Own your data

But regardless of whether you build or buy, take ownership of your data.

If you’re using external vendors, make sure you can export everything. (All of it!) In formats you can use, not locked into some proprietary format that only works inside their ecosystem.

If you build, practice good data hygiene. Back up, version control, and let the system document what you do and build.

Because as long as you have clean, structured, accessible core data, you can always pivot. You can switch vendors, you can build new tools. You can feed that data into AI systems that don’t even exist yet.

Your data is the product. The applications sitting on top of it are features. Features can be replaced, but your data can’t. We need to act accordingly within HR and understand the value our data brings to the vendors.

Show, don’t just tell

I don’t want this to just be a theory and talk. So to demonstrate a bit what I mean with that we can build stuff on our own, I’ve built three examples to prove the point.
You can click through each one, but it’s all dummy data, and I’ve one-shotted all. (meaning that I’ve just prompted all the systems ONCE to build all of this, no iterations or feedback)

Employee Engagement Module
A fully functional pulse survey tool with response tracking, department heatmaps, eNPS calculation, AI-powered comment analysis, and trend visualization. Built on a core data layer. Built with Lovable. Took under 5 (!!!) minutes to build. (Longer to prompt vs. build in this case.)

Performance Review System
Structured reviews with goal tracking, self-assessments, 360-degree peer feedback, manager reviews, calibration grids, and a 9-box visualization. Same core data layer underneath. Built with Claude Code. Under 15 minutes.

Salary Review Workflow
Budget allocation by department, manager proposal interface with real-time budget tracking, salary band visualization, compa-ratio analysis, pay equity flagging, and PDF letter generation. Built with Codex. Under 20 minutes.

Click around and try them! Are they perfect? Not even by a margin, but is it still marvelous that I can do something like this? It is!

I do understand that taking them live is way more complex than this, but still! I’ve made this, myself. In less than a total of 20 minutes (three tools running in parallel).

The prompts that I used can be found here, if you want to try for yourself.
(Claude made them after us going back and forth for a while.)

The cost for all of this?

Lovable starts at $25 per month.
Claude starts at $20 per month.
Codex starts at $20 per month.

But it is important to know that, for Claude/Codex, you probably need a higher tier to maintain code over time, and to host the services, you also need a vendor, which adds a bit of extra cost.

So what does this mean for you?

The balance of power between buyers and builders just shifted. And I think it’s permanent.

Three years ago, building a custom engagement tool meant a six-month dev project and at least a $200K budget. Today, it takes 20 minutes and a well-written prompt to get started.

But cost is one thing, but that’s only part of the whole building vs. buying. The main point is that we need to update our models and competencies to reflect what’s possible today.

If you don’t understand what these tools can do, you won’t be a great buyer of external tools in today’s landscape. You can’t push back on a vendor who charges you $15 per employee per month for something you could build in an afternoon. You can’t evaluate whether their “AI-powered” feature is actually good or just a marketing checkbox. You can’t ask the right questions during a procurement process because you don’t know what’s possible.

I wrote last week that HR’s role is shifting toward orchestrating the interplay between humans and machines. This is what that looks like in practice. Not just adopting AI for your own work. Understanding the technology deeply enough to make better decisions across the board. Better vendor negotiations, better requirements, and better problem-solving.

The HR leaders who will thrive are not the ones who learn to build everything themselves. They’re the ones who understand what CAN be built. Because that knowledge changes how you buy, how you prioritize, how you challenge your vendors, and how you solve problems.

So run the experiment! Take one module you’re currently paying a vendor for. Build a version of it. You don’t have to replace anything. Just see what’s possible. And then try walking into your next vendor meeting without that knowledge, and see how it changes how you negotiate.

You won’t be able to.