The question behind the question
When the freelancer feels expensive and the in-house hire feels risky, the honest move is to stop comparing prices and compare what you are actually buying. A freelancer sells delivered work. An in-house hire sells reserved time. The decision is not which is cheaper — it is which shape of spending matches your workload, and whether you can afford the part of an employee that is not the salary.
The loaded cost of an employee
The salary is the visible line; it is a minority of what an employee costs. Once you add the stack that comes with a human — benefits, payroll taxes, equipment, software, recruiting, onboarding, and the idle capacity you pay for whether the work fills it or not — the real number is well above the base wage. Standard HR estimates put the fully-loaded cost of an employee at roughly 1.4–1.7x the base salary once benefits, taxes and tools are added. That multiplier is a planning assumption, not a quote — but it is the honest one to plan with.
The BLS gives the anchor: the median annual wage for a web developer was $78,580 in the May 2024 release. Apply the fully-loaded 1.4–1.7x assumption to a median hire and the honest line on the budget stops being "a developer's salary" and becomes the whole package on top of it — the number that actually comes off your P&L.
The non-salary costs, line by line
- Benefits and payroll tax — healthcare, retirement, employer-side taxes. The 1.4–1.7x multiplier mostly lives here.
- Equipment and software — machine, monitors, licenses, tools. Small per month, mandatory every month.
- Recruiting and onboarding — the weeks of search, interviews and ramp-up before the hire produces at full speed. A mis-hire doubles this.
- Idle capacity — the one nobody budgets. You pay the full week whether the work is there or not; a half-empty backlog is the most expensive quiet expense.
- Management overhead — someone has to scope, review and manage the work. That time is not free.
The freelancer math
Freelancers look expensive per hour because you are paying only for delivered capacity — no benefits, no payroll, no bench, no idle time. The thing the comparison usually gets wrong is the denominator. Compare per delivered hour, not per scheduled hour, and renting wins whenever the work is intermittent: you stop paying the moment the work stops.
The crossover is workload. A developer busy forty hours a week, every week, forever, eventually justifies owning. But if the work is a burst here and a project there — twenty focused hours a week with real gaps — renting is not a compromise; it is the cheaper and better-shaped answer.
It is worth naming what the model is not deciding: quality. A strong freelancer matches or beats a strong employee on most work, because you are buying seniority and delivered output rather than headcount. The difference the model actually controls is shape — how the money moves, how the capacity flexes, how the engagement ends. That is the axis to choose on, not a quality assumption about one camp or the other.
How to run the math for your business
The honest way to decide is to write down three numbers and let them argue: your confirmed workload in hours per week across the next twelve months — not the hoped-for workload; the loaded hourly cost of a hire (salary times the loaded multiplier, divided by useful hours); and the delivered cost of outside help for the same work. Put them on one line and the model picks itself. Businesses that skip this converge on the costliest answer of all: whichever option sounded most decisive in a meeting.
Confirm the workload by looking at what the last six months actually consumed, not at what you wish the backlog were. Projects that arrive in bursts and vanish — a launch sprint here, a quiet quarter there — are the exact shape renting was built for. A steady, predictable, permanent line of work is the shape owning was built for. Be honest about which column you actually live in, and the expensive mistakes stop being possible.
Where the crossover sits
| Workload | Best model | Why |
|---|---|---|
| 0–10 hrs/week | Freelance, per project | No bench to feed; pay only for what ships |
| 10–25 hrs/week | Freelance retainer or dedicated contract | Predictable enough to reserve, too thin to employ |
| 25–40 hrs/week, permanent | In-house hire | The work is always there; ownership beats renting |
| 25–40 hrs/week, temporary | Dedicated contract | Full attention without the permanent payroll bet |
The dedicated-contract middle path
Between freelance and in-house sits the model this site exists for: a dedicated developer — a block of one senior's week, reserved for your backlog for the term, without the employer overhead of going permanent. It delivers the continuity of a hire (accumulated context, the same person month over month) with the exit of a contract. The freelance model sells delivered work; the dedicated model sells reserved time — and which one is right is decided by your workload, not your temperament.
When neither model is right
Some workloads fit neither pole cleanly, and the honest answer is a structure rather than a label. A freelance retainer — a reserved number of hours monthly, with a fair-notice exit — delivers a bit of both. A dedicated contract divides the difference more cleanly, giving reserved time without the permanent payroll bet. And some problems are not staffing problems at all: a one-off rebuild is a project, priced like the cost it is, not a reason to touch payroll either way. Forcing every need into a hire-or-not-hire decision is how overflow becomes headcount and a single project becomes a department.
The hybrid reality
Most companies sequence it, and the sequence is the point: freelance first, hire when the backlog is permanent. Validate the work with freelancers — cheap, scalable, no commitment. The moment the backlog stops being a project and becomes a recurring calendar position a freelancer keeps filling, that is the signal to hire. And an in-house team that discovers its workload was seasonal has made an expensive discovery; the hybrid avoids committing payroll to a workload nobody has proved is permanent.
The risks in both directions
In-house carries the single point of failure: one person owns the systems, the context and the keys, and if they leave — or the need becomes a second skill — you own a gap and a rebuild. The mitigations are the same disciplines as good contracting: documentation, redundancy, every account in your name.
Freelance carries the mis-hire risk in miniature if you skip the vetting questions — the downside of a bad independent is smaller, but the continuity risk is real: a freelancer is not on call, and their calendar is not yours. The dedicated contract splits the difference — accountable, but contracted.
The honest bottom line
Do not compare salary to hourly rate. Compare the loaded cost of owned time against the cost of delivered work, sized to your actual, honest workload — and price the work itself against the cost guide. Its bands — a small business site at $3k–12k, a store at $6k–30k, an application at $15k–80k — are one-shot economics; the make-or-buy decision above is a recurring one, and it deserves the same scrutiny.
When the shape is a defined project, hire freelance. When it is continuous, reserve a dedicated developer. When you want the rates to sanity-check either, the benchmarks are here — and the methodology explains exactly how the work here is run and priced.