A note on this archive: an earlier version of this site was lost in a migration, with no surviving backup. This piece is a good-faith recreation of our writing from this period, not a recovered original; its date reflects the period it represents. See about this archive.
Outsourcing has always been sold on one number: the hourly rate. It's the first thing in every pitch and the easiest thing to compare on a spreadsheet. But there's a second number that quietly decides whether a project actually ships on schedule, and almost nobody puts it in the spreadsheet — the time difference.
The math nobody runs
Say your team is in Utah and your developer is twelve hours away. You review their work at the end of your day and leave a note: "Quick question — should this handle the empty case?" Then you go home. They start their day, read it, and reply. You see the reply the next morning. One small clarification — the kind a teammate down the hall answers in fifteen seconds — just cost a full calendar day.
Now multiply that by every question, every code review, every "wait, which design did you mean?" over the life of a project. The cheapest hourly rate in the world doesn't help you if a two-week feature takes six weeks because every loop runs overnight.
We wrote a while back that the fear of working with a developer you can't see is mostly a myth. It is — but the part that is not a myth is the clock. Distance in miles you can design around. Distance in hours you cannot.
Why this is changing
For a long time the industry's answer was "send it as far away as possible for the lowest rate." That is getting a harder sell. The companies we talk to lately aren't just asking "what does it cost?" — they're asking "when our developer is awake, are we?" A growing number have been burned by the round-the-clock relay and decided a few hours of shared daylight is worth more than a few dollars off the rate.
That's not a knock on talent anywhere. Great developers are everywhere. It's a knock on the schedule — and the schedule is where outsourcing projects most often go sideways.
What overlap actually buys you
When your developer's working hours overlap with yours, three things change:
- Questions get answered the same day, not the next one. Momentum stops leaking out overnight.
- Code review becomes a conversation, not a batch job you queue up before bed.
- Standups are real. "What are you working on, and what's in your way?" only works if you're both awake to ask and answer.
None of that requires the person to be in your building, or even your country. It requires their afternoon to touch your morning.
The takeaway
When you're weighing an outside developer, don't stop at the rate. Ask how many hours of your workday you'll actually share. We've watched this lesson play out enough times — and made the case before for thinking carefully about where your developers sit — to say it plainly: a slightly higher rate with real overlap usually beats a rock-bottom rate you can only talk to while you're asleep.
The rate is what you pay. The clock is what you wait. Budget for both.