How to benchmark and structure developer compensation

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 having a system: benchmarks you trust, bands you can defend, a written policy for remote and location, and rules for raises and counteroffers decided before the pressure hits. This guide walks through that system.

Pick benchmarking sources you can actually defend

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

Use three kinds of sources together:

1. Broad market data. Crowdsourced level-and-comp sites, compensation platforms, and large annual salary 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 posts now carry real numbers. Pull ranges from ten postings that match your role, seniority, and region, and you have a free, current dataset.

Reading rules that keep you honest: always note the percentile you are looking at (a 90th percentile number quoted as “the market rate” poisons the whole exercise), match on seniority and not job title (one company’s senior is another’s intermediate), and match on region and remote policy, since a remote-first company’s numbers do not transfer to an on-site role in a mid-sized city.

As a rough orientation, a senior full-stack developer in a North American market often lands somewhere in the low-to-mid six figures in local currency terms, with wide variance by city, company stage, and specialty. Treat any point estimate you read (including that one) as a starting hypothesis, not an answer.

Build bands by seniority, not by negotiation

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.

A workable structure for most teams:

• Define 4 to 6 levels, from junior through staff or principal, each described by scope: executes defined tasks, owns features, owns systems, sets direction across teams. Scope definitions matter more than the numbers, because they are what you point to when someone asks why they are at their level.
• Give each band a spread of roughly 20 to 30 percent from bottom to top. Bottom of band is a solid new hire at that level, top of band is someone about to be promoted.
• Overlap adjacent bands by design. A top-of-band senior should be able to out-earn a bottom-of-band staff engineer. That removes the pressure to promote people into scope they cannot handle just to give them a raise.
• 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. The document forces the arguments to happen once, in the abstract, instead of during every offer.

Structure the mix: base, bonus, equity

The mix matters as much as the total, and developers read it as a signal of what kind of company you are.

Base salary carries the load. Developers, especially seniors, discount everything else. A common failure mode is offering a below-band base “made up for” by a target bonus. Candidates translate that offer to base-only and compare it to the competing base-heavy offer, and you lose.

Cash bonuses work when they are simple and believable. A modest annual bonus tied to company performance is fine. Elaborate individual performance formulas for developers tend to reward ticket-counting and are usually more trouble than the money they steer. If your bonus needs a spreadsheet to explain, fold most of it into base.

Equity is where stage determines everything. At an early startup, options are a genuine bet and should be sized like one: meaningful percentage grants that could matter, offered with honest framing about dilution and the 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. Experienced candidates will price illiquid paper near zero, and pretending otherwise costs you credibility on everything else in the offer.

A useful decision rule: for each component, ask “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.

Write your remote and location policy before your first remote hire

There are three defensible remote pay policies:

1. Location-based pay. You pay the market rate where the employee lives. Cheapest and defensible on cost-of-labor grounds, but it creates visible gaps between teammates doing identical work, and it makes moving cities a comp negotiation.
2. National rate. One rate per country per level, regardless of city. A good middle path: simple to administer, kills the intra-country fairness argument, and only modestly more expensive than city-based pay.
3. Global or single rate. One rate for the role, everywhere you hire. Simplest and best for fairness, most expensive, and mostly used by companies competing directly for the same senior talent as top remote-first firms.

Any of the three can work. What fails is having no policy: improvised, per-hire decisions that leak (they always leak) and cannot be defended when they do. Pick one, write down how relocations are handled, and apply it without exceptions. Exceptions are the whole ballgame; one visible exception converts your policy into a rumor.

Compare total comp, not base, and make candidates do the same

When you benchmark or when a candidate weighs your offer against another, base-to-base comparison misleads in both directions.

Build a simple annual total-comp view for your own offer and put it in the offer letter: base, expected bonus at target, annualized equity value with your assumptions stated, and the cash value of unusual benefits (a real professional development budget, above-norm retirement matching, extended health coverage in markets where that is not standard). Do not inflate it with things like “free snacks” or notional office space savings; padding the number teaches candidates to distrust all of it.

Then be honest about discounting. A dollar of base is worth a dollar. A dollar of target bonus is worth somewhat less. A dollar of private-company equity is worth much less, and how much less depends on stage and terms. If your offer only wins when equity is counted at face value, you are not winning the candidates you want, because the good ones do exactly this math.

Run raises as a cycle, not a series of ambushes

Ad hoc raises reward the people most comfortable asking, which correlates poorly with the people contributing most. The alternative is boring and it works:

• One or two scheduled comp reviews per year. Everyone is reviewed, nobody has to ask.
• Refresh your benchmarks before each cycle, not once at founding. Developer markets move fast in both directions, and bands set two years ago are fiction.
• Position within band follows performance and scope, and the manager can explain each person’s position in one sentence.
• Promotions change bands and are decided on scope already demonstrated, not scope hoped for.

Also budget explicitly for market corrections: when the market moves faster than your merit budget, fixing the gap for your strongest people mid-cycle is dramatically cheaper than replacing them. A useful check before every cycle: “if this person resigned tomorrow, what would we offer their replacement?” If that number is materially above their current pay, you have found the correction budget’s next line item.

Decide your counteroffer policy in advance

Counteroffers are decided in the worst possible conditions: surprise, time pressure, and the immediate pain of a departure. So decide the policy now, while nobody is resigning.

The honest case against counteroffers: the number was never the whole reason. By the time someone has interviewed, gotten an offer, and handed you a resignation, they have mentally left once already. A counteroffer that fixes only pay leaves the scope, manager, or trajectory problem intact, and you have taught the rest of the team that the raise path runs through a competing offer.

The narrow case for them: sometimes the market genuinely moved, the person genuinely wants to stay, and the gap is genuinely just money. If that is true, it was true last month too. Which is the real policy: run the correction before the resignation. Review your key people against current market every cycle and fix gaps proactively. Companies that do this rarely face counteroffer decisions, because the offer their people would get elsewhere is not a surprise.

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 number in the job 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.