The Dutch government's proposed Self-Employed Persons Act introduces a two-part test, built around seven criteria, to decide when a contractor is genuinely independent. If a freelancer and the working relationship meet those criteria, both sides get a legal "safe harbour": no employment contract, no reclassification risk. For hiring managers and freelance developers, that's the headline. The details decide whether it actually helps you.

This isn't law yet. It still needs review by the Council of State and approval from both houses of parliament, and it's not expected to take effect before 2028, according to reporting from de Volkskrant. But the direction is clear, and it matters now. Any hiring manager setting up a long-term freelance arrangement with a developer or DevOps engineer is already working against this future standard. Tech freelancers planning their next contract are, too.

The goal is simple: give real self-employed professionals and their clients certainty, so a compliant freelance relationship doesn't get reclassified as employment years later. That's according to the government's own framing, reported by NU.nl, which describes the aim as providing clarity and preventing false self-employment.

Dutch courts have been moving this direction for a while. The Supreme Court confirmed in February 2025 that the relevant factors for determining employment status generally carry equal weight, though demonstrable entrepreneurship can tip the balance in an individual case. There's no single decisive test. That's exactly the uncertainty this new law tries to fix.

For tech recruitment, this isn't abstract legal theory. A senior system developer working on a long freelance contract, or a security engineer embedded in an internal team, sits right in the middle of this question. The new rules won't change what good contracting looks like. They'll just make the consequences of getting it wrong more predictable.

Meeting these criteria on paper isn't enough. The relationship has to work that way in practice, according to NU.nl's summary of the proposal. Here's what the seven points cover:

Registration as a business. Chamber of Commerce registration and a VAT number. Basic, but it has to be real, not a formality.

Multiple clients. At least three clients over a two-year period, based on current reporting. A developer working almost exclusively for one company for two years will struggle here, whatever the contract calls them.

Entrepreneurial risk. Real exposure to liability, including the cost of fixing your own mistakes. Professional liability insurance helps show this risk isn't just contractual language.

Freedom over how the work gets done. A client can define the outcome. They shouldn't be directing every technical step or managing the contractor through a line manager.

Freedom over time and place. Can the contractor choose when and where to work, within reason? Fixed office hours and mandatory shifts work against this.

Contractual risk allocation. The agreement should show the contractor carries responsibility for non-performance and damage. Think acceptance criteria and rework clauses, not a generic independence statement.

Match between paperwork and practice. This one matters most. A model agreement helps, but it can't paper over daily managerial control.

Outcome-based projects hold up better under this framework than open-ended staff augmentation. Designing a platform architecture, running a cloud migration, or hardening a CI/CD pipeline (the automated process that builds, tests, and deploys code) are the kinds of assignments where a freelancer clearly controls the approach, the tools, and the sequencing.

Compare that to a developer working full-time for one client for two years, getting daily tickets assigned, sitting through the same performance reviews as employees, and reporting to the same team lead as the internal staff. Same work. Same hierarchy. No other clients.

That's the profile most likely to fall outside the safe harbour.

DevOps work adds a wrinkle. On-call duty often requires fixed availability, which looks like operational control. That alone doesn't create employment. But the agreement should spell out why fixed availability is a business necessity, define the service level, and leave room for professional discretion over how incidents get handled. Access to production systems isn't the issue. Who carries the risk when something breaks is.

Waiting for the law to pass before thinking about this is a mistake. The direction of travel is already visible in Dutch case law and in how the Belastingdienst (Dutch tax authority) enforces existing rules.

Start by defining assignments around deliverables, milestones, and acceptance criteria rather than hours and availability. Document why you need specialist outside expertise and why the engagement is temporary. Give contractors real discretion over tools and working methods. Avoid employee-style language in contracts: no job titles, no manager, no annual appraisal, no leave approval.

Ask for evidence of business activity too. Chamber of Commerce registration, VAT status, other clients, a portfolio. None of this is bureaucracy for its own sake. It's what separates a defensible freelance engagement from one that collapses the moment someone asks questions.

This is also where the line between coordination and authority gets tested. Agile ceremonies, shared Slack channels, and architecture meetings are usually necessary to deliver a project well. They become risky only when combined with fixed hours, direct supervision, and the kind of day-to-day control you'd exercise over an employee. Teams that have already mapped out this distinction, as we covered in our deeper look at the self-employment act for IT contractors, tend to handle the transition with far less friction.

If you're a freelance developer or engineer working almost exclusively for one client, it's worth asking honestly: would this hold up under the new test? Maintaining more than one client, even a small secondary one, strengthens your position considerably.

Quote for outcomes, not indefinite availability. Keep a portfolio, invoices under your own business name, and professional liability cover. These aren't just compliance checkboxes. They're the evidence that makes the difference between being treated as a genuine business and being treated as an employee without the benefits.

The market context matters here too. Companies are under more pressure to get specialist hiring in fields like cybersecurity right, and that pressure tends to favor contractors who can demonstrate real independence over those who can't.

It's tempting to read a new law with clearer rules as good news for flexibility. The safe harbour gives predictability to genuinely independent arrangements, but it makes life harder for embedded, long-term freelance setups that function like employment in every way except the contract.

Companies relying on long-running "freelancer who's basically staff" arrangements will likely need to restructure. Some of those roles will convert to employment. Others will move toward intermediary or payroll models. A smaller group will become genuine project-based engagements with real deliverables and real contractor risk.

None of this is dramatic news. It's a continuation of where Dutch enforcement was already heading.

The companies that come out ahead are the ones setting up compliant structures now, not waiting for 2028.

The proposed Self-Employed Persons Act won't simplify tech hiring overnight, and it's still years from taking effect. But the logic behind it, clear criteria, real independence, contracts that match practice, is already shaping how serious companies and serious freelancers structure their work.

For hiring managers, that means setting up assignments around outcomes now, not waiting for the law to force the issue. For developers and engineers working independently, it means treating your business status as something to actively maintain, not something a contract template handles for you.

Doghouse works through a structured Delivery Sprint process precisely because getting this right from the start saves everyone the headache later. If you're building out a tech team and want contracts that hold up under scrutiny, that's a conversation worth having early.

1. Nieuwe zzp-wet moet duidelijkheid geven en schijnzelfstandigheid voorkomen
2. Kabinet komt met langverwachte zelfstandigenwet, biedt die nu wel duidelijkheid voor zzp'ers?
3. Dutch employment law: legislative update july 2026
4. Twaalf dingen die je als zzp'er – en opdrachtgever - ZiPconomy
5. The EU Platform Work Directive: Recent developments and ...
6. apps.eurofound.europa.eu · platformeconomydb · countriesNetherlands | Eurofound Platform work database

Written by our AI, read by a flesh-and-blood recruiter.