I had a conversation last month with a Head of Engineering who told me his company "only hires contract-to-perm now." Every role. No exceptions. When I asked why, he said "it lets us try before we buy."
I asked him how many of his last ten contract-to-perm hires actually converted to permanent. He paused. "Maybe three."
That's not a hiring strategy. That's a revolving door with a premium price tag.
The Maths Nobody Does
Let's talk money, because this is where the contract-to-perm-as-default strategy completely falls apart.
A mid-level software engineer on a permanent salary of $150,000 costs the business roughly $170,000 to $180,000 when you factor in super, leave entitlements, and other on-costs. That's your fully loaded cost.
That same engineer on a day rate as a contractor? You're looking at $800 to $1,000 per day through an agency, which annualises to $200,000 to $250,000. That's 50 to 100% more than the permanent equivalent once you account for the total cost of engagement.
If you're running a three-month "trial" before converting to perm, you've just spent $50,000 to $62,500 on what is essentially a very expensive probation period. Permanent employees already come with a six-month probation period. It's literally built into the employment contract. You already have a trial mechanism. You're paying a massive premium to duplicate something you already have.
The Candidate Problem
Here's the other thing nobody tells you. The best permanent candidates don't want contract-to-perm roles. They see them for what they often are: a company that can't commit.
Think about it from the candidate's perspective. They have a stable job. They're considering a move. You offer them a contract-to-perm arrangement. Now they have to resign from their permanent role to take a contract with no guarantee of permanency. They lose their leave accruals, their continuity of service, potentially their visa stability. For what? So you can "try before you buy"?
The candidates who accept contract-to-perm are disproportionately people who are between jobs, who need something quickly, or who are already contracting and will happily take another contract with no real intention of converting. You're not getting the best of both worlds. You're getting a filtered pool that skews toward people with fewer options.
When Contract Actually Makes Sense
None of this means contracting is bad. Contracting is excellent when used for the right reasons.
Urgent project delivery
You've won a new client. You need three extra developers for four months to deliver the build. Contract is perfect here. Clear scope, clear timeline, clear end date. Nobody's pretending it's something it isn't.
Niche specialist skills
You need a Kubernetes architect to redesign your infrastructure. Or a machine learning engineer to build a specific model. Or a cybersecurity consultant to run a penetration testing program. These are genuinely specialist, project-based needs where contracting is the natural fit. The best people in these fields often prefer contracting because they can command higher rates and work on varied, interesting problems.
Covering a genuine gap
Someone's on parental leave. You've got a vacancy while you recruit for the permanent role. You need coverage. Straightforward.
When Permanent Is the Obvious Answer
If the role is ongoing, if you need someone to build institutional knowledge, if you want them to care about the long-term health of your codebase or your client relationships or your team culture, hire permanent.
Contractors, by design, are not incentivised to think long-term. Their engagement has an end date. They're optimising for deliverables within scope, not for maintainability, mentoring, or organisational improvement. That's not a criticism of contractors. It's a structural reality of the engagement model.
The companies that build the strongest engineering, data, and product teams are the ones that commit to permanent hires and invest in onboarding, development, and retention. Not the ones that keep people on rolling contracts hoping nobody notices the lack of commitment.
The Real Reason Companies Default to Contract-to-Perm
In my experience, it comes down to three things.
- Fear of a bad hire. Understandable, but solvable through better interviewing. A structured interview process with practical assessments is far more predictive than watching someone sit at a desk for three months.
- Budget uncertainty. The headcount isn't fully approved, so they hedge with a contract. This is a leadership problem, not a recruitment problem. If you can't commit to a headcount, fix your planning process.
- Slow decision-making. It takes the company eight weeks to approve a permanent hire but two weeks to sign a contractor. So they go contract and "convert later." This is an internal process failure dressed up as a talent strategy.
All three are organisational problems being dumped on the candidate. And the candidate pays the price in instability while the company pays the price in cost and talent quality.
Contract-to-perm isn't a strategy. For most companies, it's a symptom of indecision wearing a trench coat and pretending to be a plan.
The Decision Framework
Before you default to contract-to-perm on your next role, ask yourself three questions.
- Is this role ongoing or time-bound? If ongoing, hire permanent.
- Am I using a contract because the work is genuinely project-based, or because I'm nervous about commitment? If the latter, fix your interview process instead.
- Would the best candidate for this role accept a contract? If the answer is probably not, you've answered your own question.
Contract and permanent hiring are both legitimate tools. But they solve different problems. Using one as a substitute for the other doesn't reduce risk. It just creates a different kind of risk: the risk of paying more for less, and losing the candidates you actually wanted.
Commit to the hire or commit to the contract. Just stop pretending there's a magic middle ground that gives you the benefits of both with the downsides of neither. There isn't.