March 20, 2026

Outstaff Hostages: How to kill the market you work in, your business, and your employees' careers

I have been working as a department head in an IT company in Russia for almost four years. Most of our employees are engaged in an outstaff format, and we have had almost no turnkey or outsource projects. And because of this, we have problems.

What exactly is outstaffing?

In fact, there is nothing new in this section if you understand the difference between outsourcing and outstaffing. It is written solely for the integrity of the article.

In custom development, there are three approaches to work: turnkey, outsourcing, and outstaffing.

Outstaffing began to spread massively in Russia about 10–15 years ago. The format is as follows: a company hires developers, handles their development (not really, actually), takes on all risks related to the benefits package, replacements/dismissals (sometimes), and sells the developer, who is integrated into the client's team. The client manages the developer themselves, occasionally does additional training; the executing company in this case only has the obligation to react to the developer's performance, while the result is the client's responsibility. The developer is paid in this case either in a "buyout" format — the client pays for 100% of the time and uses it as they wish, or within Time&Material — the client pays only for the time spent.

In the case of outsourcing, however, the team, development management, and the result shift to the executing party. Often in this format, an employee of the client joins the executing team as a Product Owner, the client has less influence on the technical result and team composition, and if the team delivers everything on time and with good quality, then everything is fine. Such projects are often characterized by the familiar T&M payment formats and Fixed Price — payment based on a preliminary estimate, independent of labor costs.

Turnkey projects differ little from outsourcing: mainly in that the client provides the requirements and does not heavily influence the development. The executor makes most of the key decisions themselves, but also bears the responsibility for everything. The payment format is the same as in the previous case, but T&M is almost never found. It is often assumed that in this case, the executor has extensive experience in such products or even some ready-made internal solutions.

In 2020, this model gets a second wind — most IT work is performed by outstaff specialists. Sber, VTB, and other companies often have clouds of companies around them from which they attract employees. The world shifted to remote work, and the line between an in-house remote worker and an outstaffer became more transparent than ever.

Low responsibility of the executing company / Full control of the development process/status by the client

From the executor's point of view in outstaffing, everything looks simple: Hired, and sold in such a way as to cover costs and make a profit. If the client takes up 50% of the developer's time, you can usually bill 60%. And sell them to another similar project. Beauty! Why does the client like this? They have the highest immersion in the development process itself. There are no approvals, just a developer who was given a task, and they did it. If the developer slacks off — well, you write to the executor, the developer is given a magical kick or replaced. And if a task is delayed, you can just not pay for it. Beauty!

Short settlement period

For the executor, this is good; by the time last month's salaries are paid, mutual settlements have often already passed and the money is in the account. For the client, it is also a plus; if it is clear that the developer/executor is bad, they can be replaced. Plus, you can also attract people for short tasks on a part-time basis, which is relevant, for example, for QA or some "sluggish" product, or, conversely, a fire that urgently requires reinforcements to extinguish.

Low hiring/benefits costs

Until recently, the IT labor market had a shortage of personnel. Back then, hiring a single employee could cost a company tens or hundreds of thousands. And then there's the benefits package, vacations, sick leaves. For companies from Moscow, finding an employee for the office quickly became a problem. Why not find an employee on the outstaff market, for example, from Omsk, where salaries are lower? They will go to the office (this was relevant until 2020), they will be given a laptop if needed, and a replacement will be offered for vacation/sick leave/upon dismissal. If the employee burns out, they will be rotated to another project and you will be given a replacement, even if you have no internal projects. And if a client knows that a certain company selects employees well, they can take developers without interviews and hiring costs at all. Convenient!

The executor, on the other hand, often has a small bench, which covers internal needs and replacements; if there is no bench, they can find someone else's specialist on the outstaff market and embed their costs and profit into the price. Also not bad)

Convenient sales channels

Most sales in outstaffing happen through aggregating chats and connections. Fast and simple, marketing is often unnecessary. You have a free specialist — you sold them.

Well, if it's good for everyone, is there a problem?

Yes, there is. Let's analyze each plus from the other side.

Low responsibility / High controllability

The biggest illusion that everyone suffers from. Coming from a developer background, I see only one trend in outstaffing: clients do not know how to manage developers. There is no onboarding, no control over task execution, no skill in even clearly setting tasks and maintaining healthy communication in the team (and there isn't always a team). Often this turns into us (executors) taking control of management or training the client. Moreover, six months later, a new employee often replaces the trained one, and the wheel of Samsara makes a new turn. The client, having assigned the developer to recolor a button and move it to the left (for example), sees no changes a week later: the developer recolored and moved another button, which the previous developer had glued to that spot with workarounds so it wouldn't move, and our developer invented their own workarounds to finally move it.

As a result: a claim where everyone lost. The client got whatever, the developer burned out, and the executing company is forced to prove that the developer worked and did what was asked.

Short settlement period

It always creates the problem of a short planning horizon. Clients can name any project duration, but few will allow it to be included in the contract. And in my practice, there were clients who came in with plans, but after a short time, their project "unexpectedly" closed, the concept changed, and so on. Tactically, this is a very convenient format, but in reality, the executor suffers from it. The client can cut the time spent by the developer, for example, to 70%, and the executor is unlikely to find a workload for the remaining 30%.

Low HR costs

They gradually became a myth. And everyone is to blame here:

First, the clients. The market has long demanded the most experienced developers for the simplest tasks. The most experienced ones arrive, burn out, and do everything slowly for a high price. The gap between the actual experience of specialists and what is expected of them and written about them has long been an open secret on the market. Because of this, clients are forced to interview everyone as if they were hiring them, interviews have become detached from the project's needs, and developers perform tasks that have become routine for them and do not lead to growth.

Second, outstaff middlemen. We sell almost all developers through 2-3 "layers" of middlemen. "In the middle" sit simple HRs who, via AI chatbots (and before that - simply by keyword searching through resumes), verify resumes against vacancy requirements. And each such "middleman" increases the developer's cost without bringing value to the market. Often, they used to sell only their own developers, and then, having obtained direct contracts with large clients on the market, they shrank their staff and began simply controlling their clients' cash flow.

Third, the executors, who supported and actively participated in destroying the concept of a specialist's experience. If we had all been conscientious and preserved the expertise of matching a developer to a project and a project to a developer, hiring in outstaffing would be simpler, and the market would be understandable and predictable. The collective executor failed at this and broke the great thing it had. By the way, they also invented the concept of a "pre-offer", where a developer is not hired but is already being sold. As soon as a project is found, they are hired.

Before the next paragraph, I want to note that no political reasons for market and economic changes are touched upon, and I ask not to discuss this in the context of the article.

And finally, the economy. The economic slowdown began to freeze the market, causing a shift towards monitoring actual costs rather than convenience. Also, the VAT threshold raised prices in the outstaff market to a level where it is cheaper to hire anyway. Furthermore, with the slowdown, the amount of work in IT decreased, and the personnel shortage was replaced by a surplus... Which spoiled clients with beautiful resumes entered and "broke" the labor market there too with their vacancies.

Sales channels

They turned into a bloodbath due to the previous point. Both in the labor market and in outstaffing, an oversupply and lack of any trust in resumes tighten barriers and make sales impossible. There is no other way, there is no point in developing a brand — most executors work through "middlemen" and are forced to pretend to be them. Everything gets into the portfolio very indirectly. Moreover, for an employee to start, they often have to pass 3-4 interviews — screenings with "middlemen", technical interviews detached from the project, etc. At any of these stages, one can fail due to something that won't even be needed on the project.

Stagnation and burnout in employee development

Very simple projects often end up in outstaffing, where employees perform standard tasks. While this might be an experience for juniors (but juniors won't pass the request), for middles and seniors it will be stagnation that evolves into burnout. Almost all goals set by the manager will only be achievable on some pet projects, and the employer won't be able to sell them further as mastered skills (even when they actually are).

There is another category of projects on the outstaffing market — endless legacy (in the bad sense of the word). A massive refactoring often burns employees out very quickly, which is why it is handed over to outstaffing. Undoubtedly, a developer will emerge from such a project more skilled, but burned to the ground.

So what now?

The market has outlived itself, outlived itself a long time ago. It's time to move forward. If you are not looking for your company's development outside of outstaffing, you will close down sooner or later. Build a product, look for outstaffing. To do this, you need to develop marketing, sales, and promote your brand. If you can. If there is someone in your company who believes that the company's future can be in outstaffing — show them this article, convince them otherwise.

Clients in this market have long stopped getting the best specialists to solve their tasks, but only get extra costs and poorly solved tasks.

Executors get a small share of the developer's cost, a lot of quality complaints, and a big headache with sales.

And developers, burning out in droves on some primitive tasks, not developing and stagnating, also get nothing good in this market.

Instead of an afterword

This article is very unspecific only because, in fact, we moved away from outstaffing two years ago. Nevertheless, everything in it is the real experience of real people, companies, our partners, my friends, and colleagues.

This whole article is unlikely to be a revelation to anyone. But it was written to remind everyone of the elephant in the room that no one notices.

Often, my colleagues simply lack the arguments to prove that it's necessary to develop other work formats and other sales channels. Offer to package some work as a case study, try to secure a trip to a conference with a case study, and use it to gather those willing to implement it for themselves.

And if you happen to be the owner of a business built on outstaffing — listen, diversify your sales and work formats. The golden age of outstaffing is over. Do not be afraid of fixed prices, do not skimp on promotion and PR. Expand the coverage of tasks the company can solve, develop project management to take on outsourcing. If budgets allow — invent a product, build it using the bench. It doesn't have to be something simple, but something you can pull off.

Sergei Riabinin

Sergei Riabinin

Software Engineering Manager