Should Remote Salaries Be Localized to Cost of Living?

Every distributed company eventually has to answer a question with no neutral answer: does a software engineer in Lisbon and a software engineer in San Francisco, doing the same job to the same standard, get paid the same amount? Companies that say yes and companies that say no both describe their policy as the fair one, and both are responding to a real constraint — they're just weighting different variables.

The two models, and who actually runs them

GitLab publishes its formula openly: base pay is set from a benchmarked role and level, then multiplied by a location factor derived from cost-of-labor data for that market — a senior engineer in a lower-cost region is paid less in absolute dollars than the same role in San Francisco, deliberately. Buffer runs closer to the opposite: its published salary formula uses role, level, and experience, with location affecting pay far less than the GitLab model, on the stated reasoning that value delivered doesn't change with zip code.

The argument for localization

Localized pay isn't just a cost-saving move dressed up in fairness language, even though it functions as one. The honest case for it is budget sustainability at scale: a company hiring globally without any location adjustment either pays San Francisco rates everywhere — which most companies genuinely can't afford across a large headcount — or quietly caps hiring in high-cost regions entirely, which just moves the inequity somewhere else. Localization lets a company hire broadly while keeping payroll predictable, and it mirrors how cost of labor already varies by market for almost every profession outside tech.

The argument against it

The case against localization is that "cost of living" is a proxy that breaks down under scrutiny. Two engineers doing identical work produce identical value to the business regardless of their rent — pay tied to cost of living effectively taxes people for choosing to live somewhere cheaper, and rewards people for living somewhere expensive, which is close to the opposite of what compensation is supposed to measure. It also creates a strange incentive: an employee on a localized band who relocates to a lower-cost city can see their pay cut for a decision that has nothing to do with their performance, which is a specifically remote-work version of a problem in-office companies never had to solve.

What the retention data actually shows

Neither model is free of turnover risk — they just fail in different places. Localized pay tends to struggle retaining senior talent in lower-cost regions once that talent becomes competitive for location-agnostic offers elsewhere; a strong engineer in a lower-cost-of-living city is exactly the profile most likely to get poached by a company paying location-agnostic rates for the same role. Location-agnostic pay struggles with a different problem: budget ceiling. Companies running it tend to hire more conservatively by headcount, because every hire costs closer to the top of the market rate band regardless of where they're based, which shows up as slower hiring rather than turnover.

A middle path: banded, not fully localized

Most companies that have run localized pay for several years land somewhere between the two extremes — not a precise per-city multiplier, but a small number of broad bands (for example, three or four tiers based on national or regional cost indices rather than exact city data) that reduce the "moved cities, lost pay" problem without abandoning cost control entirely. Fewer, wider bands also cut down on the administrative overhead of maintaining precise location factors for every city an employee might live in — a real cost that pure per-city localization carries and rarely accounts for.

Questions worth answering before picking a model

1. Is the goal to maximize hiring reach at a fixed budget, or to guarantee pay equity for identical roles? These pull toward different models, and pretending otherwise just delays the conflict.
2. How will the policy handle an employee who relocates — pay adjusts immediately, on a delay, or not at all? Decide this before the first relocation happens, not during it.
3. Will the location factor (if any) be published, like GitLab's, or kept internal? Publishing it removes ambiguity but also removes room to negotiate exceptions quietly.

Whichever model a team picks, the same discipline from hiring through an Employer of Record applies to compensation policy generally: the cost of getting it wrong shows up months later as turnover, not immediately as a complaint — so it's worth deciding deliberately rather than defaulting into whichever model came up first in a hiring conversation.