Nearly every founding team runs the same sequence. A spreadsheet of names and start dates, which works. Then a Notion database, because someone wants a page per person and a template for onboarding. Then, at some companies, a small internal app, because an engineer has an afternoon and the leave requests are cluttering a Slack channel.
That progression is usually described in vendor content as a mistake to be corrected as early as possible. It is not a mistake. It is a rational response to a real situation, and it works for longer than most people selling software would like to admit. It also stops working in ways that are precise enough to name in advance, which is the useful thing to know.
The spreadsheet is a real answer
Be honest about why it wins. It is free, it is instant, everyone in the company can already use it, and it is entirely under your control. There is no vendor, no procurement, no data processing agreement, and no monthly obligation. For a team of eight people in one country where two founders handle every hiring decision, a spreadsheet of names, start dates, salaries and holiday taken is a complete and correct system of record.
The Notion version adds what the spreadsheet lacks most visibly: a page per person, somewhere to attach a contract, and a checklist that can be duplicated for each new hire. That is a genuine improvement and it costs a morning.
The internal app is the point at which the calculation quietly changes, and it deserves the most scepticism. The first ten percent, a directory with a leave form, is a pleasant weekend project. The remaining ninety is effective dated history, approvals, document retention, per country fields, an audit trail, permission rules that hold when someone leaves, and a permanent maintenance claim on an engineer you hired to build the product you actually sell. Teams that build well usually build one narrow thing no vendor does and buy the ordinary parts around it.
Where it genuinely works
Three conditions, and you need all three at once.
Very small headcount, where every person is known personally by whoever maintains the list, so an error is caught by memory rather than by validation. One country, so there is one set of statutory fields, one leave regime and one definition of a leaver. And no external reporting obligation beyond the basics your accountant already handles, so nobody outside the company ever needs to be shown the underlying record.
While those three hold, buying software adds cost and process without adding much. Anyone who tells you otherwise at that stage is selling.
The four events that end it
The transition is not gradual. It is triggered, and there are four triggers.
The first employee who is not a founder. This one is about permissions, not scale. A founder can see everything because a founder is liable for everything. The moment an office manager or an ops hire is maintaining the list, a spreadsheet containing salaries has become a document where the access control is a shared link and the audit trail is version history. That is the point at which who can see pay stops being an abstract question, and it is worth asking of any tool you consider, as covered in the twelve questions to ask a vendor.
The first leaver who needs a document two years later. Someone who left in 2024 needs an employment letter for a mortgage or a visa. You need their exact title, their exact dates, their salary at the time, and a document generated from that. A spreadsheet holds what is true now, not what was true then. Somebody overwrote the title when they were promoted, and the contract is in an email account that was closed at offboarding. This is the trigger that catches people by surprise, and it arrives long after the headcount question felt settled.
The first audit or diligence request. An investor, an acquirer, a customer security review or a regulator asks a question that begins “show me”. Show me every current employee with contract, start date and current salary as of a date in the past. Show me who had access to this system and when it was removed. Show me that leave accrual matches policy. A spreadsheet can answer those questions but cannot evidence them, and evidence is the entire point of the request.
The first hire in country number two. Everything doubles that you assumed was singular: the leave regime, the notice period, the statutory identifiers, the document set, the definition of a working day. Two countries in a spreadsheet is not twice the work of one, it is the beginning of a second spreadsheet with different columns and a person mentally translating between them. If this is on your roadmap, sequence it deliberately rather than discovering it, which is what the hiring plan guide is for.
Buying too early has a real cost
The reverse mistake is less discussed and just as expensive.
You pay for capacity you cannot use: modules for performance cycles you do not run, engagement surveys for a team that eats lunch together, an org chart for an organisation that fits on a whiteboard. You spend a week configuring approval chains that describe an organisation you do not have yet, and then you rebuild them when the real structure emerges. You give a vendor eighteen months to accumulate your switching cost before you know what you need, which is the worst possible time to acquire one.
And there is a subtler cost. A system implies a process. Buying performance software early tends to produce a review cycle designed by the software rather than by you, and undoing that later is harder than never having had it.
So the correct answer to “when should we buy” is not “as early as possible”. It is “when a trigger fires”, which is why the list above is a list of events rather than a headcount rule. If none of the four have fired, what a free plan actually means is a more useful thing to read than a feature comparison, because the question at your stage is what you get without commitment rather than which tier is best.
When one of them does fire, the next document worth reading is the implementation plan rather than another comparison table. Buying is a decision that takes an afternoon. Standing the record up so that the rest of the company trusts what is in it takes a fortnight, and the order you do it in decides which of the two it ends up feeling like.
Where we stand
Our own position is that most companies buy their first HR system about a year after the first trigger fires and roughly two years before they think they should. That is the gap we try to fit into, which is why the core system of record is free up to twenty people rather than time limited: a trial that expires forces the decision on the vendor’s schedule, and a headcount cap forces it on yours.
Where we deliberately do not compete is the second and third trigger. If you need a document reconstructed as of a date two years ago, or an evidence trail for a diligence request, you need a system that recorded history at the time. No tool, ours included, can reconstruct what nobody wrote down. Moving from a spreadsheet gives you a correct record from that day forward and a manual reconstruction of everything before it, and anyone promising otherwise is describing an import that does not exist.
What we do carry from day one is the part most first systems lack: pay is a separately granted permission rather than something every admin can see by default, and every change to a record is written to an activity log that administrators can read. Be clear about the limit there, because it is the one people assume the other way: an activity log tells you that a title changed and when, which is not the same as the record being reconstructable as it stood on a date. Effective-dated role history is not built. Compensation is the part that genuinely is dated. The modules that sit on top of that, when you eventually need them, are listed with what each one does on modules, and the product page covers what the free core includes. If you are earlier than all of this, the startup guide is written for the stage before you buy anything.