How to work with a remote developer in a different timezone

Working with a remote developer in a different timezone hinges on three rules: design the week around your overlap window (zero, partial, or full), default to async-by-writing for everything outside it, and enforce a "no surprises" SLA so blockers surface within 4 hours of being hit. Get those three right and a 9-hour gap turns into a feature, not a bug.

The setup: why timezones break founder builds

You hired well. The engineer is sharp, the spec is clean, the first commit landed Monday. By Thursday you are stuck because a config decision you flagged at 9pm your time has a 14-hour round-trip, and your Friday demo just slipped to Tuesday.

This is the most common silent failure mode for founders running global teams. The work is fine. The cadence is broken.

The fix is not "make them work your hours." It is to pick the right collaboration pattern for the actual overlap you have, then build the week around that pattern instead of around feature tickets.

Overlap quality determines everything

Before you do anything else, count the overlap hours. Treat 9am to 6pm as both sides' working window and intersect them. You get one of three buckets.

Overlap window	Typical pairings	Recommended workflow	Best-fit work
Zero overlap (0 hours)	SF + Manila, NYC + Bangalore weekend mode	Pure async, written specs, end-of-day handoffs, Loom-first	Greenfield features with clean specs, refactors, infra hardening
Partial overlap (2-4 hours)	NYC + Lisbon, London + Bangalore, SF + Mexico City	Hybrid: async PRs + one daily sync window	Standard feature work, integrations, anything with normal ambiguity
Full overlap (5+ hours)	NYC + Buenos Aires, London + Berlin, SF + Vancouver	Mostly synchronous, normal Slack cadence	Pair programming, debugging unknown unknowns, design sprints

Most founder pain comes from running a zero-overlap pairing on a partial-overlap workflow, or worse, a partial-overlap pairing on a full-overlap workflow. The pattern has to match the geography.

Workflow 1: zero overlap (the "follow the sun" model)

This is the hardest setup and also the most powerful when it works. You sleep, they ship. They sleep, you review. Done well, you get 18 productive hours per calendar day.

It only works if four things are true:

1. The scope is written down with enough specificity that nobody has to ask a clarifying question to start.
2. Every handoff is recorded (Loom or written), not waiting in a Slack DM you both have to be online to read.
3. There is a "no surprises" SLA: if the engineer hits a blocker, they file a Linear ticket with blocked: prefix within 4 hours of hitting it, and you respond inside your next working window.
4. Code review windows are explicit. Engineer pushes the PR at end of their day. You review and merge (or comment) inside your morning. Loop closes in 24 hours, every time.

The danger here is "I will just ask quickly on Slack" creep. Every quick question costs a calendar day. The discipline is treating Slack as a logging channel and Linear plus Loom as the actual workflow.

A sample week in zero-overlap mode looks like this:

Day	Founder (NYC)	Engineer (Manila)
Mon AM	Review Friday's PR, write Monday spec	(sleeping)
Mon PM	(offline)	Pull spec, ship first commit, push PR by EOD
Tue AM	Review PR, comment, write next spec	(sleeping)
Tue PM	(offline)	Address comments, ship next slice
Fri AM	Review week, queue weekend work	(sleeping)
Fri 9pm NYC / Sat 10am MNL	30-min weekly sync (the only required call)	Weekly sync

That 30-minute Friday sync is the only required synchronous moment. Everything else routes through written artifacts.

Workflow 2: partial overlap (the 2-4 hour sweet spot)

A 2-4 hour overlap is the most common founder situation, and it is also the workflow most likely to be run wrong. The mistake is to fill the overlap with status updates instead of decisions.

Treat the overlap window like an expensive resource. Use it for:

• Unblocking anything that needs back-and-forth (architecture decisions, ambiguous specs, debugging mystery errors)
• One short standup (10 minutes, not 30) at the start of the window
• Live demos of anything just shipped

Do NOT use it for:

• Status updates that a Linear comment covers
• Code review (do that async, outside the window)
• "Let me explain this Figma" (record a Loom instead, then answer questions live)

The 90-minute weekly sync rule applies here too. One longer Monday or Friday call (90 minutes max) covers the week's planning, retro, and any architecture decisions that need a whiteboard. Everything else is the short daily overlap plus async.

For PRs in partial-overlap mode, the rule is "review inside the next overlap window." If the engineer pushes a PR at 9am their time and your overlap is 3-6pm their time, the PR is reviewed and merged or commented by 4pm their time. No PR sits more than one overlap cycle without movement.

Workflow 3: full overlap (the easy mode, with hidden costs)

When you have 5+ hours of overlap, most things just work the way they would in a colocated team. Slack stays warm. Pair programming is cheap. Debugging happens in real time.

The hidden cost is meeting drift. Founders with full overlap tend to schedule 4-6 hours of calls per week, which crushes the engineer's deep-work time. The same 30-90 minute weekly sync rule still applies. A senior engineer should ship 25-30 hours of focused work per week, and that math does not survive five 1-hour meetings.

Full overlap is also where founders are tempted to skip the written spec because "we can just talk." Do not. Even in full-overlap mode, the prompt-as-spec discipline (every engineer on Cadence is AI-native, vetted on Cursor, Claude, and Copilot fluency before they unlock bookings, so they expect written specs anyway) is what makes the work fast.

The "no surprises" SLA

Across all three workflows, one rule does more for trust than any other: no surprises.

A no-surprises SLA means the engineer commits to flagging anything that will slip, block, or change scope inside 4 working hours of noticing it. Not at end of day. Not at the next sync. Within 4 hours.

In practice this is:

• Blocker hit at 11am their time? Linear ticket with blocked: prefix by 3pm their time.
• Realized the spec is wrong and will take 2x longer? Loom recorded and posted by end of working day, plus a Linear update.
• Found a bug in upstream code that changes the approach? Slack ping plus written summary, not a 15-minute monologue.

The point is to convert surprises into early signals. A 4-hour SLA on bad news means the founder always has a full working day to react, even in a zero-overlap pairing. Most timezone disasters are not the gap; they are the gap plus a 36-hour silence.

The async toolchain

The specific tools matter less than that they are consistent. A standard async stack:

• Linear for tickets, spec, status. Every PR ties to a Linear ticket. Every blocker is a Linear comment, not a Slack DM.
• Loom for anything that would have been a meeting. 5-minute walkthroughs of decisions, demos of new features, screen recordings of bugs.
• GitHub PRs with detailed descriptions. No "fixed the thing" commits. The PR is the artifact your future self reads when something breaks in 6 months.
• Slack as the logging channel. Important decisions get written up elsewhere and pasted in. Slack is searchable but ephemeral; trust it for "I am online" signals, not for decisions.
• One shared doc per major decision. Notion, Google Docs, even a markdown file in the repo. Architecture decisions live somewhere a non-coding cofounder can read them.

For founders who can't code, the same toolchain doubles as your read-only window into the work. You can evaluate a developer's GitHub progress through PR descriptions and Loom recordings without ever asking a synchronous status update.

Common founder mistakes when running timezone-split builds

Five patterns burn more money than anything else:

1. Booking a full-time hire for an unvalidated MVP. A 60-day hiring loop plus a 90-day notice period is the wrong instrument for "I need to ship in 6 weeks." Weekly billing exists for exactly this gap.
2. Trying to force synchronous hours. Asking the engineer to work 2am-10am their time burns them out in 3 weeks and you lose institutional knowledge.
3. Skipping the written spec because "we can just sync." This is the partial-overlap workflow run on a zero-overlap pairing. Every "quick sync" costs a calendar day.
4. No weekly retro. Without a 30-90 minute weekly retro you don't catch the cadence problems until week 4, by which point you've burned $4k-$8k on the wrong workflow.
5. Hiring a senior when a mid is the right tier. A mid engineer ($1,000/week on Cadence) handles standard async feature work fine. You only need a senior ($1,500/week) when scope ownership and architecture judgment matter.

If you find yourself stuck on the wrong workflow, common founder mistakes when hiring developers covers the diagnosis flow in more depth.

What to do this week

If you have a remote engineer right now and the cadence feels off, do three things in this order:

1. Count the overlap. Pick the matching workflow from the table above. If you're running the wrong one, switch on Monday.
2. Install the no-surprises SLA. Write it into your engineer agreement or Notion onboarding doc. 4 hours, in writing, both sides.
3. Pick one Loom-first rule. "Every PR over 200 lines gets a Loom walkthrough." Or "every architecture decision is a Loom plus a doc." One concrete rule beats five abstract ones.

If you are starting a new engagement and the overlap is rough, the fastest path is to book on a marketplace built for this. On Cadence, every engineer is AI-native by default (Cursor, Claude, Copilot vetted in a voice interview before they unlock bookings), and weekly billing with a 48-hour free trial means you can test the cadence for two days before committing. Book your first engineer and run the trial against your actual overlap window before you spend hiring time.

The Cadence connection

For short-scope or pre-PMF work, booking weekly is the right instrument for timezone-split builds. The 48-hour free trial means you can validate the cadence (not just the code) before any money changes hands. Daily ratings drive auto-replacement, so if the no-surprises SLA breaks down inside week 1, you can swap engineers without a notice period or recruiter call.

This matters most for the partial-overlap and zero-overlap cases, because the cost of a bad cadence pairing compounds: a 14-hour silence on Tuesday is a missed Friday demo is a missed investor update is a slipped quarter. Catching that mismatch on day 2 of a free trial is dramatically cheaper than catching it in week 6 of a full-time hire.

Try a 48-hour trial. Book a mid or senior engineer with the timezone overlap you actually want, run the no-surprises SLA for two days, and only convert to a paid week if the cadence holds.

If your project is earlier than that and you're still validating the idea, the booking math is wrong. Read how to ship from idea to revenue in 90 days before you hire anyone.

FAQ

How many hours of overlap do I actually need?

Two to four hours of overlap is the sweet spot for most founder-engineer pairings. Zero overlap works if the scope is well-defined and both sides are disciplined about written handoffs; full overlap (5+ hours) is rarely necessary and often a sign you are over-meeting.

What's the best timezone for hiring a remote developer if I'm in NYC?

For partial overlap, Lisbon, Buenos Aires, and São Paulo all give you 3-5 hours of useful overlap. For follow-the-sun, Bangalore or Manila is the textbook setup. For full overlap, anywhere in Latin America from Mexico City to Buenos Aires works.

How do I handle code review across timezones?

In zero-overlap pairings, the engineer pushes the PR at the end of their day; you review inside your next working window. In partial-overlap pairings, the rule is "review inside the next overlap window." Either way, no PR sits more than 24 hours without movement.

Should I use Slack, email, or Linear for blockers?

Linear, with a blocked: prefix or label. Slack is for "I am online" signals; email is too slow. Linear gives you a searchable record of every blocker, who responded, and how long it took to clear, which is the data you need for the Friday retro.

What's the cheapest way to test a timezone pairing?

Run a 48-hour free trial with a mid-tier engineer ($1,000/week on Cadence). For $0 spent, you get two real working days of evidence on whether the overlap window, async tooling, and no-surprises SLA actually hold up for your scope.