Open HR
Open-source hiring platform for the companies enterprise tools were never built for
Most small companies hire on WhatsApp. Not because they want to.
Every serious hiring tool assumes a customer that most companies are not — an HR team of twenty, a recruiter with an ATS budget, an ops manager trained on enterprise software. A founder hiring their sixth person has none of that. So hiring happens in group chats and spreadsheets, and good candidates get lost in somebody’s inbox.
Open HR is built for that founder: an open-source hiring platform for small companies in Lagos, Nairobi, Johannesburg and London. Free forever for individuals, self-hostable by anyone, and paid for only by the organisations that want SSO, audit logs and somebody else running the servers.
There is a complication the enterprise tools never have to solve. When a company posts one role open to candidates in three countries, three different data protection regimes apply to that single job post before a single application arrives. Each wants a different lawful basis, a different retention period, a different disclosure. Getting it wrong is not a bug. It is a regulatory exposure sitting on a founder who has never read a privacy statute in their life.
Which makes the design problem underneath this product a strange one. Not make hiring simple. Make somebody compliant across nine jurisdictions without ever letting them feel like they are filling in legal paperwork.
Nothing gets designed until the system exists.
Design system built alongside the Lead Designer before any screens: icon library (componentized with Claude), color referenced against Cal.com and rebuilt in our own direction, and Inter on an irregular type scale adapted from Rasmus Andersson’s own site. Variables for every parameter, tested for light and dark from the start. Components: banners and notifications, selection controls, buttons, avatars, inputs, tags and chips.
A specification is not a design.
The product documents for Open HR are dense: lawful bases, retention schedules, cross-border transfer instruments, gate severities, nine markets. None of that is a design. Turning it into something a founder can move through was the work.
I started by studying how others handle it, Deputy, Workable, Remote, Wise, Oyster, not to borrow patterns, but to find the places where each of them makes the user do work the product should have absorbed.
Then wireframes. Waitlist, account creation, login, password reset, onboarding, and the permissions and access-control model, because Open HR is a tool a team shares, and who can see what is a design question long before it is a settings page. Over a hundred frames before anything was made to look good.
Wireframes
The screen I spent longest on never shipped.
I wireframed a homepage, a landing surface for someone signing in. It was thorough. I mapped every error state it could hold, every empty condition, every way it could fail.
Then the team sat with it and asked a harder question: does someone who opens this product to do one specific thing need a homepage before they do it? A founder logs in to post a job or check applicants. A homepage is a room you walk through to reach the room you actually wanted.
We cut it. It was the right call, and it is the clearest lesson I have had in the difference between thorough work and necessary work.
Mapped for engineering, not for show.
Every screen, decision, and error state in the onboarding flow, laid out end to end so engineering could build it without guessing what happens next.
Onboarding Flow
Annotated for zero guesswork.
Every spacing value, state, and behavior called out on the screen itself, so implementation matches the design.
The job creation in high fidelity
Role & Responsibility
Design system, built with the Lead Designer: icon library, colour, typography and the type scale, variables, light and dark, and the component set.
Designed end to end: wireframes for waitlist, account creation, login, password reset, onboarding, the homepage, and permissions and access control, the jobs page, and application tracking system.
What this taught me
A design system is a product decision, not a tidy-up.
Building the foundation before the screens cost weeks up front. Building it afterwards would have cost the product, because every screen would have inherited a set of decisions nobody made on purpose.
Legal requirements are design requirements.
Nothing here treats compliance as a layer applied on top of a finished product. The lawful basis picker, the gates, the retention setting, they are the flow. The work was letting a founder move through all of it without feeling audited.
Currently building
Currently working on flows for scheduling events, reviewing how workable, Lever and WizeHire handled it without turning it into the form where candidates give up. Wireframes and mapping first. The polish comes after.