An internal tool for employee onboarding, scoped to day one

Every company that has hired more than about six people has an onboarding process, and almost none of them can show it to you. It exists as a folder somebody made, a WhatsApp thread, and a manager's memory of what went wrong last time. It works well enough at four hires a year and falls apart at twenty, usually without anyone deciding it has.

The instinct at that point is to buy an HR suite. Sometimes that is right. But an internal tool for employee onboarding is a narrower thing than an HR suite, it solves a different problem, and the two get confused often enough that companies buy the wrong one and stay frustrated. This note is about what the narrow thing actually has to do.

Onboarding is a handover problem, not a paperwork problem

The paperwork is the visible part and the easy part. Contract signed, ID collected, bank details recorded, laptop issued. Those are tasks with a clear finish line, and a spreadsheet handles them adequately for a long time.

What breaks is the handover. A new starter needs access to six systems, an introduction to four people, and an answer to the question of what they are supposed to produce in the first month. Each of those depends on somebody else doing something, and none of them has a natural deadline. So they slip, quietly, and the new hire spends two weeks being politely unproductive while nobody is quite sure whose job it was.

That is the problem the tool exists to solve: not storing the paperwork, but making an unowned task visible before it costs a fortnight.

The three things the tool has to hold

Strip out everything optional and an onboarding tool is three fields repeated: a task, an owner, and a piece of evidence that it happened.

• The task, written as something a person does rather than a state to reach. "Grant CRM access" is a task. "Fully onboarded" is not.
• The owner, a named person and not a department. IT is not an owner. The queue with no name in it is exactly the queue that stalls.
• The evidence, which is the part usually left out. A tick box records an opinion. A link to the created account, the signed document, or the calendar invite records a fact, and it is the difference between a checklist you trust and one you re-verify by hand.

Add a due date relative to the start date rather than an absolute one, because the template has to survive being reused, and you have most of the data model. The rest is reporting.

Where the HR suite stops

Off the shelf HR software handles the employment record well. It stores the contract, tracks leave, runs payroll integrations, and does so with more rigour than anything a small team will build. That part is genuinely solved and worth paying for, and the general form of that decision is set out in custom software versus off the shelf, decided in the right order.

Where it stops is the company specific half. The systems a new starter needs access to are yours. The sequence in which your team introduces someone is yours. The thing a new hire is meant to have shipped by week three is yours, and no suite ships with it. Companies work around this by writing the company specific half into a document that the suite links to, which is to say they keep the part that actually fails in exactly the place it was failing before.

The honest test is the one that applies to any internal build: does the workaround cost more than the build, repeatedly and measurably? If onboarding happens twice a year, the document is fine. The signals that it has stopped being fine are the same ones listed in signs you need custom software, and signs you do not yet.

The records question, which is not optional

An onboarding tool holds a concentrated pile of personal data about people who have very little leverage to object, which makes it a higher risk system than its size suggests. The UK Information Commissioner's Office is clear in its guidance on the storage limitation principle that the law does not set a retention period for you, that it is on the organisation to justify how long it keeps personal data for its stated purpose, and that data should not be kept indefinitely just in case it turns out to be useful.

That has a direct design consequence. If the tool inherits candidate records from recruitment, it needs a deletion path for unsuccessful applicants rather than an archive that grows forever, and the ICO's guidance on keeping employment records makes the same point about reviewing what is held when someone leaves. A retention rule is three lines of code if you write it at the start and a project if you write it in year three.

The other half is backups, because a system holding employment records is one you cannot casually lose. What a workable arrangement looks like at this size is in a data backup strategy for a small business, in plain terms.

What to build first

Build the template and the checklist. Nothing else, in the first version.

The offboarding mirror is worth naming specifically, because it is nearly free once onboarding exists and it is the version with the real risk in it. An access grant that does not get revoked is a security problem with a name attached to it, and the list you already built is the list you need to walk backwards.

Scoping this properly before anyone writes code takes about an afternoon, and the method is in how to scope a software project before anyone writes code. If the current process lives in a spreadsheet that several people edit, the migration question comes first, and that sequence is in migrating from spreadsheets to a database without losing the history.

The limits worth saying out loud

A tool does not create ownership. If the reason IT access takes nine days is that one overloaded person does it between other work, a dashboard will show you a red row for nine days and change nothing. The tool makes the constraint visible, which is genuinely valuable, but visibility and capacity are different problems and only one of them is a software problem.

It also does not fix a hire that should not have happened. Before building onboarding infrastructure for a first commercial hire, the prior question is whether the role is ready to exist at all, and BDG Labs works through that honestly in when to hire your first salesperson, and the six readiness tests. Tooling around a premature hire just makes the mistake tidier.

And it will not survive contact with a process nobody agreed on. If two managers genuinely disagree about what week one should contain, the tool will encode one of their views and the other will quietly stop using it. Settle that first. It is a twenty minute conversation and it is the actual dependency.