A full-time hire pays off only when your code changes almost daily - if the system gets built once and then quietly lives on, contracting it out is cheaper and faster. The line is surprisingly sharp: a full-time developer starts to make sense when you have genuine work for them every month, month after month, and someone who can plan that work. Below that threshold you are paying for availability, not for results.
In this piece I break the three models down to their parts: what they really cost, how fast they start, where the risk sits and how to check a specific person before you hand them your business system.
Three ways of working - what actually differs
A full-time hire means employing a developer on an employment contract: you get all of their time, and all of the employer obligations that come with it. Contracting (a freelancer, a B2B contract, an outside developer) means buying a defined result: agreed scope, agreed price, agreed deadline. An ongoing arrangement sits between the two: the same person builds the system and then looks after it on a monthly retainer, knowing it from the inside.
| Model | What you pay for | When it makes sense | Main risk |
|---|---|---|---|
| Full-time hire | One person’s availability all month | Continuous product development, several systems at once | You also pay for months with no tasks |
| Contract | A specific result by a specific date | A project with a start and a finish | After handover nobody watches the whole |
| Ongoing arrangement | The result plus someone watching the system | A system meant to run for years | Dependence on one person - put it in the contract |
In practice most of the companies I work with need the third option, and walk into the conversation thinking about the first.
What a full-time hire really costs
The cost of an employee is not the number in the job ad. On top of the gross salary come employer-side social contributions (in practice somewhere between the mid-teens and low twenties in percent above gross - the exact figure depends on the contract type and the accident insurance rate), plus the items that are easy to forget in a first calculation.
| Item | Visible in the budget | Note |
|---|---|---|
| Gross salary | Yes | Market rates shift year to year, check current salary reports |
| Employer contributions | Rarely at the start | Added on top of gross |
| Holiday and sick leave | No | Roughly a month a year when the system stands still |
| Hardware, licences, tools | No | Computer, IDE, test environments |
| Recruitment and onboarding | No | Several weeks of your time and your team’s |
| Management | No | Somebody has to know what this person does on Monday |
That last item is the most underestimated. A developer without someone setting priorities produces code the company does not necessarily need. With a contract that cost moves to the contractor - they have to write the scope and keep the order straight, and you sign off on the result.
The other side: on a contract you pay a rate higher than an employee’s hourly cost, and that is normal. That rate carries the contractor’s risk, their gaps between projects, hardware, accounting, and the fact that you do not pay them for a month with no work in it. What those rates look like in practice I covered separately when writing about the cost of a Laravel developer and about WordPress developer hourly rates.
When a full-time hire genuinely pays off
Employment wins when you tick at least three of the following:
- You have a continuous backlog - a list of changes stretching months ahead, not “there will be stuff to do”
- Somebody in the company can direct technical work - a product owner, an operations director, anyone who settles priorities
- The system is the heart of the business - you earn from it directly, and every day of downtime is a countable loss
- The knowledge has to stay in-house - a specific industry, unusual processes, a long ramp-up into the domain
- You have someone to pair them with - one developer in a company is a lonely island; a second one raises the odds the first stays
If you ticked one box or none, employment will simply be a more expensive version of what a contract would have given you.
When contracting out is the better call
Contracting wins on work with a clear start and finish: building a store, a B2B portal for trade customers, an ERP integration, a site rebuild, a migration. It also wins when you need skills you cannot hire half-time for - because decent work on a business system is usually backend, frontend, databases, deployment and security all at once.
The third case is seasonal or irregular work: a few days a month, then silence, then a sudden spike before the season. Nobody keeps an employee busy on that rhythm.
Who starts faster
A contract starts faster, usually by an order of magnitude. Hiring a developer means a job ad, screening applications, interviews, a technical task, negotiations and a notice period at their current employer - realistically weeks, often months. An outside developer looks at the system, quotes it and starts as soon as a window opens up.
There is also a difference in the ramp-up curve. An employee needs time to learn the company, but after that they are fast at everything. A contractor who builds similar systems over and over is fast from day one on the typical parts, and slower on the parts that are very specific to your industry. That is why with unusual processes it is worth starting with a short paid slice of work - a cheaper way to test the fit than a three-month probation period.
The single-person risk - and how to cover it in the contract
The biggest risk in both models is identical: all the knowledge sits in one head. An employee can quit, a contractor can vanish - the effect on you is the same, and what makes the difference is what you have in writing. Whichever model you pick, watch four things:
- Rights to the code - the contract transfers the economic copyright to your company, including the right to modify it; with an employment contract this usually happens automatically, with a contract it has to be spelled out
- Repository and access in your name - the GitHub account, hosting, domain and payment dashboard registered to the company, not to the contractor
- Deployment documentation - how to stand the system up from scratch, where the environment variables live, what runs in cron; one A4 page is enough, but it has to exist
- Backups outside the contractor - a backup you can reach without asking anyone for permission
If anyone pushes back on any of those four points, that is a warning sign in its own right - no matter how well they write code.
How to vet a candidate before you start
A technical interview will tell you very little if you do not code yourself. Check the things you can verify without technical knowledge instead:
- A portfolio with live addresses - not screenshots, actual deployments you can open and click through
- Contact details for two clients - ask them one question: “what happened when something broke?”
- How they quote - do you get a written scope listing what is in and what is out, or just a number in a message
- Their answer about outages - a good contractor tells you unprompted how to report a problem and how fast they respond
- A small paid slice up front - one concrete change or an audit; you see the pace, the communication and the quality before you commit to a big project
- Version control - the question “where will the repository live and will I get access to it?” settles a great deal in one sentence
Red flags: no contract, resistance to a written scope, working without a repository, no test environment of any kind, a flat “I can do anything” without a single question about your process. Separately, it is worth deciding whether distance matters - in my view almost never, but local or remote developer is a question that comes up in every other conversation.
The setup that works most often: a contract plus maintenance
The healthiest arrangement for a company that is not a technology company looks like this: the system is built on a contract with a closed scope and a written quote, and after handover it moves into monthly maintenance with the same person. You get a predictable build cost and then a steady, low cost for someone watching over it - instead of a full-time salary just in case.
On my side it looks concrete: I price projects fixed-bid, usually in the 5,000-10,000 PLN net range depending on scope (Polish market rates), and ongoing technical support is Basic from 1,000 PLN, Pro from 2,000 PLN or Premium from 3,500 PLN net per month. The difference between plans is response time and the number of hours for changes, not a “better” or “worse” level of attention.
Where to start if you do not know which model to pick
Start with a free diagnosis - I look at your current system or your idea for one and tell you straight whether it is a job for a single contract, an ongoing arrangement, or genuinely for a full-time hire. I do talk people out of my own services when I see a company with a constant stream of changes that will be better off with their own person.
For anything larger a written quote always comes before the start: scope written out, a list of things outside scope, a deadline and a price. I do not begin work until both sides are looking at the same document - the simplest way to avoid expectations drifting apart in week three.
Frequently asked questions
Does a contractor work out more expensive than an employee? Per hour yes, over a year usually not - if you do not have a full month of work for them. With an employee you also pay for holidays, contributions, hardware and months with no tasks; with a contract you pay only for work delivered. Compare the annual cost of both models, not the hourly rate.
How long does it take to find a good developer? Hiring realistically takes weeks, counting from the job ad to the first day, because the notice period at their previous employer stacks on top. An outside contractor can be checked and started within days, beginning with a small paid task.
What if the contractor disappears mid-project? That is exactly why the code should go into a repository on your account from day one, and hosting and domain access should be registered to the company. Then the worst case is a delay and the cost of onboarding someone new, not the loss of all the work.
Can one person handle a company system? Yes, if the system is a sensible size and the workload is realistically spread over time. The line runs where several parallel streams of change begin, or where you need round-the-clock response - at that point you need a team, or a contract with a clearly stated response time and cover arrangements.
Would rather not watch over it every month yourself? I take sites and stores under ongoing care - backups, updates, monitoring, and priority when something breaks. Tell me what you run and I will send back scope and price.