What drives developer compensation, and what a hire really costs

Most companies decide developer pay backwards. They pick a number that feels affordable, post the job, then discover the market’s opinion one rejected offer at a time. The fix is not paying more across the board. It is understanding what actually sets a developer’s price, reading market ranges without fooling yourself, and knowing what a hire truly costs under each employment model before you commit to one. This guide walks through all of it.

The four levers that set a developer’s price

Every developer rate you will ever see, whether a salary, an hourly contractor rate, or an agency quote, is the product of four levers:

1. Seniority. The biggest lever by far, and the one job titles describe worst.
2. Stack and specialty. Premiums appear where supply is thin relative to demand, and they decay as supply catches up.
3. Region. Remote work compressed geography. It did not erase it.
4. Employment model. A salary, a contractor rate, and an agency rate price three different things, and comparing them on the raw number misleads every time.

Get these four right and any benchmark becomes readable. Get them wrong and you will compare a senior contractor’s day rate against a junior salary and conclude the market has lost its mind.

Seniority moves the number more than anything else

The pay gap between a mid-level developer and a genuine staff-level engineer is usually wider than any premium for stack or city. So before you benchmark anything, define what seniority means to you in terms of scope, not years:

• Junior: executes well-defined tasks with review. Needs the problem broken down.
• Mid-level: owns features end to end. Needs the problem defined, not decomposed.
• Senior: owns systems and ambiguity. Turns a vague business problem into a shippable plan, and makes the people around them faster.
• Staff and above: sets direction across teams. Their output is measured in decisions the organization did not get wrong.

Two things follow. First, titles do not transfer between companies: one firm’s senior is another’s mid-level, so benchmark against scope descriptions, never against title strings. Second, the senior premium is not inflation, it is scarcity plus leverage. A strong senior raises the output of everyone whose code they review and whose designs they check, which is why the market prices the jump from mid to senior so steeply and why underpaying for it quietly staffs your hardest problems with people who cannot yet solve them.

Stack and specialty: where the premiums are

Stack premiums are real but they are smaller and less stable than seniority premiums, and they follow one rule: pay rises where supply is thin relative to demand.

Mainstream web stacks (JavaScript and React, Python, general back-end work in Java or C# or Go) have deep talent pools, so they price near the baseline for a given seniority and region. Sustained premiums tend to show up in specialties where the pool is genuinely shallow: machine learning and AI infrastructure, low-level and embedded systems, security engineering, specialized data engineering at scale, and maintenance of legacy platforms that nobody trains on anymore. How large those premiums are at any moment moves with the market, so treat any specific figure you read as dated the day it was published.

Two cautions before you pay a premium. Hot-stack premiums decay: the framework commanding a surcharge today attracts a wave of learners, and the surcharge shrinks within a few years. And a strong generalist can pick up most application-level frameworks in weeks, so pay a stack premium only when the role genuinely needs deep existing expertise, such as performance work, security-critical code, or an ecosystem with years of accumulated sharp edges. Paying a premium for a skill your hire could learn during onboarding is the most common way companies overpay on stack.

Region still matters, even for remote roles

Remote hiring changed the geography of developer pay without deleting it. Broad tiers persist: major US tech markets set the ceiling; secondary US cities, Canada, the UK, and Western Europe sit below that; Eastern Europe and Latin America below that; South and Southeast Asia lower still. The tiers overlap heavily, and strong seniors in lower-cost regions increasingly price against international remote demand rather than their local market, which is exactly why the tiers have compressed.

When you benchmark, this means two things. Match the region and the remote policy of your sources to your own role, because a remote-first company’s numbers do not transfer to an on-site role in a mid-sized city. And understand which game you are playing: hiring remotely in a lower-cost region is a real and legitimate saving, but you are competing there against every other company that had the same idea, and the best people in those markets already know what international employers pay.

Employment model changes what the number even means

The same developer can cost you a salary, a contractor rate, or an agency rate, and the three numbers are not comparable at face value.

A salaried employee’s number is an annual base that comes bundled with everything else: payroll taxes, benefits, equipment, paid time off, and often equity. It buys commitment in both directions, plus the accumulated context that only builds when someone stays.

A contractor’s rate looks high next to salary math because it has to. The contractor carries their own taxes, insurance, benefits, equipment, downtime between engagements, and unbilled hours for sales and admin. A crude conversion mistake is multiplying an hourly rate by 2,080 hours and gasping; independent contractors bill well under a full year of hours, and the rate is set accordingly. Compare a contractor rate against your loaded employee cost, never against base salary.

An agency or network rate includes a margin on top of what the developer receives, and what the margin buys is the honest question. From a good network it buys vetting you would otherwise do yourself, speed to a qualified candidate, a replacement path if the fit is wrong, and administrative simplicity. From a mediocre body shop it buys a markup and nothing else. Ask precisely what stands behind the margin before comparing an agency quote against a direct rate.

How to read rate ranges honestly

There is no single true number for what a senior back-end developer costs. There are several noisy signals, and your job is to triangulate:

1. Broad market data. Crowdsourced level-and-comp sites, compensation platforms, and large annual surveys. These skew toward larger companies and self-selected reporters, so treat them as the optimistic edge of the market rather than the median.
2. Your own pipeline. The asks, accepts, and declines from your last ten developer conversations are the most honest local benchmark you have. Log every candidate’s expectation, even the ones you do not pursue.
3. Job posts with published ranges. Pay transparency rules mean many postings now carry real numbers. Pull ranges from ten posts matching your role, seniority, and region, and you have a free, current dataset.

Reading rules that keep you honest: always note which percentile you are looking at (a 90th percentile number quoted as “the market rate” poisons the whole exercise), match on scope rather than title, and match region and remote policy. Above all, hold every number as a range that moves. Developer markets shift meaningfully within a single year, in both directions, so a benchmark is a hypothesis with a date on it, not an answer. Anyone quoting you a precise figure without a percentile, a region, and a date is selling confidence, not information.

The total cost of an in-house hire vs a contractor

Base salary is the visible fraction of what an employee costs. The loaded version includes:

• Statutory costs: employer payroll taxes and mandatory contributions, which vary widely by country and add a meaningful percentage on top of base everywhere.
• Benefits: health coverage where the employer carries it, retirement matching, insurance, paid vacation and sick leave.
• Tooling and overhead: laptop, software seats, cloud sandboxes, office or coworking cost where it applies.
• Acquisition: recruiter fees or the internal hours your engineers spent interviewing, which are real engineering payroll spent on not engineering.
• Ramp: the months before a new hire is fully productive. You pay full price for partial output during this period on every hire, under every model.

A common rule of thumb puts loaded employee cost at roughly 1.25 to 1.4 times base salary before acquisition and ramp are counted. The exact multiplier depends on your country and benefits, so compute your own rather than borrowing one, but never compare a contractor rate to a bare base salary.

The contractor side of the ledger: a higher visible rate, but you pay only for time worked, carry no benefits, no severance, no equipment in most cases, and the off-ramp is measured in weeks rather than in a termination process. Contractors get expensive in different ways: on long engagements the rate premium compounds past the point where an employee would have been cheaper, context walks out the door when the engagement ends, and a rotating cast of contractors on a core system means you pay repeatedly for the same codebase learning.

A workable decision rule. Bounded or spiky work with a clear end (a migration, an integration, a prototype, extra hands for a defined push) favors a contractor. A core system you will still be maintaining in three years favors an employee, because the context premium beats the rate saving. Urgent work where you lack the ability to vet the skill yourself favors a vetted network, because the margin is buying exactly the thing you cannot produce in-house: verified skill on a short clock.

Build salary bands before the candidate is in the room

A salary band is a range you commit to for a level before any candidate is in the room. If two developers doing the same job at the same level earn very different pay because one negotiated harder, you do not have bands. You have a record of negotiations.

The short version of a workable structure: define four to six levels described by scope, give each band a spread of roughly 20 to 30 percent from bottom to top, overlap adjacent bands so a top-of-band senior can out-earn a bottom-of-band staff engineer, and decide your market position on purpose. Paying at the 50th percentile with strong equity and real ownership is a coherent strategy. So is paying at the 75th with little equity. Paying “competitively” with no definition of competitive is not a strategy, it is a mood.

Write the bands down, even at a five-person company, and refresh them against the market before every comp cycle rather than once at founding. Bands set two years ago are fiction.

The mix: base, bonus, equity

Base salary carries the load; developers, especially seniors, discount everything else. Cash bonuses work when they are simple and believable, and a bonus that needs a spreadsheet to explain should mostly be folded into base. Equity is a genuine bet at an early startup and should be sized and framed like one, with honest talk about dilution and odds. At a later-stage or private-forever company, be careful claiming equity as compensation at all if there is no plausible path to liquidity, because experienced candidates price illiquid paper near zero.

A useful decision rule for each component: would a skeptical senior engineer count this as money? If the honest answer is no, it belongs in the story about upside, not in the comp comparison.

For remote pay, three policies are defensible: location-based rates, one national rate, or one global rate. Any of them can work. What fails is having no policy and improvising per hire, because improvised decisions leak (they always leak) and cannot be defended when they do. Pick one, write down how relocations are handled, and allow no exceptions; one visible exception converts your policy into a rumor.

Negotiation realities

Most compensation negotiation with developers is not haggling, it is calibration: the candidate testing whether your number is real and where they sit inside your structure. A few realities make it go better.

Candidates compare total comp and discount the non-cash parts. A dollar of base is a dollar. A dollar of target bonus is somewhat less. A dollar of private-company equity is much less, and the good candidates run exactly this math. If your offer only wins when equity is counted at face value, you are not winning the candidates you want.

Know what is actually negotiable. Base within the band, the level itself (a candidate above your band is often a candidate you leveled wrong, and re-leveling is honest where quietly breaking the band is not), start date, equity size, vacation, title, remote terms, and a one-time signing amount to bridge a gap without distorting the band. What should not be negotiable is a base above band at the same level, because that decision is permanent and it will leak.

Speed is part of the offer. Good developers hold multiple conversations, and offers decay while approvals crawl. A company that moves from final interview to written offer in two days wins candidates from companies that pay more and decide slower.

Decide your counteroffer policy in advance, while nobody is resigning. By the time someone has interviewed elsewhere and handed you a resignation, a counteroffer fixes the number but not the reason. The real policy is to run the correction before the resignation: review your key people against current market every cycle, and fix gaps proactively. If you do counter, counter once, in writing, with any scope or title changes included, and treat a second resignation within the year as final.

Put the range in the post

After all this work, use it. Publish the band in the job description. Stating a range gets you more senior applicants (who rarely apply blind), filters mismatches before anyone spends an interview hour, and is legally required in a growing list of jurisdictions anyway. Internally, transparent bands convert compensation from a per-person secret into a system people can locate themselves in. You do not have to publish everyone’s salary to get most of the benefit; publishing the structure is enough.

The shortcut

Everything above still applies if you hire through a network, but the hardest part gets easier. The most expensive comp mistakes happen from benchmarking in the dark: three months of interviews before discovering your range is 20 percent under market, or an offer built on stale data that gets declined with no counter. A vetted network like turnkey.dev compresses that discovery, because candidates arrive with rate expectations already known and already screened against the market. Your bands stop being a guess tested one rejected offer at a time and become a sanity check against live numbers. Use this guide to build the structure either way. If you want to skip the dark-benchmarking phase for your next developer hire, tell us the role and we will show you vetted candidates with their expectations attached.