How to compensate remote engineers fairly across geos
How to compensate remote engineers fairly across geos
Pay remote engineers using one of three models: a flat global rate, a location-adjusted rate with a multiplier off your headquarters benchmark, or a fully location-based rate that tracks each city's market. The fairest model for a startup under 50 people is the one you can defend in writing, publish on a Notion page, and apply identically to the next hire. Anything else is improvised.
Most teams improvise. They pay the first engineer what felt right, the second engineer what the first one asked for, and the third engineer whatever it took to close the offer. Six months in, the Buenos Aires senior is making 40% of the New York junior, both of them know it, and now you have a problem you can't fix without a board memo.
This piece walks the three models, the data behind each, the actual dollar tiers we publish at Cadence, and one alternative most founders don't consider: skip the policy entirely and book the work by the week.
The three real models, plain English
The compensation industry talks about geographic pay like it's a spectrum. It isn't. There are three discrete choices, and most companies pick one within their first ten hires whether they meant to or not.
Location-agnostic. Everyone gets the same base for the same role, regardless of where they live. GitLab famously moved off this. Basecamp still uses it. Buffer's transparency post made it the default talking point for remote-first culture in 2017.
Geographic differential. Pick a baseline (almost always your HQ city or San Francisco), then apply a multiplier. Buffer's published version: 100% in Tier 1 cities (Zurich, London, New York), 90% everywhere else. So a P3 engineer at $169,400 in SF earns $152,460 in Berlin.
Location-based. No single baseline. You benchmark each city against its actual local market. Ravio uses this internally with three brackets (London, UK remote, global remote). It's the most accurate, the most operationally heavy, and the one you cannot ship without a comp tool.
What the data actually says
The shorthand "remote killed geo pay" is wrong. Mercer's 2026 read is that San Francisco's pay differential rose from 19% to 26% above national averages over four years. Geographic gaps in tech are intensifying, not collapsing, because the same talent shortage that pushed the SF premium up didn't reach Boise.
The flexibility math complicates it from the other direction. Workers value remote at roughly 8% of salary, and surveys consistently show tech workers will trade up to 25% of total compensation to avoid a daily commute. Hybrid roles command 5 to 15% higher base than fully remote at equivalent seniority, partly because of commuting costs and partly because in-office workers still get the promotion premium.
And the methodology hasn't moved as much as Twitter suggests. Payscale's 2025 state-of-remote report found 86% of organizations have not dramatically changed their pay methodology because of remote work. The loud minority who did (GitLab, Coinbase, Reddit) drove the public conversation; the silent majority kept their pre-pandemic comp bands.
For startup founders, the relevant data point isn't the SF differential. It's that you probably have 5 to 15 engineers, you don't have a comp tool, and you're going to make this call from your phone in the next 72 hours.
The model comparison founders actually need
| Model | When it fits | Hidden cost | Real example |
|---|---|---|---|
| Location-agnostic (flat global) | Pre-Series A, <20 engineers, US-anchored, you can pay top-of-market everywhere | You overpay in low-cost geos by 30-60%, underpay in SF by 10-20%, lose the SF senior you needed | Basecamp; early Buffer |
| Geo differential (multiplier) | 20-100 engineers, multiple time zones, you have a Notion comp page and one person who owns it | The multiplier ages badly; you'll renegotiate every 18 months as cities re-tier | Buffer post-2018; most YC graduates by Series B |
| Location-based (per-city) | 100+ engineers, dedicated comp lead, paying Ravio or Pave for benchmarks | Operational drag; every offer needs a lookup; harder to publish | Stripe; Vercel; most public tech companies |
| Vendor booking (weekly rate, flat global) | Any stage; you want the work shipped without becoming a comp committee | Not your engineer long-term; less culture investment | Cadence; Upwork; agency model |
The honest answer for most founders we talk to is option one (flat global) until headcount forces option two. The honest answer for the work you don't want to staff long-term is option four.
How we set Cadence's tiers (a published, flat, global rate card)
Cadence books engineers by the week. Our pricing is the same in Buenos Aires, Bangalore, Berlin, and Brooklyn. Here it is, exactly as it appears on the booking page:
- Junior, $500/week. Cleanup, dependency hygiene, doc-writing, integrations against well-documented APIs.
- Mid, $1,000/week. Standard features, end-to-end shipping, refactors with test coverage, reasonable judgment without prompting.
- Senior, $1,500/week. Owns scope, mentors, architecture work, complex refactors, performance, handles edge cases unprompted.
- Lead, $2,000/week. Architectural decisions, complex systems design, fractional CTO, scale.
The engineer keeps 80% of the weekly rate. We take a flat 20%. There is no geo multiplier on either side of the transaction. A senior engineer in Ho Chi Minh City earns the same as a senior in Lisbon for the same week's work.
This only holds because the productivity floor is the same. Every engineer on Cadence is AI-native by default; vetted on Cursor, Claude Code, and Copilot fluency in a voice interview before they unlock the platform. We don't have a "non-AI-native" track, because in 2026 we don't think one ships. When the floor is set by tool fluency rather than years in a Bay Area office, geo pay stops mapping to value.
For context: our current engineer pool is 12,800 vetted engineers, median time to first commit on a booking is 27 hours, and 67% of trial bookings convert to an ongoing weekly engagement. Those numbers are what let us hold a flat rate. If the average booking took two weeks to produce shipped code, we'd need geo arbitrage to make the unit economics work.
The "what to do" section for founders setting a policy this quarter
If you're under 20 engineers, write a flat global band and ship it. Publish it on a Notion page accessible to the team. The losses from overpaying in Mexico City are smaller than the losses from one bitter Slack thread when the rate disparity leaks.
If you're 20 to 100 engineers, move to a two-tier or three-tier multiplier. Pick a baseline (don't make it SF unless you literally have engineers there), set a 0.85x to 0.95x multiplier for everywhere else, and apply it to base only. Keep equity and bonus flat globally. This is roughly the Buffer-style structure most YC-stage companies use by Series B.
If you're past 100 and you still don't have a comp tool, you have a different problem. Hire a comp person, buy Ravio or Pave, and benchmark each market individually.
If the work in question is project-shaped, scoped, and you need it shipped in the next four weeks: don't run a comp policy at all. Book it. The fastest path is to find your remote engineer in 2 minutes on Cadence, pay the flat weekly rate, and skip the geo conversation entirely. The 48-hour trial means you're not committed before you know the engineer can ship.
The trade-offs we don't see discussed enough
Every comp model has a politics problem nobody writes about.
Flat global creates a recruiting moat in low-cost geos and a recruiting wound in high-cost ones. You'll have 80 applicants for every Buenos Aires opening and 4 for every San Francisco one. Some founders use this on purpose (build the Latin America engineering team, accept that you can't hire in SF). It's a strategy, but say it out loud.
Differentials create perceived unfairness that compounds. The Berlin engineer doing identical work to the Brooklyn engineer for 90% of the salary knows. The internal Slack will surface it within 18 months. The fix is usually to publish the multiplier and the reasoning, like Buffer did. Hidden differentials destroy trust faster than published ones.
Location-based creates relocation traps. An engineer moves from Lisbon to London for personal reasons and expects the London band. You either give it (and your comp budget blows up) or you don't (and they quit within a year). The companies that handle this best, per Mercer, use temporary relocation allowances that sunset after 18 months rather than permanent salary jumps.
Vendor booking creates a different trade. You don't get to make the engineer a culture investment. They're shipping the work, not joining the offsite. For project work that's a feature; for the next person you want on your founding team, it isn't. Be honest about which bucket the role belongs in.
For more on operating across these dynamics, our breakdown of async communication for engineering teams covers the rituals that make a multi-geo team actually function, and our remote engineering team setup checklist walks through the legal vehicle and payment rails decisions you make before hire one. If you're paying contractors across borders, our Wise vs Deel vs Stripe Connect comparison covers the rails most teams pick from.
Pick the model in writing, then publish it. Whatever you choose, the published version beats the implicit one. If you'd rather skip the policy entirely for project work, Cadence's flat weekly rate is the same in 60+ countries and ships with a 48-hour free trial; the booking takes about two minutes.
FAQ
Should we pay remote engineers the same regardless of location?
Yes, if you're under 20 engineers and your hiring is US-anchored. Flat global is the simplest defensible policy, and the overpayment in low-cost geos is usually cheaper than the operational drag and political cost of multipliers. Past 20 engineers, most teams move to a tier system. The wrong answer is to have no published policy at all.
What multiplier do most companies use for non-headquarters cities?
The most common public benchmark is Buffer's: 100% in Tier 1 cities (SF, NYC, London, Zurich), 90% elsewhere. Mercer's 2026 data shows the SF premium itself has grown from 19% to 26% above national averages, so a multiplier built off SF as baseline ages quickly. Most YC-stage companies use a 0.85x to 0.95x band off a national US median rather than SF.
How do we handle an engineer who relocates to a cheaper or more expensive city?
The defensible policy is to adjust at the next compensation cycle (annual or semi-annual), not immediately. For moves to expensive cities, Mercer recommends a temporary relocation allowance that sunsets after 12-18 months rather than a permanent base salary increase, because the latter is hard to walk back if they move again.
Do remote engineers earn less than hybrid engineers?
Yes, on average. 2026 benchmark data shows hybrid roles command 5 to 15% higher base salaries than equivalent fully remote roles at the same seniority. The driver is partly commuting cost reimbursement and partly the in-office promotion premium. Workers also value remote at roughly 8% of salary, and many will trade up to 25% of total compensation to avoid a commute, which suggests the market price for remote should logically be lower.
How does Cadence handle geo pay for its engineers?
We use a flat global weekly rate at four published tiers ($500 junior, $1,000 mid, $1,500 senior, $2,000 lead). Engineers earn 80% of the weekly rate, the same in every country. The model only works because every engineer is AI-native by baseline (Cursor, Claude Code, Copilot fluency required before unlocking bookings), so the productivity floor is set by tool discipline rather than zip code.
What's the fastest way to start without overthinking it?
Write a one-page comp doc with three things: a flat base by role and seniority, a flat equity grant by level, and a single sentence that says "we do not adjust for location at this stage." Publish it internally. Revisit at 25 engineers or when you make your first non-US hire, whichever comes first. The mistake isn't picking the wrong model; it's not picking one.