What happens when you stop buying onboarding software and build it instead?

Onboarding is the process every organisation says it wants to fix, and almost nobody does.

Ask any HR team what needs attention and it will be in the top three. I know, because I have been asking those questions since 2024!

Ask when they last changed it properly and the answer is usually a redesign that stalled, a portal that nobody logs into, or a welcome pack that was updated in 2022 and still refers to a building the company no longer occupies.

This is not a competence problem. It is a constraint problem because it goes to the bottom of the pile when there are 1001 other things to do, or you dont have time to investigate a platform that can do all the things for you. But the constraint has just quietly disappeared.

Last week I built a working, interactive onboarding platform in about ten minutes. No developer. No budget approval. No IT ticket. The full outcome is in the video below - its a very simple visual so imagine what could be done when it's scoped out properly.

I built this in lovable but you can do something similar using Copilot and connecting it to a couple of other tools.

The platform is not the point of this article. What it makes possible is.

Why onboarding never actually gets fixed

Think about what improving onboarding has meant for most of your career.

Somebody notices new starters are having a poor first month or, if they do, they wait until the stats tells them something is very wrong. Typically what happens is HR gathers evidence. They build a business case, because anything with a system attached needs one. The business case goes into a prioritisation process where it competes against payroll, against the HRIS upgrade, against whatever the finance director cares about this quarter.

If it survives, there are vendor demos. Procurement. Security review. Implementation planning. A phased rollout.

Somewhere around month seven, the person who wanted the change has moved roles, and the energy has quietly gone with them.

We have all lived some version of this. Most of the time, HR don't even get to the vendor selection because it's not seen as a priority. There are many other things that the leadership team think are more important. Or HR never gets the budget to implement something.

And over time it trains a very particular instinct into HR: learn to tell the difference between problems worth the fight and problems you simply live with.

That instinct was rational and something I have experienced so many times before.

When every improvement cost twelve months and a six figure sum, choosing your battles was good judgement.

The trouble is that the instinct has outlived the constraint that created it.

What actually changed

When I built that onboarding platform, the interesting number was not ten minutes. It was zero. Zero business case, zero vendors, zero procurement, zero developers.

That changes the economics of trying something.

When an experiment costs a year, you have to be right before you start. You need certainty, sign-off and a plan. When an experiment costs an afternoon, you can find out by building it. You can put a rough version in front of three new starters, watch where they get stuck, and rebuild it on Friday.

That is a different way of working, not just a faster one. HR has spent decades specifying requirements for other people to build. The skill in front of us now is prototyping: making a rough version of the thing so you can see whether the idea was any good.

Most AI conversations in HR are still about tools. This is not about tools. It is about which constraints you are still designing around out of habit.

What good onboarding could actually look like

Once building becomes cheap, you can stop asking what your system allows and start asking what a new starter actually needs. Those are very different questions, and most onboarding processes are answers to the first one.

A new starter needs to know what happens on day one, and what happens in week six. They need one place to look rather than four emails, a shared drive folder and a manager who is on annual leave. They need the information to arrive when it becomes relevant, not all of it on the first morning. They need to be able to ask a question at nine o'clock at night without feeling like they are being a nuisance. They need their manager to be prompted at the right moments, because most poor onboarding is not a bad process, it is a busy manager with no reminders.

None of that requires an enterprise platform. Almost all of it is content, sequencing and prompting, which is exactly the kind of thing you can now build and test yourself.

How to approach it: REWORK™ applied to onboarding

Building something is the easy part now. Building the right thing still takes method. This is how REWORK™ applies to an onboarding redesign.

Review. Map what actually happens to a new starter, hour by hour for the first day and week by week for the first three months. Not the process on paper. The real one, including the bits people work around. Talk to someone who joined in the last quarter, because they are the only people who remember it accurately.

Eliminate. Before you build anything, take things out. Most onboarding is bloated with content that exists because somebody once asked for it. If a document has not been opened by a new starter in a year, it is not onboarding, it is archaeology.

Workflow. Redesign the sequence around the new starter's questions rather than the organisation's departments. The order in which HR, IT, Facilities and the line manager want to talk to someone is almost never the order in which a new person needs to hear from them.

Optimise with AI. Now build it. This is where a tool like Lovable earns its place, turning your redesigned workflow into something interactive in an afternoon rather than a quarter. Build the roughest version that a real person could use, then put it in front of a real person.

Roll Out. Start with one team, one cohort, one month. A prototype used by five new starters will teach you more than a steering group will.

Keep Evolving. The advantage of building it yourself is that changing it costs an hour rather than a change request. Use that. Onboarding should be different in six months, because you will have learned something.

The order matters. If you jump straight to Optimise with AI, you will build a fast, attractive version of a process nobody liked in the first place.

The part that needs care

I would not be doing my job as a HR practitioner if I let this sound frictionless.

Something you build in ten minutes is a prototype, not a production system. That distinction matters enormously in HR, because our processes touch personal data and employment decisions.

Before anything you build goes near a real new starter, you need clear answers on a few things. What data does it hold, and where does that data physically live. Whether personal data goes into it at all, and if so, who signed that off and under what lawful basis. How it connects, or deliberately does not connect, to your HRIS. Who owns it when you are on holiday, and who maintains it when you leave. Whether IT and Information Security know it exists.

That last one is not bureaucracy. The fastest way to lose your credibility, and the right to build anything else, is for a shadow system to appear on the network without anyone knowing.

My strong recommendation for a first build is to use no personal data at all. Build the content, the sequencing and the experience. Prove the idea. Then have the governance conversation with something concrete in your hand, which is a far better conversation than one that starts with a proposal.

The bigger question

Here is what I actually want you to take from that ten minute build.

For thirty years, HR has been on the wrong side of a bargain. We understood the work better than anyone in the organisation, and had the least ability to change the systems that shaped it. We wrote requirements documents and waited.

That gap is closing. Not because HR is becoming technical, but because building is becoming less technical. The advantage now sits with the people who understand the work, and that has always been us.

Which means the limiting factor is no longer budget, or IT capacity, or vendor roadmaps. It is whether anyone in the room thinks to ask the question.

Onboarding is simply the obvious place to start. It is contained, it is visible, it is measurable, and everyone already agrees it needs work. But it is one process among dozens sitting in your function right now, all of them shaped by a constraint that no longer applies.

So the question worth taking into your next team meeting is not "should we use AI for onboarding?"

It is this. What have we stopped trying to fix, purely because fixing it has always cost too much?

Answer that honestly, and you will have your first project.

If you want to build the underlying capability rather than watch someone else do it, Rethink:Foundations is the practical starting point for individual practitioners, and Rethink:Team brings a whole HR function to the same standard in a day.

If this is useful, send it to the person in your team who needs it most. Don't just use AI. Rethink the work.