Contract developer or employee: which do you actually need?
The comparison most companies run is a day rate against a salary, and it settles nothing, because the two arrangements buy different things. A contractor buys capacity that can be turned off. An employee buys accumulated context that stays. If your work has a clear end, hire a contractor and stop worrying about the rate; if it does not, the rate difference is the least important part of the decision.
What are you actually choosing between?
Duration and context ownership, not price. A contract arrangement is right when the work has an end you can describe, and an employment arrangement is right when the value is in somebody knowing your system a year from now. Everything else in the decision follows from that.
Context is the part people underestimate. A developer who has been in your codebase for eighteen months answers questions in minutes that would take a newcomer a day, and that accumulated knowledge is worth more than the difference in rate. It is also entirely lost when the person leaves, which is the real cost of a short arrangement rather than the invoice.
So the first question is not what either costs. It is whether you will still need someone who understands this system in a year, and whether you would be comfortable if that person were not available.
What does each arrangement really cost?
The day-rate comparison undercounts employment substantially, and it also undercounts contracting in ways that are less obvious. Set out honestly, the two converge more than either side of the argument tends to admit.
| Dimension | Contractor | Employee | Commonly missed |
|---|---|---|---|
| Headline cost | Day rate, invoiced | Salary | Employment adds payroll taxes, pension, equipment, leave and recruitment cost |
| Time to start | Days to weeks | Weeks to months, plus notice period | The gap is often the real reason for choosing contract |
| Time to useful | Same as anyone, weeks | Same as anyone, weeks | Onboarding cost is identical and is paid every time |
| Ending it | Notice in the contract, usually short | Legal process, cost and time | Optionality is most of what the higher rate buys |
| Context retained | Leaves with them | Compounds while they stay | The dominant cost on work lasting over a year |
| Classification risk | Real, and jurisdiction specific | None | Treating a contractor exactly like staff is what creates it |
When is a contractor clearly the right answer?
When the work is bounded and you can say what finished looks like. A migration, an integration, a specific product launch, or covering a parental leave. These have an end date that exists independently of how the person performs, which is what makes the arrangement honest on both sides.
It is also right when you need a skill once. Nobody needs a permanent expert in the payment provider they will integrate exactly one time, and hiring for that permanently produces a role that becomes something else within a quarter.
The third case is speed. If the work starts now and a permanent process would take three months including notice periods, a contractor is not a compromise, it is the only arrangement that matches the timeline. It is reasonable to run a permanent search in parallel and plan the handover deliberately.
When does the contract arrangement go wrong?
When it is used to avoid a hiring decision. A contractor kept on rolling monthly renewals for two years is an employee with worse retention and a higher rate, and both sides usually know it. The person has no reason to invest in anything longer than their notice period, and you are paying an optionality premium for optionality you are not using.
It also goes wrong when the contractor becomes the only person who understands something. That is not a contracting problem in principle, but a contracting arrangement makes it far more dangerous, because the exit can be thirty days rather than a resignation you can plan around.
The third failure is classification. Several jurisdictions have tests that look at control, substitution and integration into the team, and an arrangement that treats a contractor exactly like an employee is the arrangement most likely to be reclassified. Take advice locally rather than assuming that a signed contract settles it.
Who owns the code, and when?
Not automatically you, and this catches companies out more often than it should. In many jurisdictions work created by an employee in the course of their employment vests with the employer by default, while work created by a contractor does not unless the contract assigns it. That assignment needs to be explicit and in writing.
Check the assignment covers everything, not only the deliverable. Repositories, infrastructure configuration, designs, scripts, and any account or domain registered during the work. The item that most often goes missing is not code, it is access: a cloud account or a third-party service registered under the contractor's own email.
Also agree what happens to anything they bring with them. A contractor who reuses their own libraries is normal and usually beneficial, but the licence under which you keep using them should be written down before the engagement rather than discovered at the end of it.
How do you structure a contract so it ends well?
Write the handover into the engagement rather than the final week. A short written record of decisions and their reasons, maintained as the work happens, costs an hour a fortnight and is the difference between a clean exit and three months of archaeology.
Require that nothing is deployed only from the contractor's machine. Everything runs through a pipeline in your account, on infrastructure you own, using credentials you can rotate. This single rule removes most of the risk in a short engagement, and it is a reasonable thing to state in the contract.
Then schedule a review at the point the work was supposed to end, and treat renewal as an active decision with a reason attached. Arrangements that end badly are almost always arrangements that were extended without anybody deciding to extend them.
Common questions
- Is a contract developer more expensive than an employee?
- Per day, usually yes. In total, less than the gap suggests, because employment adds payroll taxes, pension, equipment, leave and recruitment cost that the salary figure hides. What the higher rate genuinely buys is optionality: the ability to end the arrangement on short notice. If you are not going to use that optionality, you are paying for it without benefit.
- When should you hire a contract developer instead of an employee?
- When the work is bounded and you can describe what finished looks like, such as a migration, an integration or covering a leave. When you need a skill exactly once, such as a payment integration that will not be repeated. And when the timeline will not survive a permanent hiring process including notice periods, in which case running a permanent search in parallel and planning the handover is the sensible arrangement.
- What is the risk of keeping a contractor for years?
- Three things converge. The person has no reason to invest beyond their notice period, so decisions get made for the short term. You pay an optionality premium for flexibility you are not using. And in several jurisdictions the arrangement risks reclassification, because the tests look at control, substitution and integration into the team, and a long rolling engagement treated exactly like employment is the clearest example of that.
- Who owns code written by a contract developer?
- Not automatically the client. In many jurisdictions employee work vests with the employer by default while contractor work does not unless the contract assigns it explicitly and in writing. The assignment should cover repositories, infrastructure configuration, designs and scripts, and any accounts or domains registered during the engagement, since the item most often lost is access rather than code.
- How do you end a contract developer engagement cleanly?
- Build the handover in from the start rather than the final week: a short running record of decisions and their reasons, maintained as work happens. Require that nothing is deployed only from the contractor's own machine, so everything runs through a pipeline in your account with credentials you can rotate. Then treat each renewal as an active decision with a stated reason, because arrangements that end badly are usually ones that were extended by default.
