This decision gets made as a cost comparison and it isn't one. That's why so many pre-seed companies get it wrong in the same direction.
The cost comparison goes: a contractor is £600 a day, a junior developer is a fraction of that on an annualised basis, therefore hiring is cheaper. The arithmetic is correct. The conclusion is usually wrong, and the reason has nothing to do with money.
The actual question
You are short of one of two things, and which one decides everything else.
You might be short of throughput. You know what to build. Someone technical has already decided the architecture, the sequencing, the trade-offs. There is more work than there are hands, and the work is well enough understood that a new person could pick up a ticket and do it correctly without a long conversation first. This is a hiring problem. Hire.
Or you might be short of decisions. You have eleven features and no strong opinion about which three prove the thesis. You don't know whether the model is good enough, whether the integration is a week or a month, whether the thing you're about to build is the thing that matters. There is no roadmap; there's a hypothesis and a runway. This is not a hiring problem, and hiring into it makes it worse.
Most pre-seed companies are short of decisions. Almost all of them try to solve it by hiring, because hiring is what you do when you need engineering, and because "we made our first technical hire" is a sentence that sounds like progress.
What a hire actually costs at pre-seed
Not the salary. The salary is the part you budgeted for.
It costs lead time. Writing the spec, posting it, screening, interviewing, offer, notice period. Two to three months is normal and that's before anyone writes a line of your code. If your runway conversation is happening now, the hire is not a solution to it — the hire is a thing that starts happening after the problem has already resolved itself one way or the other.
It costs direction. This is the one that gets people. A junior or mid-level engineer needs someone to tell them what to build and to review whether it's right. In a company with a technical co-founder, that person exists. In the company that's asking this question, they usually don't — which means you have hired someone whose productivity depends on a resource you don't have. They will be busy. That is not the same as being useful.
It costs irreversibility. A twelve-month commitment made by a company with a twelve-month runway is a bet that the current plan is the right plan. At pre-seed the current plan is a hypothesis under test. If the Sprint comes back with a no — and sometimes it does — a contract ends and a hire is a conversation you'll be dreading for a month.
And it costs the thing you were trying to buy. If what you needed was judgement about what to build, and you hired execution capacity instead, you have converted a decision problem into a management problem, and you now have both.
What a contract actually costs
Also not what you think.
It costs more per day, visibly. £600 a day for someone senior against a UK median of £513 for a software developer contract, measured over the six months to 16 August 2026. You feel every day of it, which is uncomfortable and also useful: nobody drifts for three weeks on a day rate you're watching.
It costs continuity. When the engagement ends, the person leaves, and whatever isn't written down leaves with them. This is a real cost and it's manageable — handover docs, a codebase someone else can pick up, no proprietary framework only they can maintain — but it's manageable only if you insist on it at the start. Ask what happens on the day it ships, before you sign anything.
It costs the ceiling on ownership. A contractor optimises for the engagement. An employee optimises for the company. Over a long enough horizon that difference compounds and the employee wins. Pre-seed is not a long enough horizon; that's the whole point of the stage.
Where the two actually fall
Contract when there's a question. When you need something proved before you can justify the next six months, when the scope is boundable, when the deadline is external and real — a raise, a board meeting, a partner who needs to see it. Fixed scope, fixed price, hard end date. You are buying an answer, and an answer has a natural stopping point.
Hire when there's a roadmap. When you know what you're building for the next year, when the work genuinely parallelises, when there's someone senior in the company to set direction and review the output. You are buying compounding capacity, and capacity needs somewhere to compound into.
The sequence that works, more often than not: contract to get the answer, then hire against the answer. The build becomes the spec, the codebase becomes the thing you onboard someone into, and you're now hiring for a known problem instead of an open one. Hiring is much easier when you can describe the job.
The sequence that doesn't: hire to get the answer. Now the hire's first task is to decide what to build, which is the thing you needed help with, and they were hired to execute.
The bit where I declare an interest
I sell four-week fixed-scope builds, so of the two options above I have an obvious preference and you should read the last three sections accordingly.
What I'd say in my own defence is that I turn down the ones that should be hires. If a founder describes sustained work across several workstreams with a clear roadmap and someone senior already in the room, a Sprint is the wrong purchase and I'd rather say so on the call than take four weeks of their runway to prove it. That's not generosity — a build that shouldn't have happened is a bad case study for everyone involved.
If you're genuinely unsure which one you are, that's a thirty-minute conversation and it's free. Bring the eleven features. We'll find out whether you have a decisions problem or a throughput problem, and those have different answers.
Sources: ITJobsWatch — UK Software Developer contract rates.