From zero to paid: designing Shiftbase HR Pro

35→~600

Beta customers, within a year

~250

Active paying accounts in the Netherlands

1,000+

People hired using HR Pro

I designed the first post-offer hiring workflow for Shiftbase, turning a manual, chase-and-copy-paste process into a guided flow where candidates submit their own data and contracts generate themselves. It shipped as HR Pro and became a paid add-on in the Netherlands.

The key design move was treating hiring paperwork as a structured data workflow, not a document-editing task: collect data once, generate the contract from it, review it, sign it, then convert the new hire into an employee.

Shiftbase needed a new revenue stream, so leadership hired a PM to find one and hired me right after, as the team's designer. A survey with 121 responses, run before I joined, pointed us at the answer: only 43% rated Shiftbase's recruitment help as valuable, while post-hiring help scored well over 60%. The real gap wasn't finding candidates. It was everything between “you're hired” and “you can start”: chasing people for documents, then retyping that into a contract by hand, every single hire.

That reframed the bet from “build HR features” to “fix the operational gap right after the offer.”

As the team's designer, I owned the core mechanics HR Pro was built on: the new-hire form, the contract-template/variable system, and later, custom contract fields and the contract-extension/rehire flow. Decisions about scope, sequencing, and risk (like which market to launch in first, or where to draw the line on legal automation) were made together as a product trio.

We were scoping for small businesses that needed a lightweight alternative to a full HR suite, so the product had to solve one problem well rather than many shallowly. Contracts carry legal weight, so anything we automated still needed a human checkpoint before it became binding. We also chose the Netherlands before Germany, deliberately, since NL's requirements were the smaller compliance surface to learn on first.

Candidate-submitted form, not employer-chased. Employers were manually emailing candidates for IDs and bank details, then retyping what came back. Moving the form to the candidate turned the employer from collector into reviewer, and took away almost all of the chasing.

Generated contracts, not hand-edited ones. I designed a template system where employers place variables (salary, hours, probation period) that the system fills automatically from already-collected data. It was built for an in-app editor we planned to add later, so employers could stop moving documents back and forth between Word and Shiftbase. That editor turned out to be far harder to build than expected, so the trade-off was to ship the structured variable model first and accept setup friction we'd revisit later.

A review step before signature, and a lifecycle model that treats new hires differently from employees. Because a generated contract is still legally binding, we (as a trio) decided automation should prepare the document while a person retains final say. Sensitive fields (BSN, IBAN, ID) require an explicit action to carry over on conversion to employee, rather than defaulting to auto-copy.

After the first NL workflow shipped, the beta group kept growing as more customers opted in. We treated every release as a research touchpoint: when we shipped something new, especially something a beta customer had asked for, we told them directly and used that moment to ask how the workflow was holding up in real hiring.

That loop surfaced two gaps between a working MVP and a product customers would pay for.

The first: early customers had only a fixed set of template variables to work with. If a contract needed something beyond salary, hours, or start date, something specific to their business, like a travel allowance or a specific CAO clause, there was no way to capture it. So they'd go back to hand-editing the generated contract anyway. We introduced custom fields that any customer could create and reuse across new-hire forms, and made them usable as contract variables, so the same data the candidate entered once could fill the contract automatically, rather than being retyped or pasted in afterward.

The second: HR Pro only handled new hires, but hospitality businesses also need to renew contracts and rehire seasonal staff, with real legal weight in the Netherlands, where the number of consecutive renewals affects an employee's rights. So we extended the flow to renewals and rehires, and deliberately kept the legal rules out of scope.

By the July 2026 commercial launch, the old process was gone: customers no longer emailed candidates for IDs, then retyped everything into a contract by hand. In its place was a guided flow candidates completed themselves. HR Pro reached roughly 250 active accounts in the Netherlands. The original six-week scope, kept grounded in real usage through a growing beta loop, became the foundation the rest of HR Pro was built on.

The clearest unresolved issue was setup friction: without that editor, some customers told us template creation still meant too much back-and-forth with Word, and a few stepped away from HR Pro because of it. About a year in, once the team had grown, I ran a workshop bringing developers into the room to map where that flow broke down and find technical ways to make it faster, revisiting a trade-off from my own original design once real usage showed it was still costing us.

The first release also exposed a process gap: under our Shape Up pilot, design and engineering worked so closely in parallel that early drafts sometimes reached implementation before I'd validated them. We adjusted the process so design had lead time before build. A decision made well in a shaping session isn't the same as one that survives shipping, and that's the gap I've since focused on closing.