How to Set Up an Offshore Development Center (ODC) in Minsk: Legal, Tax, and Operational Roadmap

A pattern we’ve watched repeatedly over the past two years.

A foreign-owned ODC isn’t built the moment a company decides, “We should hire some engineers in Belarus.” It’s built much later — usually 18 to 36 months after the first Belarusian engineer signed on through an EOR, once the team has scaled past fifteen or twenty people, and once the operational control gap and the structural cost stack have begun to argue for a permanent presence on the ground.

The conversation usually starts with the COO or the head of finance, not with the head of engineering. The engineering side is typically happy with what they have. It’s the operational and financial side that begins to feel the friction — EOR margin compounding monthly, decisions that need a Belarus-based counterparty to sign things, IP chains that everyone hopes are clean but nobody has properly stress-tested. And the right answer, in our experience, isn’t always to convert.

This article walks through the framework. When an ODC is the right answer. When it isn’t, even when the team has reached the size where the conversation usually starts. And when the answer is yes, how the setup actually plays out in 2026 — including the parts that blow up timelines if you don’t see them coming.

ODC vs. EOR — the question before the question

Too many foreign clients ask “How do I set up an ODC in Belarus?” when the question they should be asking, honestly, is “Do I actually need one yet?” The setup work is structural. It costs time, attention, and political capital inside the foreign parent. If the team size and operational complexity don’t yet justify it, the right answer is to stay on the EOR model for another year and revisit. The question of when to convert deserves more space than it usually gets.

EOR remains the right answer when

• Team size is under 15–20 engineers and not trending sharply higher.
• The Belarus team is supporting a non-Belarus headquarters, and the engineers don’t need a direct contractual relationship with the foreign parent.
• Banking simplicity matters more than tax optimization at the current scale.
• The foreign parent doesn’t want the compliance, HR, and reporting overhead that a Belarusian entity carries — even an HTP-resident one.

ODC becomes the right answer when

• Team size has stabilised above 20 and is trending toward 40 or more.
• The Belarus operation needs commercial decision rights — signing local supplier contracts, leasing office space, building its own employer brand presence.
• EOR margin (typically 8–15% of total monthly payroll for an established relationship) starts to materially exceed the cost of running a local entity.
• Operational sovereignty — equipment ownership, office leases, local vendor relationships — becomes important to the business.
• The structural HTP advantages would be larger as a direct resident than as a client of an HTP-resident EOR.

This is the section the linear how-to articles tend to skip. We’re foregrounding it because the conversion decision is more consequential than the conversion mechanics. The mechanics are well-understood. The decision is what foreign founders sometimes get wrong, by deciding too early or by deciding too late.

The HTP framework — why almost every serious ODC ends up there

Most foreign-owned ODCs in Belarus are residents of the High-Tech Park. The alternative — a standard Belarusian limited liability company without HTP residency — is structurally uncompetitive for IT operations of any meaningful scale.

The High-Tech Park is the special legal and tax regime created for IT companies in Belarus. As of 2026 it hosts over a thousand resident companies, providing the operational framework that most foreign clients ultimately work through whether directly (as an ODC) or indirectly (as an EOR’s client).

The substantive HTP benefits, in summary:

• 9% personal income tax on engineer wages (versus the standard 13%).
• Social fund contributions calculated on the average national salary, not the engineer’s actual full salary — this is the structural saving that compounds fast at scale.
• 0% VAT on most IT services exports.
• 9% corporate profit tax (versus the standard 20%).
• Reduced rates on dividends and royalties for residents.
• English-language commercial contracts permitted.
• Elements of English commercial law accommodated in commercial agreements.
• Simplified residency procedures for foreign IT specialists.

Qualification turns on whether the company’s principal activity falls inside the HTP-permitted activity list (software development and a number of related categories all qualify). The Ministry of Economy HTP overview has the current details. In practice, foreign-owned IT companies that meet the activity criteria almost always qualify. The application process is procedural rather than discretionary, but it isn’t instant — typically 30 to 60 days from filing, sometimes longer if the business plan triggers additional review questions.

The legal entity setup, step by step

The actual mechanics walked through honestly. Not a checklist — a narrative of how the work sequences and where the time goes.

Entity type

Most foreign-owned ODCs in Belarus are limited liability companies. 100% foreign ownership is permitted. Minimum charter capital requirements are trivially low. Joint-stock company structures exist but are rarely used for ODC purposes; the LLC is the standard answer.

Registration

Through the territorial unified registration body for the district where the entity will sit. Core registration is typically 5 to 10 business days from filing — if the document set is complete. The document set includes founding documents, founder identification (apostilled and translated where the founder is foreign), proof of legal address, and the charter. Getting the document set complete is the part that takes time; the registration itself is fast once you’re ready to file.

HTP residency application

Separate process, usually run in parallel with entity registration or immediately afterward. Application includes the business plan (specific format), activity classification, founding documents, and supporting attachments. Approval typically 30 to 60 days. The administration occasionally comes back with clarification questions — building in a two-week contingency for this is wise.

Banking account opening

This is the step where timelines stretch most often. Foreign-owned entities face KYC processes that vary materially by bank. Some Belarusian banks have established workflows for foreign-owned IT entities and onboard them efficiently in four to six weeks. Others apply heightened compliance scrutiny that runs eight weeks or longer. The practical lesson: pick the bank early, start the conversation in week one, not week six, and treat the banking relationship as the gating dependency it usually is.

Tax registration and currency control

Tax registration is standard and runs in parallel with the entity setup. Currency control compliance deserves a specific mention. Belarus operates a currency control regime that affects how foreign-owned entities move money in and out. Manageable, but it needs to be set up correctly from the start — your first inbound payment from the foreign parent will be reviewed under currency control rules, and a smooth pass on that review is largely about having registered the relevant agreements correctly at the outset.

Personnel hire and onboarding

Either fresh hires into the new entity or — more commonly for clients with established EOR-based teams — conversion of existing engineers from the EOR into the new entity. The conversion path is the typical scenario for the audience this article is written for, and it is covered in its own section below.

Honest framing on overall timeline: a clean setup typically runs 3 to 4 months end-to-end. A rushed setup runs 2 months and accumulates problems that surface in year one. The right pace is the unrushed pace.

The EOR-to-ODC conversion — the path most readers are on

This is the specific scenario that applies to most foreign clients who ask the ODC question — they already have engineers in Belarus through an EOR and are converting to a directly-owned entity. The mechanics are well-trodden but easy to get wrong.

The sequence that works

Set up the ODC entity and obtain HTP residency before terminating EOR contracts. This sounds obvious; it isn’t always done. The window between the EOR contract ending and the new entity’s first payroll is the window where engineers feel uncertain about their employment status, where small problems become big ones, and where attrition risk is highest. Don’t open that window if you can avoid it. Run the new entity in parallel for a transition period.

Negotiate transition terms with the existing EOR early in the process. Most EORs cooperate with conversions — they understand that a client moving to ODC is a sign they did their job well. Some try to extract additional margin during the transition (longer notice periods, transition fees, charges for assistance with paperwork). Plan for both. Read the existing EOR contract specifically for the termination and transition clauses before you start, not after.

Re-hire each engineer into the new entity with continuity of service preserved where possible. Belarusian labour law has specific rules around continuity of service, vacation accrual, and severance — getting this right matters for engineer morale and for legal hygiene. Most local labour counsel will guide this in detail.

Transfer equipment ownership if the EOR was the legal owner. Negotiate this as part of the transition; some EORs sell at book value, others request a small premium.

Re-paper the IP assignment chain. This is the moment to fix anything that wasn’t clean originally. The new chain runs engineer → ODC entity → foreign parent (or, if the ODC is the foreign parent’s directly-owned subsidiary, engineer → ODC, with the parent owning the ODC and therefore indirectly the IP). Either way, get the assignment language fresh and clean. Don’t carry forward language from the previous EOR contracts without reviewing it.

Communicate the change to engineers carefully. The anxiety engineers feel during an employer change is real and well-founded — even when nothing actually changes for them in terms of compensation or working conditions. Clear, early communication and individual conversations prevent the avoidable attrition we’ve seen at clients who handled this less attentively.

Common conversion mistakes

• Setting up the new entity but starting payroll before HTP residency is granted — which forces the entity to operate under non-HTP cost structures for the first quarter and erodes the conversion economics.
• Terminating EOR contracts before the new entity’s banking account is operational.
• Forgetting to re-paper the IP assignment chain. The old chain (engineer → EOR → foreign parent) breaks when the EOR exits. A new chain has to be in place before the transition completes.
• Not communicating early to engineers. By the time HR explains the change, anxiety has spread informally and some engineers are already in recruiter conversations.

Operational setup — what the entity actually runs

Beyond the legal setup is the operational stack the entity needs to function. Quick walk-through of the components and how foreign clients typically resolve each.

Office or remote

Belarusian IT in 2026 is largely remote-first. The default for engineering work is hybrid or fully remote, and an entity can run that way without strict physical office requirements. That said, a small Minsk office signals seriousness, creates a center of gravity for the team, and provides a credible address for visiting clients and partners. Most ODCs settle into a small office (200 to 500 square meters) in central Minsk districts — Niamiha, Centralny, the area around Pobediteley Avenue — housing 30 to 50 hot-desks for a team of 60 to 80 engineers. Office lease costs are meaningful but not punishing — $15 to $30 per square meter monthly is typical.

HR and payroll

Either built in-house with a hired HR manager (and a chief accountant, which is required by law) or outsourced to a local payroll provider. The hybrid is most common — local payroll provider handles compliance and processing, in-house senior HR business partner handles people management. Pure outsourcing works at a smaller scale; once the team is past 40 engineers, an internal HR presence becomes valuable.

Compliance and accounting

Labor code compliance, tax filings, and HTP reporting. A chief accountant is mandatory for the entity by Belarusian law — the role can be filled in-house or, more commonly at a smaller scale, outsourced to a local accounting firm with the in-house team handling oversight.

Equipment procurement and lifecycle

Most ODCs handle this in-house once they hit 30+ engineers. Below that, working with a local IT supplier on a managed basis is simpler. Equipment ownership becomes part of the entity’s balance sheet, with tax and operational implications, but is generally cleaner than the EOR-owned equipment alternative.

Ongoing recruitment

Some ODCs build internal recruiting teams once they reach 50+ engineers. Most continue to retain a relationship with a local recruitment agency for ongoing search work, particularly for senior and specialised roles. Internal recruiters in Belarusian IT cost $2,500 to $4,500 monthly gross at the senior level — affordable, but the case for in-house recruitment is about ongoing volume rather than cost. External IT recruitment typically runs at the standard percentage of annual gross at hire, with terms that favour predictable volume.

Tax and financial mechanics — what the savings actually look like

The numbers behind the conversion decision. Comparing an HTP-resident ODC running the same team that previously ran through an EOR.

The headline tax differences for an HTP-resident entity versus a non-HTP entity (the EOR is HTP-resident for most foreign clients, so the relevant comparison is HTP-ODC versus HTP-EOR):

• Personal income tax: 9% (HTP resident) — same in both ODC and EOR cases when the EOR is HTP-resident.
• Social fund: calculated on the average national salary base — same in both cases.
• VAT on IT exports: 0% for both.
• Corporate profit tax: 9% — applies to both, calculated on the entity’s profits.
• EOR margin: 8–15% of total monthly payroll for an established relationship. This is the line that disappears when you move from EOR to ODC.

The structural saving in the ODC model is the EOR margin. Everything else is broadly comparable when both sides are HTP-resident.

Worked example

A 25-engineer team at $5,000 average gross monthly. Total gross payroll roughly $125,000 monthly.

EOR-routed total cost (gross payroll, employer-side contributions, benefits, EOR margin): approximately $175,000 to $190,000 monthly. The exact figure depends on the benefits richness and EOR margin tier.

HTP-resident ODC running the same team (same gross, same employer-side contributions, same benefits, no EOR margin, plus the entity’s own running costs — office, accounting, HR, equipment): approximately $145,000 to $160,000 monthly.

Monthly difference: roughly $20,000 to $30,000. Annually: $240,000 to $360,000.

Setup costs that offset this in year one: roughly $30,000 to $50,000 in entity setup, banking onboarding, HTP residency application, legal fees, office lease deposits, equipment purchases, and the time cost of the founder’s attention. Crossover from net cost to net saving typically occurs 12 to 18 months from setup, sometimes faster for larger teams.

Below 15 engineers, the math doesn’t work — EOR is cheaper end-to-end. Above 40 engineers, ODC is significantly cheaper. Between 20 and 40 engineers is the zone where the decision turns on factors beyond pure cost — operational control, employer brand, the strategic importance of the Belarus operation to the foreign parent.

Where the timeline blows up — the honest section

Where setup projects go wrong: observations across multiple conversions in 2024–2026.

Banking is the single biggest delay vector

Foreign-owned entities can face KYC processes that take four to eight weeks at the slow end. Some banks have efficient foreign-IT-client workflows; others do not. The practical lesson is to start the banking conversation in the first week of the setup, identify two or three candidate banks, and run the relationship-building in parallel with the entity registration. Treating banking as an afterthought is the single most reliable way to push the timeline from four months to seven.

Founder document apostille and legalization

Foreign founders consistently underestimate how long it takes to gather their home-jurisdiction documents. Notarised and apostilled copies of foundation documents, passport copies, proof of address, sometimes corporate good-standing certificates — all need to be obtained in the home jurisdiction, then apostilled, then translated into Russian (sworn translation by a recognized translator), and only then submitted in Belarus. Build in four weeks for this. It takes six.

HTP residency review questions

The HTP administration occasionally comes back with clarification questions on the business plan, particularly around activity classification or projected revenue. These questions aren’t a sign of trouble — they’re routine for non-standard cases. Build in two weeks of contingency for an exchange of clarifications.

Currency control on the first inbound payment

The entity’s first cross-border inbound payment from the foreign parent — typically the initial capitalisation or the first invoice — sometimes gets held by the bank for compliance review. Anticipated, not surprising, but it’s a process step that runs a few days to two weeks. Plan for it; don’t be caught with payroll due and incoming capital still under review.

Existing EOR cooperation

Some EORs cooperate fully and helpfully with conversions; others extract additional margin during the transition window. Read the existing EOR contract, specifically the termination, notice period, and transition cooperation clauses, before you start the conversion. Plan accordingly.

Engineer communication

The gap between “we’re moving you to a new entity” and “actually, nothing meaningful changes for you” is the gap where avoidable attrition happens. Brief engineers early, individually where possible. Pay particular attention to the senior contributors whose departures during a conversion would pose the greatest delivery risk. Some of them will be the most anxious about the change, precisely because they have the most to lose if things go wrong.

The bottom line

Setting up an ODC in Belarus is a project, not a decision made once and executed. Done well, it converts a 20-to-40-person Belarusian team from an EOR cost stack to a structurally cheaper, more controlled setup, with savings that compound year over year and a permanent base for future scaling. Done poorly, it produces a four-month project that becomes a seven-month project, an engineer cohort that loses confidence in the transition, and an IP chain that has to be cleaned up months after the fact.

The single most useful preparation is the question we opened with: Do you actually need an ODC right now, or are you 12 months early? If the answer is “early,” stay on the EOR model and revisit. If the answer is “now,” plan for the four-month case, build in contingency for six, and start the banking conversation before you start the entity registration.

At Recruitment.by we work with foreign clients on both sides of this decision — the EOR-based teams growing toward the conversion question, and the established ODCs running ongoing hiring. On the structural side of HTP residency, our HTP residency support and joining HTP services cover the application process and operational onboarding. For the broader organizational and compensation design that goes with scaling an ODC, our HR consulting handles the strategic side. Ongoing IT recruitment into the new entity, and supporting payroll and PEO services during transition, run alongside. For a conversation about your specific case — whether you’re at or beyond the threshold, or just wanting to model the trajectory — contact us.

NDA and IP Assignment Agreements in Belarus: Protecting Code When Hiring Remote Developers

Here’s a sentence that has cost companies their own product: “We paid for it, so we own it.” When the developers writing your code sit in Belarus, that assumption is wrong — or at least, it isn’t automatically right.

The US concept of “work made for hire,” where the employer owns the code the moment it’s written, is not how Belarusian law works. In Belarus, the exclusive rights to what your developer creates belong to your company only if you’ve explicitly said so — in the employment contract, or in a separate IP assignment agreement. Skip that step, or rely on a contractor arrangement with no assignment in it, and the rights can sit with the developer rather than with you. You can pay in full for code you don’t actually own.

Add the question of confidentiality on top — is your source code and roadmap genuinely protected if a developer walks out the door? — and you have two agreements that decide whether you control your most valuable asset or merely hope you do. This guide explains how NDAs and IP assignment actually work in Belarus, the work-for-hire mistake that catches foreign companies out, and what it takes to protect your code when the people writing it are remote. One note up front: this is general information from people who recruit in this market, not legal advice for your specific agreements — for those, use a qualified Belarusian IP lawyer.

The mistake that costs companies their code — you don’t automatically own it

Start with the assumption that does the damage, because almost everything else follows from clearing it up. Foreign companies — especially those used to US rules — tend to believe that paying a developer means owning what the developer produces. Money changes hands, code gets written, the code is yours. Under US “work made for hire,” that’s broadly true for employees. In Belarus, it isn’t the default at all.

Under Belarusian law, the exclusive rights to a work created by an employee belong to the employer only if that’s specified in the employment contract or a separate agreement. There’s no automatic transfer at the moment of creation. The Civil Code governs this — its intellectual-property section was reissued in a new edition that took effect in November 2024, which among other things enshrined a “presumption of creativity”: a work is presumed to be the product of the author’s creative effort unless shown otherwise, and the author holds the exclusive rights by default. The copyright term itself now runs for the author’s life plus seventy years. The thread through all of it: the rights start with the creator, and they only move to you if a document moves them.

The consequence is blunt. Without explicit assignment, you may be paying for code whose rights you don’t hold — effectively licensing your own product from the person you hired to build it, without either of you having meant that to happen. This isn’t a technicality to tidy up before an audit. It’s the difference between owning what you built and discovering, at the worst possible moment, that you don’t.

IP assignment — how to actually own what you pay for

The fix is straightforward in principle and worth getting exactly right in practice. IP assignment is the explicit transfer of the exclusive — that is, the economic — rights from the creator to your company. It can live inside the employment contract, or stand as a separate IP assignment agreement, but either way it has to be explicit, written, and signed. A vague gesture at ownership doesn’t do the job; the assignment has to actually say that the rights move.

A good assignment does a few specific things. It clearly transfers the exclusive rights to the work — the source code, the documentation, the related materials — to the company. It addresses the relationship between the background IP a developer brings with them (their pre-existing tools, libraries, prior work) and the foreground IP created for you, so the line between the two is clear. And it accounts for moral rights: in Belarus, as in much of the world, the author’s personal non-property rights, such as attribution, sit separately from the assignable economic rights and aren’t transferred the same way. A well-drafted assignment is written with that distinction in mind rather than pretending it away.

Two modern points are worth building in. First, AI-generated code: when developers use AI tools, who owns the output is a genuinely unsettled question in 2026, so the agreement should address AI-assisted work explicitly rather than leaving a gap. Second, timing. The assignment should be signed before work starts, not retrofitted once the code exists — a developer who has already written your core module and not yet assigned the rights is in a very different negotiating position from one signing an assignment on day one. Get the paperwork done at onboarding, alongside everything else.

Employee vs contractor — where the rights slip away

The ownership rule has two versions, and the difference between them is where most companies get hurt. It turns on whether your developer is an employee on an employment contract or a contractor on a civil one.

For an employee, the rights transfer to the employer only if the employment contract or a separate agreement says so. So the employment contract has to either contain the assignment or be paired with one — present it as a given, but make sure the document actually exists. For a contractor working under a civil or service contract, the position is sharper still: the rights remain with the creator unless they’re assigned. There’s no version of “the contractor obviously meant to hand over the code” in Belarusian law. If the service contract doesn’t assign the rights, the contractor keeps them, however much you paid.

Here’s why this matters so much for remote hiring specifically: a great many Belarusian developers are engaged as contractors, not employees. That’s precisely the arrangement where IP most easily stays with the developer, because the assumption that payment equals ownership is at its most wrong and the default most firmly favours the creator. Identify which relationship you actually have, and make the assignment explicit either way — but treat the contractor case as the one to be most careful about, because it’s the one that quietly costs companies their code.

NDAs and the trade-secret regime — confidentiality that actually holds

Owning the code is half the protection. The other half is keeping your confidential information — source code, architecture, roadmap, client data — from walking out with a departing developer. Here the news starts good: confidentiality clauses and NDAs are generally enforceable in Belarus. Then comes the catch that most employers miss.

Information is only protected as a trade secret if the company has actually taken steps to keep it secret — a complex of measures the law expects, often called the trade-secret regime. This isn’t a formality. The Supreme Court’s intellectual-property board has held that information which was freely accessible, or which the owner took no real measures to protect, simply doesn’t qualify as a protected trade secret, regardless of what a piece of paper says. An NDA sitting on top of nothing is an NDA resting on air. The signature doesn’t create the protection; the regime does, and the NDA enforces it.

So what does the regime look like in practice? You define what counts as confidential, document it (commonly in an internal regulation on trade secrets), limit access to the people who genuinely need it, and sign NDAs with everyone who sees the protected information — employees and contractors alike. The NDA itself should define what’s confidential, set the scope and how long the obligation lasts (during the engagement and after it ends), and spell out the remedies for breach. Built that way, the NDA does its job because there’s a real trade secret underneath it. Signed without the regime behind it, it’s a comfort blanket, not a defence.

Why you can’t lean on non-competes

One more expectation worth correcting, because companies often reach for it. A non-compete clause — the kind that tries to stop a departing developer from joining a competitor or starting a rival — is subject to strict limitations under Belarusian law. You cannot rely on it the way some US companies do, and treating it as your main line of defence is a mistake.

The protection has to come from the two tools that do work: a strong IP assignment, so the departing developer takes no ownership of your code with them, and a strong confidentiality regime, so they can’t lawfully use or disclose your secrets. Don’t build your strategy on a non-compete that may not hold. Build it on the assignment and the trade-secret regime, which do.

The practical checklist — protecting code when hiring remote in Belarus

None of this is exotic. It’s standard practice, and the companies that come unstuck are almost always the ones who assumed US rules applied. The short version:

• Identify the relationship first. Employee or contractor — the IP rules differ, and the contractor case is the higher-risk one.
• Assign IP explicitly, in writing, before work starts. In the employment contract or a separate agreement; cover source code, documentation, and the line between background and foreground IP.
• Address AI-assisted code in the assignment, since ownership of AI output is still unsettled.
• Build a trade-secret regime, not just an NDA. Define and document what’s confidential, limit access, and take the measures the law actually expects.
• Sign NDAs with everyone who sees confidential information — employees and contractors — with clear scope, duration, and remedies.
• Don’t rely on non-competes. They’re strictly limited; lean on assignment and confidentiality instead.
• Keep the paperwork trail. Who signed what, and when. Clean chain-of-title is exactly what an investor or acquirer will ask to see.

Two scenarios from practice

Scenario A. The contractor who owned the code

A foreign startup engaged a Belarusian developer as a contractor to build a core module, paid in full, and shipped the product. The service contract said nothing about IP assignment — the founders assumed, as founders often do, that paying for the work meant owning it. The product worked, the company grew, and nobody thought about it again.

Then an investor’s due diligence asked for clean chain-of-title to the code, and the gap opened up. Under the civil contract, with no assignment, the exclusive rights to that core module had stayed with the developer the whole time. What should have been a single signature at the start became a renegotiation under pressure, mid-financing, with the developer now holding leverage nobody had intended to give them. The deal survived, but it was a bad few weeks and a worse precedent. The lesson is plain: with a contractor in Belarus, paying for the work is not the same as owning the rights. The assignment has to be explicit — and it costs a signature at the start or a great deal more later.

Scenario B. The NDA that held because the regime was real

A company hiring Belarusian developers did the unglamorous groundwork before it needed to. It defined its confidential information, wrote it into an internal trade-secret regime, limited access to the codebase and the product roadmap to the people who actually needed it, and had every developer sign an NDA tied to that regime. It felt like over-preparation at the time.

It wasn’t. When a developer left for a role at a competitor, the confidentiality obligations were enforceable — not because of the signature alone, but because the company had taken the real measures the law requires, so the protected information genuinely qualified as a trade secret. The NDA wasn’t a standalone scrap of paper; it sat on a foundation that made it mean something. The lesson pairs with the first: an NDA is only as strong as the trade-secret regime beneath it. Build the regime, and the NDA does its job when it matters.

Own it on purpose, protect it for real

When you hire remote developers in Belarus, owning your code and protecting your secrets aren’t automatic — they’re the result of two agreements done properly. IP assignment, because Belarusian law doesn’t hand you ownership the way US work-for-hire does; you have to take it explicitly, and most of all with contractors. And an NDA built on a real trade-secret regime, because confidentiality is only enforceable when you’ve taken the measures the law actually requires. Non-competes won’t save you. The assignment and the regime will.

The companies that keep control of their code are the ones that signed the right paperwork before the first line was written — not the ones who discovered the gap during due diligence or after a developer left. It’s a signature at onboarding versus a crisis later, and the difference between the two is entirely a matter of doing it on purpose, up front. Own it deliberately. Protect it for real. Everything else is hoping.If you’re hiring developers in Belarus and want to do it so your code and your secrets are actually protected — the right agreements, signed at the right time, for the relationship you actually have — get in touch with us. We place IT professionals across the Belarusian market and help employers structure hiring that holds up — including the onboarding paperwork that keeps your IP yours. One more time, because it matters: this article is general information, not legal advice. For your specific NDA and IP assignment agreements, work with a qualified Belarusian IP lawyer who can draft for your situation.

Stock Options and Employee Equity for Belarusian IT Employees: What’s Legally Possible

Equity is a standard part of the package in tech now. Stock options at a startup, RSUs at a scale-up, a slice of ownership meant to tie talented people to the company’s success. For Belarusian IT engineers — among the most sought-after in the region — equity offers are increasingly common, and almost always from a foreign employer or parent company.

That last detail is where the questions begin. Can a Belarusian employee legally receive and benefit from foreign equity? What happens at tax time? Does currency control complicate it? Most equity guidance online is written for someone sitting in San Francisco or Berlin, and it quietly assumes a tax and legal context that simply doesn’t hold when the employee is in Minsk.

This article looks at what’s actually possible — and what’s actually required — for a Belarusian IT employee with equity. The mechanics of options and RSUs, the Belarusian tax reality of foreign-source income, the currency and documentation side, and an honest bottom line: it’s possible and increasingly normal, but it rewards understanding the rules before you sign, not discovering them at tax-return time. One caveat up front, and we’ll repeat it, because it matters: equity taxation is genuinely complex and turns on the specifics of each grant. This is general information from people who recruit in this market — not tax or legal advice for your particular situation.

The mechanics — options vs RSUs, and how equity actually works

Before the Belarus layer, the universal part: what you’re actually being offered. Two instruments dominate, and they behave differently.

Stock options give you the right to buy shares at a fixed price — the strike price — once they vest. If the company’s value climbs above that strike, the options are worth something; if it doesn’t, they aren’t. RSUs, restricted stock units, work the other way around: they’re a promise of actual shares delivered to you on vesting, with nothing to buy. An RSU keeps some value unless the share price falls to zero, which makes it the lower-risk of the two from the employee’s side. Options carry more upside and more risk; RSUs carry steadier, smaller value.

Both come with vesting — the schedule that earns you the equity over time, typically three to five years, often with a one-year cliff. The cliff means nothing vests in the first year; stay past it and the equity starts accruing, usually monthly or quarterly, until it’s fully vested. So the lifecycle runs grant, then vesting, then — for options — exercise, then eventually sale. Each of those points can carry tax consequences, and understanding which instrument you hold and where you are in its lifecycle is the foundation everything else sits on. Get that clear first; the Belarusian layer attaches to specific points along it.

The foreign-company reality — why this is almost always cross-border

Here’s the fact that shapes everything else for a Belarusian employee, and the one the Western guides skip entirely. Your equity almost always comes from a foreign company — a foreign startup, the foreign parent of a local entity, a foreign client that became an employer. That single fact is what pulls Belarusian rules into the picture.

Foreign-issued equity is foreign-source income and foreign property. Which means the rules that apply to it aren’t only the issuing company’s home-country rules — they’re also Belarus’s rules on how its tax residents are treated on income and assets from abroad. And tax residency is a low bar to clear: spend more than 183 days in Belarus in a calendar year and you’re a Belarusian tax resident, taxed on your worldwide income. For most Belarusian IT employees, that includes the equity. So the mental model isn’t “I have shares in a US company, so US rules apply.” It’s “I’m a Belarusian tax resident receiving foreign-source income, so Belarusian rules apply too” — on top of whatever the issuing country does.

The tax reality — foreign-source income, self-declared

This is the central section, and the one to read most carefully. Income that a Belarusian tax resident receives from a foreign source — including income in kind, such as shares or securities — is foreign-source income subject to Belarusian personal income tax, at the standard rate of 13%. (The High-Tech Park rate has historically been lower and has shifted in recent years, so the exact rate for HTP-linked employees is worth confirming for the current year; the IT-sector tax picture is covered in our overview of taxes in IT companies in Belarus.)

The part that surprises people most is who handles it. Foreign-source income is self-declared. The foreign employer doesn’t withhold Belarusian tax — it can’t — so the obligation sits with the employee. In practice that means filing a personal income tax return by 31 March of the year after the income arose, and paying the tax by 1 June. Miss those and the problem is yours, not the company’s. Equity income doesn’t arrive with Belarusian tax already handled the way a salary does; it arrives as something you have to declare yourself.

Then there’s the currency question, which has a precise answer. Foreign-currency amounts are converted into Belarusian rubles at the official National Bank exchange rate on the date the income is actually received — and for income in kind, such as shares, that date is when the shares are transferred to you. So the value you declare isn’t a round number you choose; it’s the market value on a specific date, converted at a specific rate. Belarus also has a wide network of double-taxation treaties — around seventy — which matter where you’ve also paid tax abroad, because they bear on whether and how you can credit that foreign tax. That, too, is grant-specific.

Here’s where the honesty has to be loudest. Exactly when the taxable moment falls — at vesting, at exercise, at sale, or some combination — and exactly how the value is measured at that moment is genuinely intricate, and it varies by instrument and by the structure of the plan. This is not a place for a rule of thumb. The principle is clear and worth internalising: foreign equity income is taxable in Belarus and you declare it yourself. The application to your specific options or RSUs needs individual professional advice. Anyone who tells you otherwise about a complex cross-border equity grant is overselling their certainty.

The currency and documentation side

Beyond the tax itself, there’s the practical machinery of holding foreign shares from Belarus — and it rewards being organised from the start rather than scrambling later.

Receiving, holding, and eventually selling foreign shares — usually through a foreign broker — sits within Belarus’s currency-regulation framework, the same framework that governs other cross-border financial flows. It doesn’t make equity impossible; it makes it something to handle deliberately. And the documentation burden is real. To declare correctly you’ll want the grant notice, the vesting reports, the broker statements, and proof of any foreign tax you’ve paid — kept from the moment of grant, not assembled in a panic the following March. Reconstructing a multi-year vesting history from memory at tax time is exactly the kind of avoidable pain that turns a good opportunity into a stressful one.

One more practical thread: because tax residency turns on days of presence, anyone whose work involves real mobility — time abroad, relocations, remote stints in other countries — should keep records of it. Border crossings, travel documents, the basic trail. Residency can be the difference between owing Belarusian tax on the whole grant and owing it on part, and the records are far easier to keep as you go than to reconstruct after.

What’s possible — and what to be realistic about

So, the honest payoff to “what’s legally possible.” It is possible, and increasingly normal, for a Belarusian IT employee to receive and genuinely benefit from foreign equity. This isn’t a grey area to be nervous about; it’s an established part of how international tech compensates talent, and Belarusian engineers are well inside that world.

What makes it work smoothly is unglamorous: a clearly documented grant from a reputable foreign employer, understood up front, with the tax and currency steps planned rather than discovered. What to stay realistic about is equally plain. The tax is self-declared, and that obligation is yours. The value is often illiquid — shares in a private company can’t be turned into cash until a liquidity event like an IPO or acquisition, which may be years away or may never come. The FX and documentation steps are real work. And the rules can change, as rules do. None of that makes equity a bad deal. It makes it a real one — an opportunity that rewards going in informed rather than dazzled by the headline number.

For employers and recruiters — offering equity to Belarusian talent

The other side of the table matters too. Foreign companies recruiting Belarusian IT talent can offer equity, and increasingly need to in order to compete with the firms that already do. But there’s a right way to do it, and it isn’t just attaching a big notional number to the offer.

The companies that get value from equity offers to Belarusian hires are the ones that present them clearly — with documentation the employee can actually use for their Belarusian obligations, and with honest framing about tax, vesting, and liquidity. The recruiter’s role in that is real: explaining the equity component credibly, setting realistic expectations, and not overselling. A candidate who understands their offer — including the Belarusian tax and currency reality — values it correctly and doesn’t feel misled a year later when the tax return lands. That’s the same standard of clarity we bring to placing IT professionals generally; our IT recruitment services are built around matching strong candidates with roles where the whole package, equity included, is understood on both sides. And because the legal frame around hiring matters as much as the offer, our guides to the probationary period in Belarus and to background checks and candidate verification cover the adjacent ground every employer hiring here should know.

Possible, increasingly normal, and worth understanding first

Equity for Belarusian IT employees is legally possible and increasingly part of the landscape — almost always foreign-sourced, which is exactly what brings Belarusian tax and currency rules into play. The income is taxable and self-declared, the value converts to rubles at the National Bank rate on the date of receipt, and the documentation matters from the very first grant notice. The taxable-event mechanics are genuinely complex, so individual professional advice on a specific grant isn’t a nicety — it’s the sensible default.

For employers, offering equity to Belarusian talent is a competitive advantage when it’s done clearly and documented honestly. For candidates, it’s a real opportunity — best understood before signing rather than puzzled over a year later. The headline number on an equity offer is where the conversation starts. What it means for someone sitting in Belarus is where the real understanding begins.

If you’re a company recruiting Belarusian IT talent and want to build offers — equity included — that candidates understand and value correctly, or you’re navigating the hiring landscape here and want a partner who knows it, get in touch with us. We place IT professionals across the Belarusian market and help employers structure offers that hold up on both sides. A quick, important note: this article is general information, not tax or legal advice — for your specific equity grant, speak to a qualified tax professional who can see the plan documents.

Background Checks in Belarus: Legal Limits and Practical Alternatives for IT Hiring

Hiring a senior developer in Minsk. The standard playbook from back home kicks in. Identity verification. Prior employment confirmation. Criminal record check. Social media review. Maybe a credit check for a senior position. You’ve done this a hundred times. Then the recruiter sends back a polite note. Most of that isn’t allowed under Belarusian law for an IT role. The criminal record check is reserved for specific regulated positions — software developer isn’t one of them. The consent form needs statutory language you don’t have. And the “legitimate interest” basis you’d lean on under GDPR doesn’t exist as a legal basis under Belarusian data protection law at all.

Welcome to the gap between what feels like normal hiring due diligence and what Belarusian law actually permits. It’s wider than most foreign IT employers realise. It’s also entirely workable, once the framework is designed around it rather than retrofitted after the first candidate quietly declines and walks away.

Below: the legal framework that actually applies, what Belarusian law permits and what it doesn’t, the criminal record check question that catches almost every foreign client at kickoff, the cross-border data transfer issue that catches EOR setups, and the practical alternatives that produce better hiring decisions than US-style document screening ever did. Plus two possible cases from practice — including one where the playbook had to be torn up after six weeks of wasted recruitment effort.

The three laws that actually govern this

Three pieces of Belarusian legislation control what an employer can and can’t do when screening candidates. Foreign IT employers typically know about none of them at the kickoff call. Worth getting straight before the first job offer goes out.

The Labor Code

Article 26 lists the documents an employer can require from a candidate. The list is finite. Passport (or other ID). Employment record book. Education certificate. Military registration documents where applicable. Social insurance certificate. That’s essentially it. Anything outside this list — including criminal record certificates for a general IT role — needs a specific legal basis. You can’t add documents to the list as a contractual condition just because your global HR policy says so.

The Personal Data Protection Law (PDP Law)

Law No. 99-Z of 7 May 2021. GDPR-structured, but materially different in critical respects. The biggest difference for employment screening: legitimate interest isn’t a legal basis for processing personal data under Belarusian law, the way it is under GDPR. Consent is the practical foundation for almost everything an employer does beyond what Article 26 directly requires. The law reaches Belarusian and foreign employers handling Belarusian residents’ personal data — extraterritorial in the same way as GDPR is, with the same implications for offshore EORs and parent companies.

Edict No. 422 of 28 October 2021

The administrative framework. Supervisory authority is the National Personal Data Protection Center. Practical responsibilities for the data controller — your employer entity — include maintaining processing records, documenting consent, securing data transfers, and being able to demonstrate compliance on request. The Edict and its implementing acts are tracked on

The Belarusian national legal portal; the Center publishes its own guidance and supervisory materials at cpd.by.

What you can actually screen for

The operational core. What’s permitted — with the right consent framework — for an IT role in Belarus. Read this carefully. The shape is narrower than you think going in, and broader than you’d guess once you see it laid out.

Standard verification under Article 26

• Identity through passport. Part of the standard document set. No additional legal hook needed.
• Education certificates and diplomas. Also Article 26. Verifiable directly with the issuing university — most universities in Belarus and abroad will confirm a degree on request.
• Employment record book confirming prior Belarusian employment. The Belarus-specific document the candidate has. You look at it. Standard.

Permitted with proper consent

• Reference checks with prior employers. Written consent, prior employer willing to engage. Works well when the prior employer is responsive — which in the Belarusian IT market they often are, because the market is small and people stay in touch.
• Verification of professional certifications. AWS. Microsoft. Google Cloud. ISTQB. CKAD. The candidate cited them; the certifying body confirms them. Standard practice.
• Review of publicly accessible social media. LinkedIn, public GitHub, public X. Even publicly accessible content is still personal data being processed — needs consent and needs to be proportionate to the role.
• Technical assessments. Coding challenges, system design sessions, take-home projects. The primary signal for IT hiring, and entirely outside the personal data minefield.

Requires specific statutory basis (not available for general IT roles)

• Criminal record certificate. Only for positions in state security, law enforcement, education, healthcare, finance, customs, and a few other specifically regulated sectors. IT developer, designer, project manager, product manager, QA engineer, data engineer — not on the list.
• Credit history. Generally not permitted for employment without a specific regulatory basis. Senior finance roles within regulated financial institutions are the narrow exception.
• Medical examinations. Only where the role triggers a statutory medical-fitness requirement. Not a generally available employer tool.
• Polygraph or psychological testing. Heavily restricted. Requires specific statutory authority for the role. The number of IT roles with that authority is approximately zero.

The criminal record question — the mistake every foreign client makes

Foreign IT employers ask for this constantly. Almost always inappropriate. Worth its own section because the mistake is so common, the legal exposure so avoidable, and the conversation so tedious to have on day one of every kickoff.

The Belarusian criminal record certificate comes from the Ministry of Internal Affairs. Around twenty working days to issue. Routinely issued to individuals for their own purposes: visa applications, immigration, foreign employment. The employer-side question is whether you can require it as a hiring condition.

For most IT roles, no.

• There’s no general “we run criminal checks on everyone” model in Belarusian employment law. The check is statutorily tied to specific role categories. Software developer, product manager, designer, QA engineer — those categories aren’t on the list. There’s no umbrella authority for an employer to demand it across the board.
• Asking anyway, as a contractual condition, creates two layers of exposure. PDP Law exposure for collecting personal data without lawful basis. Labor Code exposure for requiring documents outside the Article 26 list as a hiring condition. Neither is theoretical.
• Voluntary provision is a different analysis. The candidate can voluntarily obtain and provide the certificate. The employer can voluntarily receive it. Different rules, different exposure. But genuine consent has to be genuinely voluntary — not extracted under threat of withdrawn offer.
• The narrow exceptions: roles touching state secrets, certain financial-services positions regulated by the National Bank, security roles in critical infrastructure, healthcare-adjacent IT roles handling sensitive medical data. Each requires its own analysis.

This comes up in almost every kickoff conversation with a new foreign IT client. The instinct comes from US, UK, or German hiring practices where pre-employment screening is the cultural default and nobody questions it. In Belarus the default is narrower. The framework is workable — but “run a criminal check on everyone” isn’t the route in, and trying to make it one creates problems faster than it solves them.

Social media checks 

Less black-and-white than the criminal record question. Still tightly regulated. Worth understanding before the recruiter does what feels like normal due diligence and creates a problem nobody noticed.

• Publicly accessible content (LinkedIn, public X, public GitHub) — generally reviewable. But the review processes personal data. Consent and proportionality still apply. You don’t get to wave them off just because the content was visible.
• Private content — off-limits. Friends-only Facebook, locked-down Instagram, private profiles. Attempting access through deception or pretexting creates clear PDP Law liability, and creates an unwinnable conversation with the candidate if it surfaces.
• Cached, archived, or historical content — same rules as live content. Findability isn’t the same as lawful processability. The fact that a Google search turns up a forum post from 2014 doesn’t make it a free game.
• Proportionality. Senior leadership in a public-facing role can justify deeper review. Backend developers can’t. The PDP Law requires the controller to demonstrate the legal basis and the proportionality of the processing — both, not either.
• Documentation. The Center can ask the controller to demonstrate compliance. “We looked at their LinkedIn” needs to fit into a documented framework — purpose, legal basis, retention period.

Cross-border data transfer — the thing that catches EOR setups

The aspect that catches multinational employers and offshore EOR providers more than any other. Personal data of Belarusian residents flowing to a foreign parent, an offshore HRIS, a US-based recruitment agency, an EOR provider sitting elsewhere — all regulated under the PDP Law. None of this is optional.

The framework requires the destination jurisdiction to provide an “adequate level of protection” for data subjects’ rights. Belarusian adequacy criteria aren’t identical to GDPR’s. Practical groupings:

• EU member states. Generally treated as adequate. Council of Europe Convention 108 membership matters here.
• EAEU member states — Russia, Kazakhstan, Armenia, Kyrgyzstan. Explicitly treated as adequate by the framework.
• United States. More nuanced. Depends on the specific entity, contractual safeguards in place, and type of data flow. Don’t assume — verify.
• Other destinations without adequacy — specific contractual safeguards required, or explicit informed consent of the data subject for the transfer.

Practical implication for foreign IT employers. If you’re a US tech company hiring Belarusian developers through a Belarusian EOR, the background screening data flow has to be designed for adequacy from day one. Retrofit fixes are awkward. Experienced Belarusian recruitment partners build this into their workflows automatically. Our EOR and payroll services are structured around exactly this compliance architecture — including the data-flow design for cross-border HR processes.

What actually works for IT hiring — the practical alternatives

Where the article earns its keep. Real techniques that work within the legal framework — and that produce better hiring outcomes than the document-heavy screening foreign IT employers default to.

Technical screening as the primary signal

For IT hiring, this is the single most predictive signal you can generate. Hands-on technical assessments. Live coding interviews. System design discussions for senior roles. Take-home projects with realistic scope. Pair programming sessions with the team the candidate would join. Public GitHub review where the candidate has meaningful contributions. None of this touches the personal data framework. All of it is more predictive of actual on-the-job performance than any document review. Foreign employers underweight this. Belarusian employers don’t.

Reference checks that actually work

Direct calls with prior managers, with the candidate’s written consent and the prior employer’s willingness to engage. Confirming employment dates, role, scope, reason for leaving. Asking specific behavioural questions instead of generic “would you hire them again” prompts — which produce vague positive answers regardless of actual performance. Cross-checking the candidate’s narrative against multiple independent reference points. Allowed. Works. Underused because it takes time.

Identity and credential verification

Article 26 document review handles identity and prior Belarusian employment. For credentials, verify directly with the issuing body — Microsoft, AWS, Google Cloud, ISTQB, vendor certification authorities. Education verification through the university. LinkedIn cross-check on dates, roles, scope using publicly accessible content. All inside the framework.

The probation period as your real safety net

Belarusian labour law allows probation periods of up to three months for most positions. Sophisticated Belarusian IT employers treat the probation period as the real background check — actual performance on actual work, which is more predictive than any document. The employer can terminate during probation with three days’ notice and minimal documentation. Build the probation period into your hiring framework deliberately and you get the equivalent of due diligence without the personal data exposure. Most foreign clients underuse this. The ones who get it right structure performance milestones at thirty, sixty, and ninety days, and treat the decision at day ninety as the real hiring decision.

Working with an experienced local recruitment partner

Belarusian senior IT talent is a relatively small market. Senior developers in Minsk are largely known quantities within the local community — references travel through industry networks rather than through formal channels. A local recruitment partner with established relationships can vouch for candidates based on long-term market knowledge no foreign recruiter can replicate. Concerns from prior placements surface naturally. Our IT recruitment service and HTP recruitment specifically are built around exactly this kind of local-market depth. Hard to retrofit; obvious in the results.

HTP-specific considerations

Brief but worth flagging — the firm’s audience overlaps heavily with Hi-Tech Park residents.

Hi-Tech Park residency simplifies many HR processes and brings real tax benefits. It does not change the PDP Law framework. HTP residents handling personal data operate under the standard constraints — same consent requirements, same Article 26 limits, same cross-border transfer architecture. HTP’s flexibility on labour terms (foreign worker hiring, contract types, remote work) doesn’t extend to relaxing personal data processing rules. Some new HTP residents assume residency benefits cover this too. They don’t.

Our HTP residency support covers the application and entry process. The HR processes inside the HTP framework still follow the standard PDP Law architecture.

The consent document — where most of the legal work lives

The single document doing most of the heavy lifting in any IT screening process. Get this right and the rest of the framework holds together. Get it wrong and you’ve built a hiring process on sand.

A working consent for personal data processing in IT hiring should:

• Identify the data controller — the employer entity, or the recruitment agency where the agency holds controller status.
• List the categories of personal data being processed. Identity data. Contact data. Professional data. Educational data. Reference data. Specific, not generic.
• State the purposes for processing. Recruitment evaluation. Employment relationship. Payroll. Regulatory compliance. Each purpose stated, each justifiable on its own.
• Identify the legal basis — consent under the PDP Law, plus statutory basis for Article 26 data where applicable.
• List third parties who will receive the data. EOR provider. Payroll provider. Parent company. Recruitment agency. Background verification provider where used. All named.
• Specify cross-border transfer destinations and the legal basis for transfer. Adequacy, contractual safeguards, or explicit consent.
• Set the retention period explicitly. For unsuccessful candidates, only as long as necessary for the recruitment process and any defensive purpose — six to twelve months is a typical range. For successful hires, the data shifts into the employment-relationship framework.
• Inform the candidate of their PDP Law rights. Access. Correction. Deletion. Withdrawal of consent. Each spelled out.
• Allow the candidate to consent to specific processing types separately where appropriate. Social media review as a discrete opt-in, for example.

Drafting that doesn’t meet these basics creates PDP Law exposure. We’ve seen consent forms drafted by foreign HR teams that wouldn’t survive a first read by the Personal Data Protection Center. The standard isn’t aspirational — it’s the operating baseline. Anything less and you’re relying on the Center being too busy to look.

Two possible scenarios 

Scenario A. The US fintech that learned the hard way

US fintech, series B, rolling out a global hiring program. Standard internal policy: criminal background check required for every role, every country, no exceptions. The US-based recruiter sent the consent form to the first Belarusian senior developer candidate — strong technical fit, six weeks of pipeline work behind them. The candidate read the form. Declined politely. Withdrew from the process. The recruiter flagged the issue. Five other shortlisted candidates raised the same concern in the next ten days. We were brought in to redesign the screening framework for Belarus. Keep the technical assessment depth — the part that actually produces signals. Keep the reference framework. Dropped the mandatory criminal check. Restructured the consent document to meet PDP Law standards. The role filled six weeks later. The framework now applies across the company’s other CEE hiring.

Scenario B. The Berlin scale-up with the proper EOR setup

Berlin-based scale-up hiring twelve Belarusian developers through a Belarusian EOR. German hiring instinct centred on prior-employer references as the primary signal. We helped structure the consent framework to meet PDP Law standards. Set up the cross-border data transfer architecture to enable the German parent to access HR data through compliant channels. Built the three-month probation period into the hiring workflow as the practical performance filter — milestones at thirty, sixty, and ninety days, with the day-ninety conversation as the real hire-or-not decision. Twelve months later: eleven of the twelve hires are still in role, and three have been promoted to senior positions. The framework that looked restrictive on paper proved entirely sufficient in practice when combined with strong technical assessment and structured probation.

Different profiles. Same underlying lesson. The Belarusian framework works when designed correctly from the start. The mistake foreign IT employers make isn’t failing to follow Belarusian law — it’s assuming their home-country playbook will translate without redesign. It won’t. But the redesign isn’t that hard, once someone walks them through it.

The decision framework — what to actually screen for

Practical checklist. Cut this out and give it to your recruiter.

Always (legally clean for any IT role)

• Article 26 document verification — passport, education, employment record book.
• Direct verification of education with the issuing institution.
• Direct verification of professional certifications with the certifying body.
• Technical assessment proportionate to the role.
• Reference checks with the candidate’s written consent.
• Documented consent for personal data processing meeting PDP Law standards.

For senior or sensitive roles (with a proper consent framework)

• Detailed reference checks with multiple prior managers.
• Public profile review with documented proportionality.
• Architectural and leadership-decision discussions for technical leaders.
• Multi-stage interview process, including non-technical leadership conversations.

For specific regulated roles only

• Criminal record certificate — only where statutorily required for the role category.
• Financial regulatory checks — only for regulated financial services positions.
• Healthcare-specific screening — only for roles handling sensitive medical data with a statutory basis.

Never (without specific statutory authority)

• Mandatory criminal record checks for general IT roles.
• Credit history checks.
• Polygraph testing.
• Mandatory medical examinations beyond labour code requirements.
• Private social media access through any means.
• Pretexting, deception, or undisclosed third-party investigation.

Frequently asked questions

Can we require a Belarusian criminal record certificate for a senior developer role?

Not as a legal matter. The certificate is required by statute for specific position categories — state security, law enforcement, education, healthcare, finance, customs — and a senior developer isn’t one of them. Asking for it as a contractual condition creates exposure under both the Labor Code and the PDP Law. Different analysis if the candidate volunteers the certificate. But volunteering has to be genuinely voluntary.

Our US parent runs background checks on everyone. Why can’t we do the same in Belarus?

Different legal framework. US background screening is built on the Fair Credit Reporting Act and a nearly universal culture of pre-employment due diligence. Belarusian employment law restricts what an employer can demand to a finite list. The PDP Law further restricts processing. The US, UK, and German playbook doesn’t translate without redesign. The framework is workable — just not by porting the US version wholesale.

What if the candidate volunteers their criminal record certificate?

Different analysis. Voluntary provision is permitted. But voluntary has to be genuinely voluntary — not extracted under threat of withdrawal of the offer. And the employer’s subsequent processing still requires consent and proportionality. Most foreign IT employers we work with abandon the criminal check altogether for general IT roles once they see what compliance actually requires. The information value is rarely worth the design overhead.

Does the PDP Law apply if we’re using a US-based recruitment agency?

Yes. If the agency processes the personal data of Belarusian residents, the law applies to that activity. Extraterritorial reach similar to GDPR’s. The agency must be set up to comply with proper data processing agreements between the agency, the EOR (if one exists), and the parent company. All three sides of the triangle need to be aligned.

How long can we retain data on unsuccessful candidates?

Only as long as necessary for the recruitment process and any related defensive purposes. Six to twelve months is a typical range, though the right number depends on the role and any potential dispute risk. The retention period should be specified explicitly in the consent document. Indefinite retention isn’t permitted, and “we keep CVs forever” is the kind of thing that catches you in a Center audit.

What happens if we get this wrong?

Administrative liability under Belarusian law, supervised by the National Personal Data Protection Center. Specific penalties depend on the violation type, the controller’s scale, and whether the violation was systematic. The reputational exposure with candidates is sometimes more significant than the legal exposure — Belarusian IT talent is sophisticated about data protection and notices when employers overreach. Word travels in a small market.

The framework that actually works

Belarusian law on background checks is more restrictive than foreign IT employers expect. That’s the honest framing. The fix isn’t a workaround or a clever document — it’s designing the screening framework around what actually works in this jurisdiction. Strong technical assessment. Direct credential verification. Reference checks are built on real conversations. A consent document that meets PDP Law standards. A probation period structured deliberately as a real performance test.

The IT employers we see succeed in Belarus aren’t the ones with the most thorough US-style background check apparatus. They’re the ones who designed for Belarus from the start — and who built their screening around the things that actually predict on-the-job performance rather than the things that feel reassuring in an HR audit.

If you’re building out IT hiring in Belarus and want to design the framework correctly from the start, get in touch. Short scoping call, framework review, structure recommended. Most foreign IT employers benefit substantially from that conversation happening before the first candidate hits the pipeline. After the first candidate walks it is later than it needs to be.

GDPR Compliance for Belarusian IT Vendors Working With EU Clients

Here’s a pattern we’ve been seeing for the past two years.

A Belarusian IT company wins the technical conversation with a European client. Strong portfolio, solid references, the chemistry is right, the price is competitive. Everyone on the call thinks the deal is close to done. Then the conversation moves to legal and compliance — and somewhere between the proposal and the signed contract, the deal goes quiet. Sometimes the EU client comes back with a polite “we’ve decided to go with a vendor closer to home.” More often they just stop replying.

The blocker is usually the data protection conversation. Sometimes formally — the GDPR review fails some specific test. More often informally — the EU client’s internal compliance team flags Belarus as a third country, the procurement process gets harder, the deal slips a quarter, and the contract ends up in Warsaw or Bucharest.

This article walks through what’s actually happening on the other side of that compliance review. What EU clients are really asking. Where the friction sits for a Belarus-based vendor, specifically. And what the practical setup looks like in 2026 — the one that gets through procurement instead of getting parked there.

Standard caveat first. We’re a recruitment agency, not a law firm. We hear this conversation from both sides of every placement, but for the legal mechanics of your specific contract you need a qualified data protection lawyer. What this article gives you is the lay of the land.

The starting fact that most people misunderstand

Belarus is not on the EU adequacy list. This single fact drives most of what follows in this article, and it surprises many Belarusian IT companies the first time they encounter it.

Under the GDPR, personal data of EU residents can move freely inside the European Economic Area, plus to a small list of countries the Commission has decided offer “adequate” protection — the UK, Switzerland, Japan, South Korea, Israel, a few others. Belarus is not on that list. So any transfer of personal data from an EU client to a Belarusian processor is a transfer to a third country, and Chapter V of the GDPR kicks in. You need an additional legal basis. Almost always that means the European Commission’s Standard Contractual Clauses — and since the Schrems II judgement in 2020, a Transfer Impact Assessment on top.

This is the part where Belarusian IT companies sometimes push back: “But we have Belarusian Personal Data Protection Law compliance. Law No. 99-Z of 2021. Doesn’t that count?”

It counts for what Belarusian law requires of you domestically. It does not substitute for the EU-side mechanics. The Belarusian law was built broadly on GDPR principles, but it hasn’t been recognised as adequate by the Commission, and EU clients still treat Belarus as a third country. Having local compliance is necessary; it just isn’t sufficient. The EU client needs their own transfer paperwork in place regardless of what you’ve done locally.

This isn’t unique to Belarus. Most countries outside the EEA are in the same position. The point is that hearing “we have a privacy policy that mentions GDPR” doesn’t carry the weight some Belarusian vendors think it does in a European procurement conversation.

What EU clients actually ask — and what they’re really worried about

From conversations with our placement clients on both sides, the questions that come up most often during procurement:

• “Where is the data hosted?” — they want to know if EU personal data ever physically leaves the EU.
• “Where are your engineers located?” — because a Belarusian engineer accessing data sitting in an EU data centre is itself a transfer under GDPR, even if the data doesn’t move.
• “Do you have Standard Contractual Clauses in place?” — at this point this is table stakes, not a differentiator.
• “Have you done a Transfer Impact Assessment for Belarus?” — increasingly common in 2025 and 2026, used to be rare.
• “What does Belarusian law say about government access to personal data?” — the Schrems II concern, applied directly to your jurisdiction.
• “Are you GDPR-compliant?” — the question that doesn’t quite mean what it sounds like. What they actually mean is: can you sign our Data Processing Agreement, pass our security review, and not create a problem for our compliance team.
• “Do you have a Data Protection Officer?” — sometimes legally required, often expected even where it isn’t.

What they’re actually worried about underneath these questions usually isn’t the formal law. It’s a reputational risk. Audit trail risk. The possibility that a data subject brings a complaint, a regulator opens an investigation, and a Belarusian vendor’s documentation becomes the EU client’s problem — not the vendor’s. The EU client is the data controller. They carry the liability under GDPR. Your job in procurement is to convince them that working with you doesn’t increase their risk surface in a way they can’t defend later.

The Schrems II problem, in plain English

In July 2020 the Court of Justice of the European Union issued the Schrems II judgement, which changed the practical conversation around third-country transfers. The headline finding was that the EU–US Privacy Shield was invalid. The broader finding, which matters more for everyone else, was that SCCs alone aren’t enough.

The court held that the EU exporter has to assess whether the recipient country’s laws and practices allow public authority access to personal data in ways that would conflict with the rights guaranteed by EU law. If they do, the exporter needs supplementary measures to bring the protection back up to an essentially equivalent level — or they shouldn’t be transferring the data at all.

The European Data Protection Board published recommendations on supplementary measures the following year, and those recommendations now sit at the centre of every serious procurement review involving a third-country vendor. For a Belarus-based vendor, the honest TIA conversation includes the Belarusian Personal Data Protection Law as a domestic framework, the operational realities of state access to data held by Belarusian companies, and the specific supplementary measures the vendor takes to mitigate identified risks.

Encryption in transit and at rest, with key management held outside Belarus. Strict access controls and logging. Pseudonymisation of personal data wherever the use case allows. Data minimisation — engineers shouldn’t have access to data they don’t need for the task. Clear documentation of who can access what, and an audit trail that shows it.

Here’s the part that separates a useful TIA from a useless one. A TIA that says “Belarus poses no concerns, no supplementary measures required” is the TIA that fails a senior compliance review on the EU side. A TIA that says “here are the realistic concerns about state access, here are the specific mitigations we have in place, here’s why this particular data set can be transferred under these specific safeguards” — that’s the document EU compliance teams will actually accept. Honesty in the assessment is what gets it approved.

The contract layer — SCCs, DPAs, and what foreign counsel expects

The contractual stack a Belarusian vendor needs for EU work is fairly standard at this point. Three documents do most of the work.

Standard Contractual Clauses (2021)

The European Commission’s updated SCCs were adopted in June 2021 and have been the working transfer mechanism since. They come in modular form — controller-to-controller, controller-to-processor, processor-to-processor — and the Belarusian vendor signs whichever module matches the role they’re playing. Most often that’s the processor or sub-processor. The Commission keeps the official SCC text and guidance up to date.

Data Processing Agreement (Article 28 GDPR)

The EU client, as controller, will want a DPA defining the scope of processing, the purposes, the categories of data, the security measures, sub-processor rules, breach notification mechanics, and audit rights. Sometimes the DPA is a separate document; sometimes it’s incorporated into the main services agreement as an annex. The Belarusian vendor’s job is to read it carefully before signing — not after.

Sub-processor chain documentation

Anyone touching the personal data on your behalf counts as a sub-processor — cloud providers, third-party tools, downstream contractors, all of them. The DPA will ask you to name them, obtain the client’s sign-off, and notify the client when the list changes. Vendors who skip the documentation step end up in awkward conversations several months in, when an audit turns up a relationship nobody told the client about.

One mistake we see often. EU procurement teams present their standard DPA to the Belarusian vendor, and the vendor signs it without carefully reading the operational obligations. Then a year later, something happens — a small data incident, a sub-processor change, an audit request — and obligations the vendor can’t actually deliver come into focus. Notification timelines that are unrealistic. Audit rights that would require disclosure beyond what the vendor can disclose. Negotiate at the signing stage. Don’t be afraid to mark up the DPA. EU clients respect a vendor who reads what they’re signing more than one who just signs it.

The technical and organisational setup that actually works

Past the paperwork, there’s the operational stack the EU client’s security team will want to see. The practical defaults for a Belarusian IT vendor working with EU customers in 2026:

• EU-hosted infrastructure as the default — AWS Frankfurt, Azure West Europe, Google Cloud Belgium. This single architectural decision removes a meaningful portion of the transfer conversation, because the data physically remains in the EU and only the access component is cross-border.
• Access control and audit logging, identifying who accessed what data, when, and for what purpose, retained in accordance with contractual and jurisdictional requirements, and available to the EU client on request during audit.
• Encryption in transit (TLS) and at rest, with key management held in the EU where the use case permits. Encryption is one of the core supplementary measures identified in the EDPB recommendations.
• Pseudonymisation and data minimisation. Engineers working on production data should be working on the minimum necessary subset, pseudonymised where feasible. Production data on development laptops is among the fastest routes to a failed security review.
• A designated DPO where Article 37 GDPR requires one — large-scale systematic monitoring, large-scale processing of special category data. Even where designation is not strictly mandatory, having one named and reachable signals seriousness to the EU client.
• A documented breach notification procedure aligned with the 72-hour clock. The procedure must be written, tested, and known to the operational team — not assembled in the moment an incident occurs.
• A maintained, disclosed, and updated sub-processor list, with change notification mechanics agreed with the client in advance.
• For HTP-resident companies, much of this is already standard enterprise practice. The High-Tech Park framework supports paperless contracting, English-language commercial relationships, and elements of English commercial law — all of which make the EU-facing contractual conversation more straightforward. For non-HTP companies, the gap is typically wider, and that is where setup work tends to concentrate before serious EU engagements can be signed.

For HTP-resident companies, much of this is already part of standard enterprise practice. The High-Tech Park framework supports paperless contracting, English-language commercial relationships, and elements of English commercial law — all of which make the EU-facing contract conversation smoother. For non-HTP companies, the gap is usually wider, and that’s often where setup work concentrates before serious EU contracts can be signed.

The part nobody talks about openly: the sanctions overlay

Here’s the section that distinguishes an honest article from a marketing piece. Some EU clients have internal procurement policies that go beyond what GDPR strictly requires. They won’t process personal data through vendors based in countries on certain sanctions lists, regardless of whether the GDPR-compliant mechanics are in place. This isn’t a GDPR question. It’s a procurement policy question. And it’s increasingly the actual reason Belarusian IT vendors lose European deals.

The formal GDPR conversation can be passed. The internal policy filter is harder, because it’s not a legal test — it’s a risk-appetite test set by the EU client’s own compliance leadership. Sometimes the bar is unreachable from Belarus regardless of how good the vendor’s documentation is. Other times it’s manageable, but requires the vendor to think about structure rather than just compliance.

The structural responses Belarusian vendors actually use in 2026 cluster into three patterns.

Belarus-only with strong documentation

The vendor contracts directly with the EU client from Belarus, with SCCs, DPA, TIA, and the full operational stack. Works for smaller EU clients without restrictive procurement policies, or for clients where the relationship pre-dates the policy tightening. Cost-effective. Won’t work for tier-one enterprises with strict third-country policies.

Belarus plus an EU entity

The vendor establishes a subsidiary or branch in an EU jurisdiction — Poland, Lithuania, Cyprus are the common choices — that contracts with EU clients directly. The Belarusian entity becomes an intragroup sub-processor under the EU subsidiary’s primary contract. Significantly easier to clear procurement. More expensive to set up and maintain. Doesn’t eliminate the underlying GDPR mechanics — the intragroup data flow still requires SCCs and a TIA — but it changes the commercial-facing structure to something EU procurement teams find easier to accept.

Belarusian vendor as a sub-supplier under an EU prime

The EU client signs a contract with an EU-based prime contractor, and the prime contractor subcontracts the work to the Belarusian vendor. The compliance umbrella belongs to the prime. The contract paperwork largely lives in the relationship between the prime and the end client. This works well when the EU client needs an EU-headquartered counterparty on the front of the contract but is comfortable with the actual delivery happening from a third country further down the chain.

None of these three structures makes the underlying compliance questions go away. What they do is take friction out of procurement. The honest read for a Belarusian vendor: when a pipeline keeps stalling at the compliance step, the problem isn’t always the paperwork — sometimes it’s the structure itself. And if that’s the case, no amount of additional documentation fixes it. The fix has to be structural too.

Common mistakes Belarusian IT vendors make

The patterns we see consistently.

Treating compliance as a website privacy policy

“We have a GDPR-compliant privacy policy on our site.” This is necessary but is not what an EU client’s procurement review is asking about. They’re asking about an operational system — documented, auditable, defensible under scrutiny. The privacy policy is the cover page. The substance is the operational stack behind it.

Signing the EU client’s DPA without reading the operational obligations

EU procurement DPAs sometimes come loaded with obligations a Belarusian vendor can’t actually deliver as written. Notification timelines are pinned to specific local laws. Audit rights that run afoul of Belarusian confidentiality rules. Direct data-subject notification requirements that don’t match how the vendor actually operates. Sign without reading, and the problems don’t show up right away — they surface twelve months in, during an audit, when it’s too late to renegotiate. Read first, push back where it doesn’t fit, then sign. That order matters.

No documented Transfer Impact Assessment

In 2026, not having a TIA is increasingly the line item that loses the procurement check. EU clients have stopped treating it as nice-to-have paperwork — they treat it as a file they expect to see. A Belarusian vendor without one is at a specific, well-defined, and easy-to-close disadvantage. There’s no good reason to leave it open.

Engineers accessing real client data without controls

Production data on personal laptops. Database dumps shared over messaging apps. Real EU customer records were used in development environments because seed data felt like too much work. Every audit catches some version of this. The fix is technical and organizational — controlled environments, pseudonymized dev data, and real access logging.

Undisclosed sub-processors

Your cloud provider. Your email tool. Your monitoring service. Your analytics platform. Every one of them might be touching EU personal data on your behalf, and every one of them should be on a sub-processor list that your EU client has seen and approved. Sub-processors that nobody told the client about are one of the fastest ways to fail an audit — and the conversation when they’re discovered is always worse than the one you’d have had upfront.

Treating Belarusian local compliance as a substitute for GDPR mechanics

Covered earlier, but worth saying again because it’s the misunderstanding that costs the most deals. Complying with the Belarusian Personal Data Protection Law meets the requirements Belarus imposes on you. It doesn’t handle what the GDPR requires of the EU client sending data your way. SCCs, TIAs, Article 28 DPAs — none of that gets ticked off by a Belarusian compliance certificate. The two regimes run alongside each other, and you need both.

A short setup checklist

Built to be saved and forwarded internally.

• Standard Contractual Clauses (2021 modular version) prepared and in place with EU clients.
• Data Processing Agreement template reviewed by counsel, with non-negotiable terms identified.
• Documented Transfer Impact Assessment for Belarus, available on request, refreshed annually.
• EU-hosted data infrastructure as the default, where the use case permits.
• Access control and audit logging with retention aligned to contract requirements.
• Encryption stack documented — algorithms, key management, scope.
• Pseudonymization and data minimization practices for development and testing environments.
• DPO designated where required by Article 37; reachable contact details published.
• Breach notification procedure documented, tested, and known to the team.
• Sub-processor list maintained and disclosed to clients, with change notification mechanisms agreed.
• All client-facing documentation in English, structured for procurement review rather than internal use.

FAQ

Do we need to establish an EU entity to work with EU clients?

Not strictly. EU clients can contract directly with a Belarusian vendor under SCCs and a properly documented compliance setup. In practice, the answer is more nuanced. For smaller EU clients without restrictive procurement policies, Belarus-only is workable. For tier-one enterprises with strict third-country policies, an EU subsidiary or a sub-supplier-to-EU-prime structure is often the practical route. The decision is commercial more than legal.

Is the Belarusian Personal Data Protection Law equivalent to GDPR?

The Belarusian law was modeled broadly on GDPR principles, but it has not been recognized as adequate by the European Commission. From the EU client’s perspective, Belarus remains a third country, and the standard transfer mechanics apply regardless of local compliance. Domestic compliance discharges domestic obligations. It does not substitute for the EU-side framework. The two regimes operate in parallel, and both need to be in order.

What does a Transfer Impact Assessment for Belarus actually look like?

A document — usually 8–15 pages for a typical vendor — that identifies the personal data being transferred, assesses the risks under Belarusian law and practice (including state access concerns), and documents the supplementary measures used to mitigate those risks. Encryption, pseudonymization, access controls, contractual safeguards. An honest TIA acknowledges risks; it doesn’t pretend there are none. EU compliance teams trust honest assessments more than reassuring ones.

Can we just sign the EU client’s DPA without changes?

Sometimes. The problem is that EU procurement DPAs sometimes contain obligations that don’t align with the operational realities of a Belarus-based vendor. Notification timelines tied to specific local laws. Audit rights that conflict with local confidentiality. Direct data-subject notification requirements. Read carefully before signing. Negotiating the DPA at the signing stage is normal practice and won’t cost you the deal — signing one you can’t deliver against will cost you the relationship later.

Do we need a DPO?

Article 37 of the GDPR is the place to look. It makes designation mandatory in three situations: you’re a public authority, your core business involves large-scale systematic monitoring of people, or your core business involves large-scale handling of special category data. Most Belarusian IT service vendors don’t fall into any of those buckets, so formal designation isn’t legally required. That said, plenty of EU clients expect one anyway — and naming a trained DPO with a real, reachable contact line signals you take the topic seriously, which matters in procurement regardless of what the strict legal reading says.

What about the EU AI Act — does it apply to us?

The AI Act, in force since 2024 with phased application through 2027, applies to providers and deployers of AI systems whose output is used in the EU, regardless of the provideris location. If you’re building AI features that EU clients use, you’re likely in scope for at least some obligations. The compliance work is separate from GDPR, but increasingly comes up in the same procurement conversation. Worth raising with counsel as a distinct workstream.

How does HTP residency affect our GDPR conversation?

HTP residency doesn’t change the GDPR position — Belarus is still a third country regardless. But the HTP framework supports English-language contracts, elements of English commercial law in commercial matters, and paperless contracting, all of which make the EU-facing contractual conversation smoother. Most of the Belarusian IT companies that successfully serve EU customers are HTP residents, and that’s not a coincidence.

Are we losing EU deals because of GDPR or because of sanctions?

Honestly, often both, and the two get tangled in the same procurement conversation. The formal GDPR review can be passed with the right documentation. The internal policy filter — some EU clients have written policies that exclude Belarus-based vendors regardless of GDPR documentation — is harder. If your pipeline consistently stalls at the compliance step, the structural responses (EU subsidiary, EU prime contractor relationship) may be more useful than additional documentation. Diagnose which it is before you spend on the fix.

The bottom line

EU clients raise GDPR questions for a straightforward reason: they’re the data controller, they carry the liability under EU law, and their compliance team needs documentation that supports sign-off without exposing them to risk they can’t defend later. Most Belarusian IT vendors who lose EU deals at the compliance stage do so for one of three reasons: the documentation isn’t there, the operational stack isn’t structured for external review, or the corporate setup makes the EU client’s compliance team’s job harder than it needs to be.

Most of this is solvable. SCCs and a DPA template can be put together in a quarter. A TIA written honestly takes a few weeks. The operational stack — EU hosting, access controls, encryption, pseudonymized dev data — is enterprise-standard work, well understood by HTP-resident engineering teams. The structural side is more involved and more expensive, but it’s also where the most stubborn pipeline blockages get cleared.

At Recruitment.by we work with Belarusian IT companies on the people side of all of this — building teams that can deliver on EU contracts, supporting HTP residency for vendors building the right structure, joining the HTP for those who haven’t yet, and providing HR consulting for the organizational side of compliance setup. 

Bonus and Compensation Structures for IT Companies in Belarus: What Actually Motivates Developers

Here’s something we’ve been telling clients for years.

Two companies. Same kind of work. They both pay a senior backend developer roughly the same, within five, maybe ten per cent of each other on gross. One of them keeps that developer for four years. The other loses them after fourteen months. Same role, same money, completely different outcome.

The salary wasn’t the thing. It almost never is, by itself.

After more than a decade of placing developers into Belarusian IT companies — and quite often watching the same developers come back to us a year and a half later — we can tell you what the thing usually is. It’s the way the bonus and compensation structure is put together. How predictable the year-end conversation feels. Whether the performance bonus rewards things the engineer can actually do something about. Whether the long-term piece is real or just a line in the offer letter. Whether the whole thing holds up when the developer explains it to their partner at the kitchen table.

Base salaries in Belarusian IT have largely converged in 2026. Most companies in a given segment pay similar numbers. The real work has moved upstream, to the structure above the base. That’s where retention is won and lost now. This article is about how that structure actually fits together and where it tends to come apart.

Why salary alone stopped working

Through 2023 and 2024 the salary picture in Belarusian IT was unstable. Numbers moved fast in both directions. By 2026 things have settled. Most companies competing for senior developers are clustered fairly tightly around the same base ranges, and the ranges themselves don’t shift dramatically from quarter to quarter.

Within that band, the base salary becomes a hygiene factor. Are you paying the market salary or not? Pay market salary and you’re in. Pay under the market and you’re not. But paying the average amount of salary isn’t the same as winning it. And in2026, it cannot provide a total victory.

Specifically, in the structure of the annual cash bonus. Whether long-term incentives exist and feel credible. Whether the salary review actually happens when it was supposed to. Whether the whole compensation picture was explained well when the developer first joined and again at the end of year one.

When we see senior developers leave companies in 2026, it’s rarely about the base salary. It’s almost always about the structure above the base, feeling opaque, arbitrary, or simply ignored. And the awkward part is that fixing this is mostly free in cash terms. It costs attention.

Four layers — and why most companies build only one of them properly

We use a simple model when we’re advising clients on structure. Four layers. Each does a different job.

• Layer 1 — Base salary. Fixed, predictable. Pays the bills. Doesn’t motivate, but its absence demotivates instantly.
• Layer 2 — Annual cash bonus. The 13th-month salary, the performance bonus, or some mix of both. 
• Layer 3 — Long-term incentives. Equity, phantom stock, retention bonuses. The reason senior developers stay through year three and beyond, rather than checking the market every spring.
• Layer 4 — Non-cash motivators with structural weight. Career progression, L&D budget, recognition, and team quality. The stuff that doesn’t show up on the payslip but explains most of the retention story.

Almost every company offers Layer 1 carefully. Then they put something generic on Layer 2 — usually a 13th-month salary copied from what other companies do. They forget about Layer 3 unless they’re at a stage where investors are asking about it. And Layer 4 quietly becomes whatever HR has time for that quarter.

The result is a comp structure with a strong foundation and three unfinished floors. Which is why so many companies end up paying a competitive base and still losing senior people. They’re solving the easy part and ignoring the part where retention actually lives.

Layer 1: What base salary actually looks like in 2026

Honest market ranges for mid-2026, gross monthly in USD equivalent, before any benefits or bonus accrual.

• Senior backend developer (5+ years): $3,500 to $5,500
• Mid-level frontend: $2,200 to $3,500
• Senior DevOps / SRE: $3,800 to $5,800
• Senior QA / SDET: $2,800 to $4,200
• Tech Lead: $5,500 to $8,000 and up
• Staff Engineer or Principal: $7,000 to $10,000+

These are general numbers, taken from open sources. If you want the proper breakdown by stack, seniority band, and company type, our IT salary research covers it in detail.

Two structural points on base that matter more than the headline number.

The review. The default in Belarusian IT used to be annual review. At the better employers in 2026 it’s semi-annual, with quarterly conversations for high performers. The cadence matters less than the consistency though. A scheduled review that consistently slips — “we’ll do it in Q4,” which becomes Q2 of the following year, which becomes “let’s wait for the funding round to close” — is one of the most reliable ways to push a senior developer to start looking. By the time the review finally happens, they’ve usually already decided to change the company.

Layer 2: The annual cash bonus — three patterns, three different outcomes

This is where most Belarusian IT companies make the most consequential structural choice, usually without meaning to. Three patterns dominate the market right now.

The pure 13th-month salary

One month of base salary, paid in December, no performance variation. Everyone who’s still employed by 31 December gets it.

The advantage is simplicity. Developers know exactly what’s coming. There’s no negotiation, no political theatre at year-end, no scoreboard. Culturally it lands well — Belarusian developers grew up with the 13th-month as a normal concept, and seeing it in the offer reads as a serious employer rather than someone testing local norms.

The flip side is that it doesn’t differentiate. The developer who shipped a major platform migration gets the same December bonus as the developer who quietly coasted for nine months. Over time the 13th-month stops feeling like a bonus and starts feeling like a delayed slice of base salary. That’s not necessarily a problem — but you should know that’s what you’ve designed, because the bonus is now anchoring expectations as a guarantee rather than a reward.

Best fit: companies under roughly 100 people where everyone knows everyone, companies where individual contribution is genuinely hard to isolate, and companies that explicitly value team cohesion over individual differentiation. 

The pure performance bonus

Variable by individual or team KPI. Can pay out at zero in a bad year, or 200% of target in a great one. Calculated against a written formula or scorecard that’s hopefully in the developer’s offer letter.

When this works, it works beautifully. Excellence is rewarded visibly. Compensation connects directly to outcomes. High performers feel seen by the system rather than waiting to be noticed by a manager. Underperformers get an unambiguous signal, which is occasionally what they actually need.

When this doesn’t work, it does real damage. The moment developers conclude that the KPI structure rewards things they can’t actually influence — sales numbers they had no part in, company metrics that depend on the strategy team and not the engineering team — the bonus becomes a frustration instead of a motivation. Worse, when the KPI structure gets gamed by people closer to leadership, the rest of the team notices fast, and trust takes a beating that’s hard to recover from. We have watched performance bonus systems destroy team morale at precisely the companies that thought they were investing in performance culture.

Best fit: companies above roughly 150 people where individual contribution is measurable, sales-adjacent engineering functions, and engineering organizations with genuinely mature OKR or scorecard practices. If you don’t have that maturity yet, this structure tends to do more harm than good.

The hybrid — half guaranteed, half performance-linked

The pattern we see most often at mature HTP companies in 2026. The annual bonus pool is split — typically half and half, sometimes 60/40 — between a guaranteed 13th-month component and a performance-linked component.

The guaranteed half provides the basis and lets the developer plan their year financially. The performance half rewards excellence without making the whole bonus feel like a lottery. People know what they’re guaranteed; they have something to play for above that.

This requires more administrative work and a lot more communication. The split has to be explicit in the offer letter. The performance criteria need to be written down and reviewed quarterly, not pulled together hastily in November. The payout has to actually happen on schedule — and at the agreed amount, not 60% of it because cash flow got tight in Q4. Companies that do this well retain noticeably better than companies on either pure structure.

Best fit: most growth-stage Belarusian IT companies, particularly product companies and HTP residents serving international clients.

Layer 3: The long-term piece — where retention past year three is decided

This is the layer most Belarusian companies underinvest in, and it’s the most consequential for keeping senior developers past year three. By year four, a developer without a long-term incentive line in their compensation has typically had multiple recruiter conversations, and the only question is which offer they accept.

Equity grants

You can run RSUs and stock options in Belarus. They’re not impossible, just a bit more involved than in Berlin or London. HTP residents have it easier because the regulatory framework was actually written with these instruments in mind. The mechanics aren’t quite as smooth as you’d get in Western Europe, but they’re workable, provided someone takes the setup seriously.

The trick is doing all the boring paperwork before the grant lands in the offer letter, not after. Vesting schedule, written down. Dilution mechanics, spelled out. Tax treatment is understood for the specific instrument you’re issuing, not the general concept of equity. The version that goes wrong is the one where someone tells the candidate, “We’ll sort the details later.” It almost always falls apart around month six. The developer asks for the documentation, finds out it doesn’t exist, and now they’re quietly re-reading every other promise in their offer letter, wondering what else wasn’t real.

Equity actually pays off at companies with a believable path to liquidity or a valuation that’s visibly moving in the right direction. If you’re a Belarusian IT services company without anything resembling an exit on the horizon, equity tends to oversell what it can actually deliver, and developers eventually do the math themselves. Usually, sooner than the people writing the offer letters realize.

Phantom stock

Tracks the value of equity without conveying actual shareholder rights. Pays out as cash at defined events — sale, IPO, scheduled vesting milestones.

Often this is the better fit for engineers who’d rather have a clean cash outcome at vesting events than navigate currency control mechanics around a future liquidity event. Administratively simpler. Sits more comfortably with the developer’s tax planning. Worth considering at companies where actual equity creates more friction than value.

Retention bonuses

Sometimes called loyalty bonuses in Belarusian HR practice. A defined cash amount that vests on tenure milestones — typically 12, 24, and 36 months. Increasingly used at senior+ levels as a direct response to outside recruitment pressure.

These work best when they’re public and structural, not negotiated quietly with individual developers. A retention bonus that becomes known across the team as something a few favoured engineers received does more harm than the bonus itself does good. If you’re going to use retention bonuses, put them in the published compensation framework where everyone can see them.

Layer 4: The non-cash stuff that decides most of the actual retention

From our placements, we hear consistently what developers say about why they’re considering a move — or why they accepted a previous one. The non-cash factors come up more often than the cash ones. By a meaningful margin.

Career progression that’s actually visible

A documented path from senior to staff to principal, with criteria, with timelines that match what actually happens. Most Belarusian IT companies say they have this. Most don’t, in any form a developer can navigate. The companies that genuinely do — published levelling, real criteria, promotions that happen on the published schedule — retain better than the companies that don’t. It’s not close.

L&D budget you can actually spend

Not just the number. The friction. A $1,500 budget with a one-step approval beats a $2,500 budget where the developer has to argue with finance over every conference ticket. The friction is what the developer remembers six months later — not the higher headline number.

Recognition that’s structural, not occasional

Public acknowledgement when something ships. Peer recognition systems. Technical leadership opportunities — chairing architecture reviews, mentoring juniors, representing the team externally. These are cheap to provide and significantly underused at most companies. The companies that get this right rarely have to ask why their senior developers stay.

Working conditions that are specific, not vague

Remote and hybrid clarity. Equipment quality at the senior tier. Real autonomy over working time. Companies that hedge on these — “we’re mostly remote” without specifying what that means in practice — quietly lose candidates to companies that are precise.

The team you’re being placed on

The single most cited reason senior developers accept an offer is who they’d be working with. Strong engineers want strong engineering teammates. Companies with a reputation for engineering quality recruit on that reputation; companies without one are paying a hidden premium they don’t see in the numbers. This is also why deliberate team-building matters as much as raw headcount growth.

FAQ

How do we structure performance bonuses without making them feel arbitrary?

Three things, all of them required, not optional. Write the criteria down in advance — ideally in the offer letter. Review the scorecard quarterly so developers can adjust before year-end. Make sure the criteria depend on outcomes the developer can actually influence with their work, not on company-level outcomes they have no leverage over. If you can’t honestly tick all three boxes, default to 13th-month for now and come back to performance bonuses when your scorecard maturity catches up.

Are stock options or phantom stock administrable for Belarusian developers?

Yes, with structure. The HTP framework explicitly accommodates equity-style instruments, which makes residents’ lives easier. The mechanics need to be set up before the grant goes out, not patched together afterward. For developers outside HTP, phantom stock or cash-based long-term incentives are usually administratively simpler. Get advice on the specific structure before promising anything in writing — “placeholder equity” is one of the most common offer-letter mistakes we see.

How often should we do salary reviews?

Annual is the baseline. The better employers in 2026 are doing semiannual reviews for everyone and quarterly conversations with high performers. The cadence matters less than the consistency, though. A slipped review damages trust more than a smaller raise. Whatever cadence you pick, hit it on schedule. Every time.

How do we keep developers from leaving for a 10% higher offer?

Usually, by making sure the structure above the base is genuinely strong. A developer who’s leaving for 10% more on base alone is almost always a developer who didn’t have a long-term incentive they cared about, didn’t have a clear progression path, and didn’t feel like this year’s bonus was going to mean anything. Fix those three, and the 10% offer doesn’t get taken. Don’t fix them, and you’ll eventually lose that developer even if you match the offer, because what they’re actually leaving isn’t the salary.

The takeaway

Salary parity is mostly solved. The structural work has moved upstream, to the layers above the base. Companies that design those layers carefully retain developers through year three and beyond. Companies that don’t end up paying market-rate salaries with above-market attrition, which is the worst possible combination of outcomes — you’re paying what the good companies pay, and you’re getting what the worst companies get.

We work with Belarusian IT companies on both recruitment and compensation strategy through HR consulting. To anchor your structure, our IT salary research provides the actual compensation developers in your segment are being paid. For a conversation about your specific structure — what’s working, what’s not, where the next adjustment should land — contact us.

How to Build an Employer Brand on LinkedIn That Actually Attracts Senior Belarusian IT Talent

A foreign CTO got on a call with us last month and asked why his InMails to senior Belarusian engineers were getting a 4% response rate when LinkedIn’s global benchmark for tech roles sits closer to 18–25%. The honest answer: because his message read like every other InMail those engineers had received that week. The seniors he was reaching out to — the ones with 7–12 years on the bench, fluent English, and EPAM or Wargaming or Apalon on their CV — get five to fifteen cold messages a month. Most of them are template trash. The good engineers stopped responding to anything that doesn’t show specific knowledge of who they are.

Generic LinkedIn employer-branding advice doesn’t fix this. “Post employee stories” and “showcase your culture” are fine for entry-level pipelines and not even close to enough for the Belarusian senior market. So below is the playbook we actually run for foreign clients hiring senior Belarusian engineers — eight tactics, in order of how much they move the needle, plus a 30-day starter plan if you’d rather act than read.

Why generic LinkedIn advice doesn’t translate to senior Belarusian engineers

Three reasons before the playbook starts.

The market is small and the seniors know each other

Roughly 100,000 IT professionals in Belarus, of whom perhaps 8,000–12,000 are genuine seniors with 7+ years of experience. They’re in the same Telegram groups. They’ve worked at the same companies. They share notes about employers — including which one is spamming generic InMails this month. Whatever you send today, somebody else is reading by Thursday. Pick a tone you’d want spread.

English is good, but not native

Senior Belarusian engineers operate at B2–C1 — most of the leading software companies mandate English for client communications and many provide internal training. That’s strong, but it’s not the same as native fluency. Generic American marketing copy lands strangely. “We’re a fast-paced team building the future of [generic vertical]” reads as exactly the kind of vapor that pushes them away.

Trust currency is different

What senior Belarusian engineers value, in this order: technical credibility, salary transparency, and predictability. They’re skeptical of performative culture content — ping-pong tables and “we’re like a family” close doors here, not open them. A LinkedIn brand built on the three things above outperforms one built on aesthetics. This is also where the geopolitical context lives, which we’ll come back to in tactic #5.

The 8-tactic playbook

Tactic #1 — Build a Company Page that signals technical seriousness, not corporate polish

Senior engineers don’t read your Company Page like a brochure. They scan it for signals. Who’s the CTO? What stack are you running? When did anyone post anything last? Do your job posts list real salary ranges or hide behind “competitive compensation”? LinkedIn’s own data shows pages with complete, regularly-updated profiles get 2x more applicants per posting — but for senior talent, that 2x is mostly noise unless the page also carries technical credibility.

What to actually do. Pin a post about something you’ve engineered that’s interesting. Link to your engineering blog (or build one). Make sure your CTO’s profile is connected and active. Use real photos of the team rather than stock imagery. Show recent product or technical wins.

What to avoid. Vague mission statements, listicle-style “five reasons we’re a great place to work” posts, anything that reads like it was written by a marketing team that has never spoken to your engineers. Senior readers can spot the difference in three lines and they’ll click away. Our work on targeted IT recruitment depends on this kind of credibility being already in place.

Tactic #2 — Have your engineers post, not your recruiter

Content from individual employees outperforms branded content by roughly 8x in engagement, and most professionals trust content from individuals more than from brands. For senior Belarusian engineers — many of whom are on LinkedIn primarily to follow other engineers, not companies — that gap is even wider.

What to do. Identify three or four of your existing engineers who already post (or would, with light encouragement). Help them write about real technical decisions: “why we picked Postgres over MongoDB for this thing,” “how we cut our API latency in half,” “what went wrong when we migrated to Kubernetes.” Don’t script them. Don’t make them post on a schedule. Let it be real.

What to avoid. Forcing employee advocacy through a content tool, ghostwriting engineer posts in marketing voice, asking engineers to repost corporate announcements verbatim. Ghostwritten content is detected within two lines, and once it’s been spotted, the engineer who posted it loses credibility with their network. That’s a worse outcome than no post at all.

Tactic #3 — Show salary ranges in EUR or USD, with a specific number

This is the single highest-leverage thing most foreign companies still don’t do. Senior Belarusian engineers receive InMails daily. The ones that name a salary range get answered first. The ones that say “competitive compensation” don’t get answered at all.

What to do. In your job posts and your InMail templates, include a number. “EUR 5,500–7,500 gross/month for senior backend, depending on experience” beats anything else you can write. If you’re hiring through HTP-resident outstaffing, be transparent about the model: “EUR 5,500–7,500 gross/month, paid through HTP-resident outstaffing structure, no relocation needed.” That sentence converts because it answers the three questions every senior is asking before they decide whether to reply.

What to avoid. “Competitive,” “market rate,” “DOE,” “based on experience” — every one of these reads as “we don’t want to commit, so neither will I.” Salary anchoring isn’t tacky in this market; it’s table stakes. The contract structure also matters — see our overview of IT outstaffing arrangements for the variations clients ask about most.

Tactic #4 — Optimize for InMail response rate, not volume

Most foreign companies treating LinkedIn as a sourcing channel make the same fundamental error. They send hundreds of generic InMails and watch their response rate collapse. Senior Belarusian engineers are over-sourced. The math has flipped — sending five carefully personalized InMails outperforms sending a hundred templated ones, by a wide margin.

What to do. Read the engineer’s profile. Find one specific thing — a project they shipped, a stack choice, a talk they gave, a GitHub repo, the company they’re at — and reference it in the first line. Mention the salary range in the second line. State your role-specific task in the third. Done. Most senior engineers won’t read past three sentences and will reply faster to short, specific messages than to long, polished ones.

What to avoid. Subject lines like “Exciting opportunity at [Company]”; opening lines that praise generic skills they didn’t put on their profile; multi-paragraph InMails that try to sell the company before establishing relevance. Companies with strong talent brands on LinkedIn see 31% higher InMail acceptance rates on average — but that’s an average across all roles. For Belarusian seniors, the gap between strong-brand and weak-brand InMails is wider than that.

Tactic #5 — Acknowledge the geopolitical and sanctions context, briefly

This is the tactic most global recruitment guides skip and most Belarus-aware foreign companies handle badly. Since 2022, senior Belarusian engineers have heard a lot of vague language from Western recruiters about “the situation.” The good ones have learned to read avoidance as either ignorance or bad faith — and either is disqualifying.

What to do. In your employer-brand content, be specific about how you handle the practical questions. Payment in EUR or USD. Working through HTP-resident structures or Belarusian EOR providers. Tax and contract structure. Sanctions exposure on either side. Don’t moralize. Senior Belarusian engineers don’t need your political opinion; they need to know whether the contract works in 2026 and whether they’ll get paid on time. The recruiting.by piece on hiring blockchain developers in Belarus is a useful template for how to address structural questions without melodrama.

What to avoid. Statements like “we believe in our Belarusian colleagues during this difficult time.” That language reads as condescending and makes senior readers click away. The cleanest tone is matter-of-fact: here’s the structure, here’s the payment, here’s what we expect.

Tactic #6 — Use video, but only with engineers as the talent

Video content is an increasingly strong differentiator on LinkedIn — but the wrong kind of video destroys trust faster than no video at all. A polished marketing-team-produced “life at our company” video performs worse than no video, because it triggers the bullshit filter every senior engineer has running by default.

What to do. Five-to-ten-minute LinkedIn Lives where your CTO walks through a technical decision the team made. Short videos where an engineer talks through an actual project — unscripted, with the rough edges left in. Conference talks recorded by your team. Internal lightning talks made public. Production quality matters less than authenticity; phone-camera footage of a real engineer beats a polished promo every time.

What to avoid. Any video that feels like a recruitment commercial. Anything with a corporate music bed under it. Anything where someone is reading from a teleprompter. The whole appeal of video for this audience is that it’s harder to fake than text — leaning into production removes the only advantage video has over a written post.

Tactic #7 — Build a Careers page that pre-answers the questions seniors actually ask

Your LinkedIn Careers Page and your careers site should pre-answer the five questions every senior Belarusian engineer asks before responding to outreach: (1) what’s the salary range, (2) what’s the contract structure — entity, EOR, HTP outstaffing, (3) is the role remote, hybrid, or on-site, (4) what’s the actual tech stack, and (5) who else is on the engineering team. If those five answers aren’t on the page they reach, the senior doesn’t reply.

What to do. Build a one-page careers site that answers all five clearly and link it in every InMail. Update the engineering team listing every quarter. If you don’t have a careers site, make sure your LinkedIn Careers Page covers the same five with the same specificity.

What to avoid. Marketing-led careers content that’s heavy on culture and light on substance. Senior engineers don’t apply to vibe; they apply to specifics. A careers page full of “join our journey” content with no salary band, no stack, and no team listing is worse than no careers page — it actively signals that you’re hiding something.

Tactic #8 — Partner with someone in Belarus who already has the network

The honest one. The senior Belarusian engineering market is heavily relationship-driven. Recruiting.by’s overview of Belarusian IT job-search platforms confirms what every recruiter in the country already knows: “senior specialists and team leads often find opportunities through networking, LinkedIn, and professional communities rather than through mass job applications.” A foreign company building a LinkedIn employer brand from scratch is starting cold. A Belarus-based recruiter is starting from a network of relationships built over years.

What to do. Use a local recruiter — us, or someone like us — to amplify your LinkedIn brand into the Belarusian senior engineering network. A good local partner does three things you can’t easily do yourself: warm intros to passive candidates, pre-vetting on technical and cultural fit, and translation of your value proposition into something that lands locally. We do this through our IT recruitment service; there are other firms doing it well too.

What to avoid. Assuming a globally-branded recruitment agency knows the Belarus market because they have a Belarus page on their website. They almost certainly don’t. Local market knowledge is built over years and shows up in details — which company is actually a good place to work, who’s been laying off quietly, which compensation expectations are realistic right now.

A 30-day starter plan

If you’re going to act on any of this, the order matters. Below is the rollout we suggest for clients who want to do this themselves.

Most clients who run this 30-day program see InMail response rates move from low single digits to the 12–18% range by the end of week four. Past that, returns flatten — the next gain comes from getting to the engineers who don’t accept InMails at all, which is where the local-network advantage in tactic #8 kicks in.

If your InMail response rate isn’t where it should be

Everything above is what we run for clients hiring senior Belarusian engineers through LinkedIn. The 30-day plan works if you have time and bandwidth to execute it; if you don’t, that’s most of what we do. Tell us the role — stack, seniority, salary band, contract structure — and we’ll tell you what’s realistic and how fast. Get in touch, or browse the rest of our news section while you’re deciding.

IT Outsourcing vs IT Outstaffing in Belarus: A Decision Framework for Foreign Companies

Roughly half the foreign companies who contact us asking for “outsourcing in Belarus” actually need outstaffing. A smaller but expensive subset asks for “outstaffing” when what they really want is fixed-price project delivery. The two models look almost identical from the outside — Belarusian developers working on your software, paid in BYN, billed to you in EUR or USD — but underneath, they’re different products. They split differently on who runs the work, who carries IP risk, who absorbs staffing churn, and what happens the morning a developer decides this isn’t for them anymore.

Pick the wrong one and you’ll feel it within the first three months. Pick the right one and you’ll wonder why nobody explained it this way before. So here’s the framework we walk new clients through before they sign anything.

The two models, in a paragraph each

IT Outsourcing

You hand a piece of work to a Belarusian provider — a project, a feature, a discrete deliverable. The provider assembles their own team, manages it, and ships you the result. You don’t choose the developers (or you choose them once at the start and then lose visibility). You pay for the deliverable, usually as a fixed-price contract or time-and-materials with a project manager sitting in the middle. The provider owns the team and the process. Your relationship is with the company, not the people doing the work.

IT Outstaffing

You select specific developers — interview them, approve them — and they then work exclusively for you, embedded in your team, taking instructions from you directly. They stay legally employed by the Belarusian agency (in our case, through our HTP-resident company), so you don’t deal with payroll, taxes, contracts, or labor inspectorate. You manage the work day-to-day; we manage the employment. The closest mental model: “they’re on your team, on someone else’s payroll.”

Where the confusion comes from is no mystery. Both look like “IT services from Belarus,” both involve developers you don’t directly employ, and the marketing language used by global vendors blurs the line on purpose — outsourcing usually sells at a higher margin. A clean breakdown of the same distinction sits in this hiring guide on Recruiting.by if you want a second take.

Side-by-side: where the two diverge

The differences look small in marketing copy and large in practice. The table below is the version we use on calls — dense on purpose.

When outsourcing is genuinely the right answer

Let’s start here, because if we only sang the praises of outstaffing the post would lose credibility on the second paragraph. Outsourcing wins in three situations.

1. Genuinely fixed-scope projects

Migrate this database. Build this marketing site to these designs. Ship version 1 of this mobile app to these specs and hand over the source. If the work has a finish line and you don’t need ongoing iteration, paying for a managed deliverable is cleaner than running an embedded team you’ll have to shut down in three months. Belarus has a deep bench of providers who do this well.

2. Specialist work outside your in-house competence

You need three weeks of a security audit. You need a Solidity team to ship one smart-contract product. Hiring a full-time outstaffed senior for a three-week need is the wrong shape. Outsourcing it is the right shape — you pay for the outcome, not the people in the team.

3. No engineering management bandwidth on your side

If you literally cannot manage developers — no engineering manager, no tech lead, no product owner who can run standups — outstaffing won’t work. The model assumes you bring management. Outsourcing absorbs that for you. We’d rather tell you this upfront than watch the model collapse two months in.

When outstaffing is the right answer (which is more often than you’d think)

For everything outside the three scenarios above — and “everything else” covers most foreign companies hiring developers in Belarus — outstaffing is the better answer. Four reasons.

1. Ongoing product development

Your product will keep evolving. The team needs to learn your codebase, your customers, your engineering culture. Outstaffing builds institutional knowledge in your team because it’s the same people, month after month. Outsourcing rotates people away from it — they finish your project and move to the next client, taking the context with them.

2. You want to control hiring and culture

You interview every developer. You decide who’s on your team. You’re not delegating that to a provider’s PM. This is the most common reason mature engineering teams pick outstaffing — control. Hiring is a strategic decision, and most CTOs aren’t comfortable handing it off.

3. Your scope will change

Software scope always changes. Outstaffing absorbs that for free because the team is yours — you re-prioritize the backlog and the team executes. Outsourcing fights it because every change goes through a contract amendment, a re-scope, and usually a renegotiation. Three scope changes in and you’ve spent more on contracts than on code.

4. You want HTP cost benefits visible in your invoice

This is the Belarus-specific point and it’s the one most global comparisons skip. When the outstaffing agency is HTP-resident, the social-contribution base is calculated against the country-average salary, not the developer’s actual paycheck. For a senior developer on $4,000/month, that’s a meaningful chunk of cost that disappears — and it shows up in your monthly fee. We run this through our own HTP-resident company at a flat €350/month service fee on top of payroll. Outsourcing buries the same benefit inside the provider’s margin; outstaffing surfaces it. Background on why this matters: outstaffing is on the approved HTP activity list, which is what makes the structure work.

The decision framework: six questions

Run through these in order. Each one narrows the answer. By the end you’ll know which model fits.

1. Is the work scope finite and locked, or ongoing? Finite → outsourcing in play. Ongoing → outstaffing.
2. Do you want to interview and choose the specific developers? Yes → outstaffing. No, don’t care → outsourcing fine.
3. Do you have an engineering manager or tech lead who can run the team day-to-day? Yes → outstaffing works. No → outsourcing, or hire that person before going further.
4. How sensitive is the IP? High → outstaffing through an HTP-resident agency gives you a cleaner IP chain and a stable team. Outsourcing can work too, but only with a bulletproof contract.
5. How much will the scope change in the next six months? A lot → outstaffing absorbs it for free. Almost none → outsourcing is fine.
6. What’s your budget visibility? “Fixed price for the whole project” → outsourcing. “Predictable monthly burn per developer” → outstaffing.

Four out of six pointing the same way is your answer. If it’s split three-three, that’s a sign the work itself is two different things — split it.

Why the choice matters more in Belarus than elsewhere

This is where the Belarus angle shows up properly. Three points that don’t apply (or apply less) in other CIS jurisdictions.

HTP changes the math on outstaffing

Already covered above, but worth repeating because it’s the structural advantage. The HTP regime — extended by Decree No. 8 to 2049 — gives resident companies a reduced social-contribution base and exemption from corporate profit tax. That benefit can flow through to your invoice in an outstaffing arrangement, or it can sit inside someone else’s margin in an outsourcing arrangement. Same developer, different cost to you.

Belarusian Labor Code is restrictive on the employer side

Termination requires grounds listed in Article 42. Severance for dismissals without cause is typically three months. Protected categories — pregnant employees, employees on maternity or childcare leave — can’t be dismissed at all in most circumstances. Both models externalize this risk away from you, but outstaffing makes the cost transparent (the agency is the legal employer; the cost shows up in the monthly fee). Outsourcing buries it inside a fixed price you can’t audit.

English fluency is strong, but management still matters

Both models work in English in Belarus — most senior engineers operate comfortably at B2 or above. But outstaffing benefits more from this because you’re managing the developer directly, not through a translator-PM. Current market data on the senior IT bench: average salaries run between $1,600 and $1,900 at mid-level with seniors well above that. Belarus is also still ranked among the top 30 global IT outsourcing destinations — meaningful depth, especially in backend, mobile, and game development. For broader market context, TechBehemoths’ Belarus overview puts the IT sector at roughly 6.1% of GDP.

A worked example

Abstract framework, meet concrete numbers. The case below is composite — based on the kind of inquiry we field weekly — but the numbers are realistic for May 2026.

A SaaS company in Berlin needs three engineers — a senior backend developer, a mid-level frontend developer, and a QA engineer — to extend their product. They expect the team to work on the product for at least 18 months and the roadmap is going to shift several times along the way.

Outsourced via a managed Belarus delivery shop: roughly €8,000–€12,000/month per engineer including the PM markup and provider margin, plus 2–3 weeks of scoping and contract negotiation up front, plus a project manager sitting between you and the developers, plus a contract amendment every time the roadmap shifts. The amendments aren’t free — usually 5–10% legal and renegotiation overhead per change.

Outstaffed via an HTP-resident agency: developer salaries at market — a senior backend at roughly $3,500–$5,000 gross, a mid frontend at $2,500–$3,500, a QA at $2,000–$2,800 — plus the flat €350/month service fee per engineer. Onboarding runs 1–2 weeks from first interview to first day. Direct management. No PM markup. No margin on top.

For an 18-month engagement on an evolving product, the math isn’t close — and the difference grows the more the scope moves. Caveat: actual rates depend on stack, seniority, and timing, and the numbers above are illustrative rather than a quote. But the shape of the answer holds across most of the inquiries we see.

If you’re not sure which one fits

If you’ve read this and you’re still not sure which model fits your situation, the answer usually takes a 20-minute call. Tell us what the work looks like — scope, team, timeline, what you’ve already tried — and we’ll tell you the model. If it’s outsourcing, we’ll be honest and point you to a partner who delivers it well. If it’s outstaffing, that’s what we do, and we can have first CVs in your inbox within a week of signing. Get in touch, or browse the rest of our news section while you’re deciding.

How to Successfully Onboard Remote IT Employees in Belarus: A Practical Checklist for Companies

Monday morning. Your new developer in Minsk opens their laptop. You’re somewhere in London, or Tel Aviv, or Austin. And you’re realizing 2014 maybe for the first time 2014 that you have no clear picture of what their first week actually looks like from their side.

Hiring is solved. You found the right person, probably with help from a specialist IT recruitment team. You’ve signed the EOR contract. The salary is agreed. What nobody told you is that the work of actually integrating this person into your company — legally, operationally, culturally — is something the EOR won’t do for you. That part belongs to you, and most foreign companies figure this out around day three, not before day one.

This guide is a practical, phase-by-phase checklist covering the two to three weeks before a Belarusian IT employee starts through the end of their 90-day probation period. It’s written specifically for the Belarus context.

If you haven’t yet decided between EOR and PEO, that question is covered in detail in our earlier piece on EOR vs. PEO for hiring in Belarus. This guide starts where that decision ends.

Why You Can’t Just Use a Generic Remote Onboarding Checklist

The EOR handles employment. You handle onboarding. These are not the same thing.

When you hire through an EOR or outstaffing arrangement, the employment contract sits between the employee and the EOR provider. The provider handles the Belarusian Labor Code compliance: the contract, payroll processing, FSZN contributions (34% of gross salary), tax filings, social insurance registration. All of it.

What the EOR does not handle: introducing your new developer to the team. Explaining your codebase. Running the day-one call. Setting expectations for the first 30 days. That’s still you. Companies that assume the EOR is “taking care of onboarding” routinely arrive at week two with a new hire who is legally employed, has all their access set up, and has no idea what they’re supposed to be doing or who to ask.

The probation period is a legal structure, not just an HR convention

Under Belarusian labor law, the probation period can run up to three months and must be explicitly stated in the employment contract. During that window, either party — employer or employee — can end the relationship with just three days of written notice. After probation ends, the rules change significantly: the employer needs documented grounds for termination and must provide at least one month’s notice.

That asymmetry matters. The probation period is a specific legal window with real advantages for both sides. Companies that treat it as a passive stretch of time where they “watch and see” lose those advantages entirely.

Belarusian IT developers have worked with foreign employers for 20+ years. They have expectations.

Developers in Minsk have been working with US, UK, EU, and Israeli companies for a long time. Many have had simultaneous clients across three time zones. They’re not unfamiliar with remote work — if anything, they’ve seen more remote-work dysfunction than most managers have caused.

Work culture in Belarus is shifting — younger developers are more vocal about expectations and more direct about what they need from an employer. But the baseline assumption that you’ll manage people proactively, not just reactively, holds across experience levels.

Before Day One: The Pre-Onboarding Checklist

Most of what determines how day one goes is decided two to three weeks before it. These aren’t nice-to-haves — each one on this list has caused a preventable failure when skipped.

Get the employment documentation actually confirmed, not assumed

Under the Belarusian Labor Code, employment contracts must be in Russian or Belarusian. Bilingual versions are fine. The contract must include the probation period duration, job title, salary in Belarusian rubles, work schedule, and start date. Remote work must be specified explicitly in the contract or a separate amendment — the Labor Code requires the work location, performance monitoring method, and document exchange procedures to be formally documented.

The practical mistake here: companies working with an EOR sign the service agreement, assume everything is handled, and then find out on day three that the employment contract wasn’t countersigned or that the payroll bank account wasn’t set up. The EOR service agreement and the employee’s employment contract are two separate documents. Both need to be confirmed complete before the start date.

Set up access and actually test it — two days before, not the morning of

Email, Slack, Jira, GitHub, Confluence, whatever your stack is. All of it should be active and tested at least two business days before the developer’s first morning. Assign someone specific to do this confirmation — not “the team” in the abstract, but one named person.

For Belarus-based employees: check VPN access if any tools apply geographic restrictions. Configure time zones in shared calendars. If your company processes personal data under the GDPR or similar frameworks, ensure the remote work agreement includes the relevant data processing terms. This one is easy to forget and annoying to fix retroactively.

Figure out equipment before the start date, not after

Some EOR providers source hardware locally in Minsk. Others expect the client to send a stipend. Some will ship internationally, which means you can’t control the customs timelines. The point is: this question needs to be resolved at least three weeks before day one, not the week before.

If you’re providing a stipend, check that it covers current hardware prices in Minsk, as prices have risen with inflation. If the EOR is sourcing equipment, get the delivery confirmation in writing. A developer sitting at a borrowed machine on day one doesn’t start well, regardless of how excited they are to join the team.

Write down what the first week looks like and send it ahead of time.

The first week agenda doesn’t need to be elaborate. It needs to exist and be sent before the start date. Day one welcome call, team introduction, codebase walkthrough, day three expectations meeting, end-of-week check-in. Put time on them. Send it to the new hire at least two business days in advance.

In Belarusian IT culture — especially among mid-to-senior developers — a well-prepared first week is read as a signal about the company. It’s not formality for its own sake. It communicates that the employer takes the working relationship seriously. Showing up to day one without a plan communicates the opposite. Experienced developers in a competitive market notice.

Assign a buddy — explicitly, not implicitly

Someone on the team should be designated, before the start date, as the person the new hire can ask anything without it going through the manager. Not “the team” — one specific person, introduced by name in writing before day one, with a brief on who the new hire is and what they’ll be working on.

This matters most in the first two weeks, before the new hire has developed their own sense of who knows what. Without a designated buddy, small questions either pile up silently or get escalated to the manager — neither of which is ideal.

Tell them when they’re getting paid before they start

Belarusian law requires wages to be paid at least twice monthly. In practice this usually means a mid-month advance — roughly 40% of salary — and an end-of-month settlement. The EOR processes all of this. Your job is to communicate the schedule to the new hire before they start.

It sounds minor. Starting a new job without knowing when the first paycheck lands creates unnecessary background noise. A two-sentence message before day one removes it entirely.

Days 1–5: What the First Week Actually Needs to Cover

Each of these steps has a time window. Delay them or try to combine them, and they lose most of their effect.

Day 1: A real welcome call, not a product walkthrough

Thirty to 45 minutes. Video. Direct manager. Morning, adjusted for the time zone gap. The purpose is a conversation, not a presentation — mutual introductions, a brief, honest overview of how the team actually works (not the investor deck version), explicit discussion of communication preferences (which Slack channels, response time expectations, preferred formats), and a clear statement of what success looks like in the first 30 days.

The welcome call sets the tone for the entire manager-employee relationship before any work gets done. First impressions in remote work are formed almost entirely through the first few conversations. It’s worth 15 minutes of preparation.

Day 1: Written team intro — don’t skip it because it feels awkward

Post an introduction to your primary internal channel on the morning of day one. Name, role, background, what they’ll be working on, and — if they’re comfortable — something personal. Ask people to respond. Make it an actual thing, not an afterthought at the bottom of a sprint planning update.

Remote teams consistently skip this because text introductions feel a bit stilted. The result is that new hires spend their first two weeks not sure who anyone is, what they work on, or how to reach out without it being weird. The written intro takes 10 minutes of effort with 2 weeks of payoff.

Day 2: A team call that is not about work

Schedule 20 to 30 minutes — explicitly framed as a “meet the team” call, not a standup or planning session. Informal round of introductions. What each person works on. Space for the new hire to ask questions in a lower-stakes setting than a work meeting.

Teams that skip this because “we have standups” find that new hires take significantly longer to feel like part of the group. The standup communicates task status. This call communicates that there are actual people on the other side of the Slack messages.

Day 2: Check that they can actually find everything

By the end of day two: main code repository, internal wiki or documentation, project management board, design files or specs if relevant, and whatever technical design document they’ll be working against first. Don’t assume they found these independently. Ask directly. Fix access gaps the same day — not “I’ll follow up on that.”

Day 3: Set expectations for the probation period, then write them down

A separate one-on-one — not the welcome call, not a standup — specifically to set probation period expectations. What gets assessed and how. When feedback happens and in what format. What the first deliverable is and when it’s due. What to do if something’s blocked.

Send a follow-up email summarizing what was discussed. Two reasons: it confirms both parties understood the same thing, and it creates a written record from the start of the probation period. If things go wrong later — either a performance issue or a misunderstanding — that written record is useful for both the employer and the EOR provider managing the legal relationship.

Day 3: Confirm HR documentation is actually complete

Is everything signed and processed? Employment contract, tax ID, payroll bank account, and social insurance registration. This is dull to ask about. Incomplete documentation causes payroll delays, and a payroll delay in week one is a relationship-damaging event that takes weeks to recover from.

Day 5: A short call where they do most of the talking

15 to 20 minutes. End of week one. Ask how it went, what was unclear, and what they needed but didn’t have. Listen more than you talk. The content of this conversation is less important than the fact that it happens — it tells the new hire that their first-week experience is considered relevant information, not just their output.

Days 6–30: Turning a Good First Week Into Something That Sticks

Lock in the weekly 1:1 and protect it

The recurring one-on-one with the direct manager should be in the calendar by the end of week one. 30 to 45 minutes, same time each week. In a remote setup, this meeting is the main relationship channel between the employee and the company. Cancellations in the first month don’t just create logistical gaps — they send a message about how much the employee’s time matters. That message is absorbed quickly and lingers.

The format: some task updates, some genuine relationship-building questions, and enough open space that the employee can surface something without needing a formal agenda item to justify it. The manager’s job is to ask specific questions, not wait for concerns to volunteer themselves.

Give them a real task — not a sandbox project

The first assignment should be scoped, genuinely useful, and completable within two weeks. A made-up “welcome task” designed to be trivially easy is worse than nothing — experienced developers read it as a sign that you don’t trust them yet, which is a rough note to start on. A sprawling mission-critical feature with ambiguous requirements and a demo next Friday is also wrong, for the opposite reason.

The right first task has: a clear acceptance criterion, a named person to ask when stuck, a realistic deadline, and actual value to the team when it’s done. The goal is a productive work rhythm and an early opportunity for the new hire to show what they can do.

Set aside 30 minutes in week two to explain the business context

Someone — a product owner, a senior manager, whoever knows the product — should spend half an hour with the new hire answering three questions: what is this product and who uses it, how does this team’s work fit the roadmap, and what are the most important things happening in the next quarter.

Developers who understand the context of their work consistently perform better. They spot problems earlier. They ask better questions. A 30-minute conversation in week two has a compounding effect on the quality of work for months after. Most companies skip it because it’s not urgent. That’s exactly why it keeps getting skipped.

Day 21: Have the feedback conversation before it becomes obvious you need to

Three weeks in, hold a structured feedback conversation that’s separate from the regular 1:1. Not a performance review — a temperature check with a specific agenda: what’s working well and why, one or two areas for development and what support the company will provide, and — this one matters — what the manager or company will do differently based on what the new hire has experienced.

That last part is the piece most managers skip. Asking “what could we be doing better for you?” and then visibly acting on the answer does more for early retention than almost anything else. It also tends to surface practical problems — a broken tool, an unclear process, a missing piece of documentation — before they calcify into frustration.

By week three, adjust how you check in based on this specific person.

Cultural generalizations about Belarusian developers are a useful starting point. By week three, you should be working from actual data about this specific person: how often they update without being asked, how they signal when something’s unclear, how they handle ambiguity in a spec.

The adaptation that consistently improves remote working relationships here isn’t more check-ins — it’s more specific ones. “Is there anything blocked?” is a fine question. “You mentioned the API spec was unclear on Tuesday — has that been resolved, or is it still slowing things down?” is a better one.

Days 31–90: Managing the Probation Period Properly

Write things down throughout — not just at the end

The probation period is a legal window — up to 90 days — during which termination by either party requires only three days’ written notice. No severance obligations, no drawn-out process. That legal flexibility is only useful if there’s a paper trail to support the decisions made during it.

You don’t need a formal HR system. You need a consistent habit: after any significant feedback conversation, send a follow-up email summarizing what was discussed. Keep a log of milestone completions, any cases where expectations weren’t met, any concerns raised, and the support offered. A folder of follow-up emails from the probation period is legally defensible documentation. A verbal conversation from two months ago is not.

Day 60: Do the mid-probation review even if everything seems fine

Around the 60-day mark, hold a structured review: what’s been accomplished against the day-three expectations, an honest account of the employee’s experience (asked genuinely, not summarized by the manager), specific commitments from the company about what will change or continue, and a clear description of what the remaining weeks look like.

Research on onboarding and early-tenure retention consistently shows that the 60-day mark is when initial enthusiasm either converts into genuine commitment or starts quietly eroding. Developers who had competing offers at hire time — which is most good developers in Minsk — make a final internal call somewhere around here. The quality of this review influences that call more than any salary adjustment at month five will.

Check whether their setup is actually working

By month two you should know whether the developer’s working environment is functional. If they’re on a personal laptop that can’t run your dev environment without issues, or they’re working on a desk that’s making everything harder — a stipend or hardware upgrade at this point costs relatively little and signals genuine investment in the person. Waiting until month six to address something that was obvious in month two communicates that you noticed and didn’t act.

Mark the end of probation deliberately

When day 90 arrives, say something. A call, a message, a written confirmation that they’ve completed probation and are a permanent member of the team. It takes two minutes. In companies where this milestone passes in silence, employees notice — and the absence of acknowledgment tends to be read as indifference.

Small moments with clear meaning are more memorable than large moments with ambiguous meaning. This is one of the clearest ones available.

The Master Checklist — All Four Phases

The full process, consolidated by phase, written as actions the client company takes (not the EOR).

Phase 1 — Pre-Onboarding: 2–3 weeks before Day 1

1. Confirm employment contract: signed, compliant, remote work terms explicit.
2. Test all system access (email, Slack/Teams, Jira, GitHub, VPN) — 2 business days before the start date; 1 named person responsible.
3. Resolve equipment
4. Write the first-week agenda and send it at least two business days before Day 1
5. Introduce the buddy in writing before Day 1
6. Tell the new hire when they’ll be paid — mid-month advance structure or equivalent

Phase 2 — First Week: Days 1–5

1. Day 1 morning: welcome call — 30–45 min, manager-led, conversation, not presentation
2. Day 1: written team introduction posted to primary channel
3. Day 2: team introduction call — 20–30 min, informal
4. Day 2: confirm they can find everything — ask directly, fix gaps same day
5. Day 3: expectations-setting 1:1 — probation criteria, first deliverable, feedback cadence, followed by written summary
6. Day 3: Confirm HR documentation is complete with the EOR
7. Day 5: end-of-week call — 15–20 min, employee talks, you listen

Phase 3 — First Month: Days 6–30

1. Weekly 1:1s locked in the calendar by the end of week one — protect them from rescheduling.
2. First real task assigned — scoped, useful, achievable within two weeks.
3. Business context session in week two – product, users, roadmap
4. Day 21: structured feedback conversation – what’s working, where to develop, what the company will do differently
5. Check-in style calibrated to this specific person by week three.

Phase 4 — Probation Period: Days 31–90

1. Written follow-ups after key feedback conversations throughout — build the paper trail.
2. Day 60: mid-probation structured review — accomplishments, employee experience, company commitments, path forward
3. Equipment and environment check — invest now if there’s a gap.
4. Day 90: probation completion acknowledged deliberately, in writing or on a call

Mistakes We See Foreign Companies Make, Reliably

These aren’t theoretical. They appear consistently across companies hiring in Belarus for the first time, across industries and company sizes.

Thinking the EOR is handling onboarding

The EOR manages the employment. The contract, payroll, compliance, and tax filings. It does not run the day-one call, explain what the product does, introduce the new hire to the team, or manage the 90-day performance conversation. Companies that conflate “we hired through an EOR” with “onboarding is covered” arrive at week three with a developer who is fully employed and compliant but has no idea what they’re supposed to be doing.

Using probation as a passive waiting period

The probation period has real legal utility — for both sides. Companies that treat it as “we’ll see how this goes” lose the structured documentation that makes decisions during it legally defensible. They also lose the relationship-building momentum that makes the 90-day mark feel like a meaningful milestone instead of a date that happened to pass.

Not planning around UTC+3 until someone complains about it

Belarus doesn’t observe daylight saving time. It’s UTC+3 year-round. A 9am West Coast standup is 7pm in Minsk. A 4pm Eastern sync is 11pm in Minsk. These are daily realities, not edge cases. Teams that don’t design their meeting schedule around this consistently find that it becomes a quiet source of friction — rarely said aloud, reliably accumulated.

Paying competitively but communicating badly

Belarusian IT professionals leave their roles because of communication quality as often as they leave for better pay. A developer earning a competitive salary but getting no structured feedback, canceled 1:1s, unclear specs, and chaotic project management will be passively interviewed by month four. The salary bought time. The communication quality is what would have kept them.

Skipping the 60-day review because “things seem fine.”

“Things seem fine” is exactly when companies skip this review. It’s also when the developer has the most headroom to absorb a genuine conversation without it feeling like a crisis. The 60-day review is the highest-leverage retention moment in the probation period — not because problems are necessarily present, but because it’s the last point at which you can address forming ones before they become definite ones.

When It Makes Sense to Bring in External HR Support

Most companies hiring one to five people in Belarus can work through this checklist on their own with the support of a qualified HR consulting service. The situations where additional expertise earns its cost:

• Hiring more than five people at once, where onboarding bandwidth becomes a real constraint
• Managing a probation period that is not progressing as expected — documentation and legal compliance become critical, fast
• Operating under HTP (High-Tech Park) residency, where specific tax and labor requirements apply that change standard employment structures
• Planning to transition from EOR to direct employment as the team grows — building a full IT team through your own entity involves legal and HR complexity that benefits from local experience
• Experiencing retention issues in the first six months, which almost always trace back to something specific in the first 30 days

Closing Thoughts

Getting a Belarusian IT developer hired is the beginning, not the end. The 90 days that follow the signing date determine whether that person becomes a productive long-term member of your team or a lesson about what to do differently next time.

The legal framework here — specifically the probation period mechanics and the Labor Code requirements around remote work contracts — means that what happens in those first three months has stakes beyond the HR sense. And the cultural context means that the management approaches that work in co-located, same-timezone teams don’t translate cleanly to Minsk without deliberate adaptation.

Our team has been placing IT professionals in Belarus and supporting the companies that hire them for over a decade. Whether you’re sourcing your first front-end developer, scaling a development team from scratch, or trying to understand why your retention numbers look worse than your hiring numbers — we’re available within two business hours on any working day. The form is below.

Top 5 Mistakes Foreign Companies Make When Hiring in Belarus

The Belarusian IT hiring market in 2026 looks materially different than it did three years ago. The talent base has consolidated around a smaller number of stronger engineers. Salary expectations have moved up. The post-2022 macro context has reshaped how foreign companies approach the market, and how the market responds to them.

Foreign companies entering this market for the first time often arrive with assumptions calibrated to other Eastern European destinations — Vilnius, Warsaw, Bucharest — and find that the playbook doesn’t transfer cleanly. The differences are subtle enough to be missed at the planning stage and expensive enough to matter at the execution stage.

What follows is a structured walk-through of the five mistakes we see most often, with the operational signals that indicate each one is happening and the practical fixes that have worked for our clients. The piece is targeted at companies in the early-evaluation or first-hire stage who would prefer to avoid these mistakes rather than discover them six months in.

For readers who want the deeper structural comparison of the legal models behind the choice, our companion article on EOR vs PEO for hiring in Belarus covers that ground in detail.

Mistake 1: Treating Belarus as a “cheaper Vilnius”

This is the most common framing error in our experience. A foreign company has hired in Lithuania or Poland in the past 18 months, the experience went well, and the team assumes the same approach can be transplanted with a downward salary adjustment. It can’t.

The headline numbers do support a cost-arbitrage thesis. Senior IT roles in Belarus sit roughly between $3,000 and $6,000 per month gross in 2026, with specialist engineers in Golang, Web3, and blockchain commonly higher. By comparison, equivalent roles in Vilnius can run 50 to 80 percent above those numbers. On paper the case for hiring from Belarus is straightforward.

The case becomes less straightforward once a company looks at the full cost structure. The employer-side social security contribution in Belarus, known as the Fund for Social Protection of the Population (FSZN), runs at 34 percent of gross salary. Belgosstrakh adds another 3.5 percent for compulsory insurance. A few smaller obligatory payments push total employer-side statutory cost to roughly 38 percent of gross salary before any service-provider margin. Current rates are published on the Belarus government legal information portal and through the Ministry of Labour and Social Protection.

There is a counterweight to that statutory burden, and it is one of the strongest reasons to hire from Belarus rather than from a neighbouring market: the High-Tech Park (HTP) residency regime. Companies that qualify, or that work with an HTP-resident provider, benefit from a 1 percent tax on revenue in place of standard corporate income tax, plus reduced individual income tax on engineer salaries. Foreign companies that overlook this lever are paying the full statutory burden when they could be paying meaningfully less. Our team handles HTP applications for foreign clients setting up their own entity, and our own outstaffing entity is HTP-resident, which means the benefit is passed through to our service clients automatically. Details are on our HTP residency service page.

The talent pool itself has different characteristics than the regional average. Belarusian senior engineers tend to have stronger formal computer-science backgrounds, a legacy of the Soviet-era technical universities that continued producing strong graduates through the 2000s and 2010s. They also tend to have somewhat thinner exposure to certain Western product-management cultures and the modern toolchains that have become standard at venture-backed product companies in London or Berlin. Neither characteristic is universal, but they’re the patterns. A hiring spec written for Vilnius will produce mismatches when run against the Belarusian market.

What works instead. Build the hiring specification specifically for the Belarusian talent pool rather than transplanting a regional template. Run cost modelling that captures total statutory burden alongside headline salary. Evaluate HTP residency or HTP-resident provider relationships as a structural cost lever before signing into a model that does not access them. And consult someone who knows the specific shape of the pool — what is deep, what is shallow, what is overpriced and what is underpriced — before committing to a spec.

Mistake 2: Letting compensation drift quietly under the radar

The second mistake is structural rather than strategic. A foreign company benchmarks salary at the moment of hire, sets the offer accordingly, signs the contract, and then doesn’t revisit compensation for 18 to 24 months. During that period the Belarusian senior IT market continues to move, and the engineer’s salary gradually slides from “above market” to “below market” without anyone noticing.

Belarusian IT compensation has moved between 8 and 12 percent per year through 2024 and 2025. A salary that sat 10 percent above market at signing can drift to roughly 5 percent below market within twelve months. Two years in, the engineer is materially underpaid relative to what they could earn by changing employers, even though their nominal salary has not changed.

What makes this issue sharper in Belarus than in some other markets is the visibility of the comparison. Belarusian senior engineers can compare their compensation, in real time, against equivalent roles in Vilnius, Warsaw, Berlin, and Tbilisi through Telegram channels, IT meetups, and direct contact with former colleagues who’ve relocated. The information environment makes salary drift much easier to detect for the engineer than for the foreign employer who isn’t in those channels.

The operational consequence shows up as voluntary attrition that clusters in the 18-to-24-month tenure window — a globally observed software-engineering pattern that is sharpened in Belarus by the local visibility dynamics. Reactive correction at the moment an engineer is already considering leaving costs roughly twice what proactive correction would have cost, and even then the save rate is below 50 percent. McKinsey research on European attrition has consistently identified inadequate compensation among the top three reasons European workers leave. SHRM puts the cost of replacing a tech employee at 50 to 60 percent of annual salary as a baseline; other industry analyses run materially higher when knowledge loss is factored in.

What works instead. Run an informal compensation health check at the six-month mark and a full review at twelve months, rather than treating compensation as an annual event. Use current benchmark data — Recruitment.by can create IT salary research covering current Belarusian compensation ranges by role and seniority, and we update it on a regular cadence specifically because annual benchmarks are too slow for this market. Build the review cadence into the operating practice rather than treating it as an exception event triggered by a counter-offer conversation.

Mistake 3: Picking the wrong employment structure (and not noticing for a year)

Of the five mistakes covered here, this is the one that compounds. Foreign companies make a structural choice based on what’s convenient at the moment of first hire, then build a team around the choice, then discover — usually at the 12-to-18-month mark — that the model no longer fits.

Four patterns come up repeatedly:

The contractor-creep trap. A foreign company hires its first Belarusian developer on a freelance or Individual Entrepreneur (IE) contract, with the intent of formalising the structure later. Headcount grows. Eight or twelve hires in, the absence of proper employment infrastructure has become a real exposure: misclassification risk, IP-ownership ambiguity, no benefits administration, no statutory contributions, and a team of people who don’t feel like part of the company because they technically aren’t.

The EOR-at-scale trap. A foreign company starts with EOR — the right choice when they have one to three Belarusian hires — and continues paying per-employee EOR fees as the team grows past 20 people. At that scale the cumulative annual fees substantially exceed what running the company’s own Belarusian entity would cost, but the original setup decision was never revisited.

The outstaffing-for-core-team trap. A foreign company uses an outstaffing arrangement for what is, in operational reality, a permanent core engineering team. The engineers don’t feel like part of the foreign company. Retention suffers. The foreign client never quite gets the team commitment they were paying for, and they can’t understand why.

The PEO-without-entity trap. A foreign company is sold “PEO” by a provider without realising that the Belarusian PEO model assumes the client has, or is creating, a local entity. Without one, the structure either quietly collapses into something that more closely resembles EOR or fails to deliver the expected co-employment benefits at all. American readers should note in particular that Belarusian PEO isn’t the same as US PEO; an American lawyer reading the term in a Belarusian contract may misunderstand who carries which risk.

What works instead. Make the structural choice deliberately at the start, based on a 12-to-24-month projection of headcount and operating intent rather than on what is fastest to set up this week. Build migration provisions into the initial contract so that switching models later — which most foreign companies eventually need to do — does not require destabilising the team. Re-evaluate the structure at the 12-month mark, with the understanding that the right answer in month 12 may be different from the right answer in month 1.

Mistake 4: Running fast-cycle screening for a market that does not reward it

Some foreign companies treat Belarusian IT recruitment as a fast-turnaround pipeline and structure their hiring process accordingly: a thirty-minute initial call, a single technical round, a quick offer. This produces a specific failure mode that’s both predictable and avoidable.

The Belarusian senior IT market in 2026 is competitive but not desperate. Strong candidates have multiple options open to them at any given moment, including options outside the country. Aggressive shortcuts in the screening process are read by candidates as a signal that the company is not taking the hire seriously — which produces self-selection. The candidates willing to accept a rushed process are often the ones who themselves are not being selective. The candidates who would have been the strongest hires politely decline the offer.

There’s a second-order issue. Cultural fit, communication style, and English-language proficiency in working contexts can’t be reliably assessed in a single thirty-minute call. They emerge across multiple structured touchpoints with different members of the team. Companies that compress screening to a single round consistently underestimate this and end up making hires whose fit issues only become visible six months later — inside the period where the cost of departure is highest.

There’s also a context point specific to the post-2022 environment. Some senior Belarusian engineers have become more cautious about new employer relationships, particularly with foreign companies whose long-term commitment to the market is unclear. Those candidates want to understand the company they’re joining, the team they’ll be working with, and the realistic time horizon of the foreign employer’s presence in Belarus. A rushed screening process doesn’t give them the information they need to commit, and the strongest of them will withdraw.

What works instead. A multi-stage screening process spanning two to four weeks: an initial conversation, a technical round, a structured team interaction (so the candidate meets people they’d actually work with), and a final commercial conversation. The total time investment is similar to what a hasty process consumes once the failed hires are factored in — it just gets spent in the right place, before the offer rather than after. Allow time for the engineer to ask their own questions about the company, the team, and the long-term plan. Stack Overflow Developer Survey data consistently shows that engineer satisfaction at hire correlates strongly with the perceived seriousness of the hiring process; this holds in Belarus as well.

Mistake 5: Underinvesting in onboarding and integration

The fifth mistake is the one that companies often don’t recognise as a mistake until well after it’s happened. They hire well, contract correctly, and then drop the new engineer into the team with a Slack invitation, a Notion link, and a vague suggestion to “ping anyone if you have questions.”

Belarusian senior engineers joining a foreign distributed team face specific integration challenges that are easy to underestimate from the foreign side. Time-zone coordination with Berlin, Tel Aviv, or US offices requires explicit norms; without them, the engineer ends up perpetually on call or perpetually misaligned. Internal documentation written for native English speakers, often in shorthand, can be opaque to a new joiner who’s highly competent in English but isn’t immersed in the company’s particular conventions. The product, the customer base, the commercial logic of the business — all of this is obvious to existing team members and invisible to a remote senior engineer joining cold.

Without structured onboarding, the new engineer takes longer to reach full productivity — commonly six months instead of three to four — and the period before they reach productivity is the period where attrition risk is highest. Worse, a poorly structured onboarding sends a signal about the foreign company’s seriousness as an employer. Combined with the career-stability concerns covered in earlier sections, that signal sometimes pushes the engineer to start looking at other opportunities within their first six months.

What works instead. A structured onboarding programme with named milestones at one week, one month, three months, and six months. An assigned onboarding partner — a more senior engineer or a manager who is explicitly responsible for the new hire’s integration during the first 90 days. Scheduled synchronous time with the broader team, the product owners, and (where possible) customer-facing colleagues during the first 30 days. Documentation written for the new joiner rather than for the existing team, particularly around product context, market context, and decision-making conventions.

For clients who want help building the onboarding infrastructure rather than the recruitment alone, our HR consulting service covers programme design and rollout.

A short diagnostic checklist

Run these questions against your current or planned setup. If the answer to any of them is no, that area’s the highest-leverage place to focus before making the next hire.

Have you built your hiring specification specifically for the Belarusian talent market, or transplanted it from another regional market?

Do you have a documented compensation benchmark for the role you are hiring, current within the past six months?

Have you chosen your employment structure — entity, EOR, PEO, outstaffing — based on a 12-to-24-month projection of headcount and intent, or based on what was fastest to set up?

Is your screening process structured across multiple stages, with time built in for the candidate to evaluate you as well?

Do you have a documented onboarding programme for new Belarusian hires that runs at least 90 days?

Have you evaluated HTP residency as a tax-leverage option, either through your own entity or through your employment partner?

If the answers cluster around “no,” the good news is that none of these gaps requires unusual sophistication to close. They mostly require the time and attention to think the next hire through before making it.

Closing thoughts

Hiring well in Belarus in 2026 is entirely achievable. The foreign companies that do it well share a recognisable pattern. They treat the market on its own terms rather than as a generic Eastern European cheap-talent destination. They make structural choices deliberately rather than reactively. And they invest in retention and integration as part of the hiring process rather than treating recruitment as a single completed transaction.

The five mistakes outlined in this article are the ones our team sees most frequently across foreign-client engagements. They are also, fortunately, the ones that are most preventable. None of them require unusual sophistication to avoid — they require thinking the hire through before making it, rather than after.Recruitment.by has worked with foreign companies entering the Belarusian market for over a decade across IT, fintech, forex, crypto, and regulated industries. Our service offering covers IT recruitment, HTP residency setup, EOR, PEO, payroll, HR consulting, and IT outsourcing and outstaffing. If any of the patterns described in this article match what you’re seeing in your own setup, or if you’re evaluating a first hire in Belarus and would prefer to avoid them from the start, contact our team for a 30-minute scoping call. We’ll start from your situation rather than from our service catalogue.