Pricing & Process6 min read

Hiring developers in the EU: employ or contract?

A client could not hire locally, not because nobody was available, but because the commitment was hard to reverse. Two years on, how the contracted team works.

A client in the EU needed engineering capacity. Not a project with an end, not a website: continuous work on a product they were building and intended to keep building.

The obvious answer was to hire. They did not, and the reason was not that developers were unavailable in their country. It was that employing one there is a long commitment that is difficult to unwind, and they were not certain enough about the next eighteen months to make it.

Two years later there are engineers from our team in their stand-up every morning. This is what that arrangement is, what it solved, and what it does not solve, because the honest version is more useful than the sales version.

What actually stops a company hiring

Ask why a European company with budget and a real need does not simply hire, and the answer is rarely about supply. It is usually one of these.

The commitment runs in one direction. Notice periods, probation limits, statutory protections and the process required to end a contract vary a great deal across the EU, and in several countries they are substantial. The protections exist for good reasons. They also mean a hire made in an uncertain quarter is a decision you live with well past that quarter.

A wrong hire costs more than money in a small team. In a team of five, one mismatch is twenty percent of the engineering capacity, and the months spent deciding what to do about it are months the product does not move.

The on-costs are not the headline number. Employer contributions, holiday, sick pay, equipment, tooling and the management time to run a recruitment process all sit on top of the salary, and they differ so much by country that a figure from a neighbouring market tells you nothing useful about yours.

Hiring is slow when the need is now. A search, a notice period and a ramp-up is frequently six months from decision to first useful commit. Some roadmaps can absorb that. This one could not.

None of these say "do not hire". They say that hiring is the right instrument for a need you are certain about, and a heavy one for a need you are still sizing.

What they did instead

They contracted a team. The agreement is with us, the engineers are our staff, and the work happens inside the client's own process.

Two engagement shapes compared. In project outsourcing the boundary wraps the whole delivery: the client writes a specification and receives a result, while the board, repository, code review and decisions all sit on the supplier's side. With an embedded team the boundary wraps only the employment: the engineers work on the client's board, repository, stand-up and code review, and the supplier carries the contracts, payroll and cover.
The difference is not who writes the code. It is where the line sits, and therefore how quickly direction can change.

That distinction is the whole thing. Project outsourcing puts the boundary around the delivery: you specify, you wait, you receive, and anything you want to change goes through a contract. An embedded team puts the boundary around the employment only. The board, the repository, the review and the decisions stay with the client, which means direction changes the way it changes for staff: somebody says so in the morning.

What made it last two years

It is worth being specific, because "dedicated team" is a phrase every agency uses and most of them mean something looser.

The same people. Not a pool, not rotation, not a name on a contract with someone else doing the work. Two years in, the engineers know why decisions in that codebase were made, which is the thing a rotating supplier can never accumulate and the main reason this model is not simply expensive freelancing.

The client's process, not ours. Their board, their branching rules, their definition of done, their release cadence. We have opinions and we offer them, but a supplier who imports their own process into a client's team creates two processes and a translation layer between them.

Direct access to the engineers. No account manager relaying questions. The person with the answer is in the same channel as the person with the question.

Sizing that can move. Three engineers for a push, two in a quiet quarter. The capacity is available when the roadmap needs it and costs nothing when it does not, which is precisely the property employment cannot give you.

A clear exit. The repositories, the infrastructure and the accounts are in the client's name. If they end the arrangement tomorrow they keep everything except the payroll. An engagement you cannot leave is not a partnership, it is a dependency.

What it does not solve

It is not automatically cheaper. A good contracted engineer is not priced below a good employed one. What changes is the shape of the commitment, not usually the rate. If the entire case for this rests on being cheap, the case is weak.

You still need an owner. Somebody on the client side has to hold the product: what to build, in what order, and what done means. A contracted team does not supply that, and no arrangement where the supplier decides the product works for long.

Hours have to overlap. Our team sits in Spain and Ukraine, which is a full working day with most of Europe. That is not incidental; it is what makes the stand-up real rather than a status report written the night before.

The knowledge is with people, not with a company. It stays as long as the same engineers do, which is why the same-people point above is not a nicety.

When to employ instead

If the need is permanent, the role is core to what the company is, and you are confident about the next two years, employ. The commitment is the point. The protections that make employment heavy are the same protections that make somebody build their working life around your product.

Contract a team when the need is real but the shape is still moving, when you need capacity in weeks rather than after a hiring round, or when the work is a defined push rather than a permanent function.

Plenty of companies end up doing both, and that is usually the right answer: a small employed core that holds the product, with contracted capacity around it that expands and contracts with the roadmap.

What to ask before signing

Five questions that separate an embedded team from a body shop:

  1. Will these named engineers be the ones working, and for how long? Get the answer in writing. Rotation is the failure mode.
  2. Whose process do we use? If the answer is theirs, ask what happens to your board.
  3. Can I talk to the engineers directly? If everything routes through an account manager, you are buying project outsourcing with a different label.
  4. In whose name are the repositories, servers and accounts? If the answer is not yours, you have a dependency rather than a supplier.
  5. What is the notice, and what happens on the last day? A clean exit should be easy to describe. If it is not, that tells you something.

If you are weighing this for your own team, tell us what you are building. We will say plainly whether this shape fits, including when the answer is that you should hire.