Manila runs 13 hours ahead of US Eastern in winter and 12 ahead in summer [T4]. Start your day at 9am in New York and the Philippine workday is already finished. There is effectively no natural overlap of standard business hours, and that is the first thing a US buyer thinks about the Philippines. It should be.
Here's the part that usually gets skipped. The gap is only a cost for work that needs same-hours collaboration. For work that's specified before it starts, it inverts: you hand off at the end of your day and read the result at the start of the next one. Whether the gap helps or hurts is a property of how the work is written down, not of the map.
This is our case for one delivery geography. We build in the Philippines and we're arguing for it, and you should read it that way. If you want the longer version with every figure and its source, including the ones that make our case harder, it's in our evidence review of the Philippines as a delivery destination.
The paper people quote at offshore teams is Herbsleb and Mockus. It's worth reading past the abstract.
The headline finding is real. Distributed work items took about two and a half times as long as colocated ones on the active-work interval [A4]. Stop there and geography looks expensive.
They didn't stop there. Controlling for the other factors, including how many people a change had to involve, distributed items were no longer significantly slower [A6]. Their own explanation: splitting work across sites slows it down "primarily because it requires the involvement of more people than comparable work accomplished all at one site" [A6].
The delay pattern says the same thing. Cross-site delays happened about as often as local ones. They just lasted longer, 2.4 days against 0.9 [A7]. Distance isn't creating the blockages. Each blockage simply has more people and more waiting packed into it.
Date it honestly: this is Lucent change-request data from 1997 to 1999 [A5], before Git, before CI, before Slack. It's the most-cited study in the field and it's old. But the mechanism it names is the one you can still act on. Team design and batch size are levers you control. The map isn't.
Follow-the-sun, where work is handed off every evening and comes back finished, is what most offshore vendors sell. The research does not support it.
Carmel's foundational paper concedes in its own abstract that FTS "has enjoyed few documented industry successes because it is acknowledged to be extremely difficult to implement" [FS1]. That was 2010. The most recent systematic mapping study, covering 57 papers, still names the field's open need as testing FTS "feasibility and effectiveness in practice" [FS4]. Nearly three decades in, nobody has shown that continuous daily handoff reliably works, and we're not going to be the first to claim it.
The defensible version is narrower and one-directional. Not work passed back and forth every night, but a single overnight leg on small, well-specified items. You write the ticket, we build it, you review the diff in your morning.
The evidence for that shape is strong, and it's about batch size rather than time zones. Google's code review is fully asynchronous, with a median end-to-end latency under four hours and 70% of changes committed within 24 hours of being sent for review [AS18, AS19]. The paper attributes that to a median change of 24 lines and a median reviewer count of one [AS21], not to asynchrony. Across 291 open-source GitHub projects, 30% of pull requests merge in under an hour and 80% within 3.7 days [AS24].
So the prescription is specific: split along architectural seams, and only split work that's well understood, where plans and interfaces are stable [EM23]. What fits the overnight leg is specified build work, code review, test cycles, and unattended CI on a schedule [FS16]. What doesn't fit is live product discovery, incident response, and pairing. Send those into the gap and the gap wins.
The real alternative for a US buyer isn't India. It's Latin America, and English is where that comparison separates.
On EF's 2025 English Proficiency Index the Philippines ranks 28th globally with a score of 569 [E5]. Brazil is 75th at 482 [E9], Colombia 76th at 480 [E10], Mexico 103rd at 440 [E11]. Those aren't close.
One index proves nothing, so here's a second and independent one. IELTS Academic results for 2024–25, published by the test owner, put the Philippine mean overall band at 6.81, above India at 6.58, Mexico at 6.54 and Colombia at 6.53 [EN5]. There's a structural reason underneath both: English is a statutory medium of instruction in Philippine schools under the 2013 Enhanced Basic Education Act [EN13].
The Philippines doesn't lead on every instrument. Argentina edges it on EF at 26th and 575 [E4], and the ranking shifts again on IELTS General Training [EN6] and on TOEFL, where ETS states plainly that ranking countries by score is "a misuse of data" [EN7, EN9]. Consistently strong across measures is the claim. Best is not.
Legal familiarity is underrated right up until the first dispute.
The Philippine legal system is expressly a blend that includes Anglo-American common law [PH6]. Philippine law libraries carry US court reports, West's national reporter system, American Jurisprudence and Corpus Juris Secundum as standard holdings [PH7]. Philippine Supreme Court decisions were once appealable to the US Supreme Court [PH8]. That account comes from a country guide written by the Supreme Court of the Philippines' own Director of Library Services, which is about as good as provenance gets.
It isn't a clean sweep. On the US Chamber's 2026 International IP Index the Philippines ranks 36th of 55 at 40.64% [K8, K9], which is 9th of 15 in Asia and below the Asia average [PH3]. Know that going in and write your IP assignment accordingly.
GitHub's 2024 Octoverse put the Philippines at #18 globally, overtaking Australia at #19, growing 29% year over year on a base above 1.7 million. That was the fastest growth in GitHub's Asia-Pacific table, ahead of India's 28% [TL22].
Now the correction, because we'd rather you had the real number than the flattering one. Octoverse counts accounts, not employed developers [P2]. And the figure quoted everywhere, 1.9 million, is the whole IT-BPM sector, which is overwhelmingly contact-center work [R26]. Formal computer-programming employment in the Philippines is 90,573 [P7]. The defensible bracket for working software developers is roughly 90,000 to 200,000.
That's an order of magnitude below the headline and still deep enough to staff from. Any vendor quoting you 1.9 million developers either hasn't checked or is counting on you not to. It also changes how you shop: a pool that size means the Philippine vendor market is worth reading name by name.
Most cost comparisons in this market are broken in the same way: they put a salary next to a price and treat the two as the same number. A salary is what a developer earns. A price is what you pay. Nobody publishes a methodology-backed bill rate for any region, so the salary usually gets drafted in to stand where a price should be [R27].
Here is the comparison that is actually like for like — what a US developer costs an employer each month, against what a subscription costs a buyer each month. Both in dollars. No conversion, no proxy.
Start with the employer's side. The US median annual wage for software developers is $135,980 [R1]. That is not the cost. The recurring fully-loaded figure — base plus payroll taxes, health insurance, retirement, equipment, software and workspace — runs 1.25 to 1.4 times base salary, with benefits alone accounting for roughly a third of total compensation [C1]. Applied to the median, that is about $14,200 to $15,900 a month, every month the seat stays filled.
Now ours. Dev On Demand is $3,495 a month for one dedicated engineer. That is roughly a quarter of the fully-loaded monthly cost of a US developer at the national median, and it is the entire line item on your side of the ledger: no benefits load, no employer payroll tax, no recruiting fee, no equipment budget, no cost of an empty seat while a role stays open.
Three things keep that comparison honest. The $3,495 is our price, not a market rate for Philippine engineering. The 1.25–1.4× multiplier is a general employer figure rather than a developer-specific one [C1]. And it is deliberately the conservative version: it counts only the recurring load, and leaves out recruiting spend and the ramp months a new hire is paid through before full output arrives — both of which push a first-year hire well above that band.
The mechanism above is the one the delivery model is built on.
Dev On Demand "runs async by design" and "timezone alignment isn't required", which is only defensible because the unit of work is small and singly-owned, the way the code-review evidence says it has to be. "Submit a task, matched same-day" keeps down the number of people a change passes through, which is the variable Herbsleb and Mockus actually found predicted delay [A6]. A "3-day task cycle, daily async updates" and a "5-day first ship" are batch sizes, not claims about time zones. Engineering is "distributed, headquartered in Manila".
Two hours of the gap are also negotiable. We move the Philippine working day by up to two hours in either direction when a client wants more contact time, and it's worth being precise about what that buys, because it does different things on different coasts. Taking a nine-to-six day at both ends: shifted two hours earlier, the day widens the live window with the US West Coast from one hour to three against Pacific Standard Time, and from nothing to two against Pacific Daylight. Shifted two hours later, it does not create overlap with the East Coast, because the gap is too wide for two hours to close: what it does instead is halve the handoff, so work lands one to two hours ahead of your morning rather than three to four, and is waiting when you open the laptop rather than having sat overnight. Both of those are arithmetic from the standard offsets [T4], not a claim about how fast anyone replies.
Written specification is still the price of admission. If the ticket isn't clear, the overnight leg becomes an overnight round-trip and you've bought the bad version.
Two different answers live here, and running them together would cost you either way.
Don't buy Dev On Demand for incident response. A "3-day task cycle" is a delivery rhythm, not a pager. If a 2am alert needs somebody awake and accountable in the moment, a task subscription is the wrong instrument regardless of where the engineer sits or how well you write tickets.
That's an argument about the instrument, though, not about the geography or the company. Where we build a system and then keep it running, the service is Managed AI Automation, described on our own site as "Designed, deployed and run by us", with "Continuous monitoring, regular performance reports, managed by our team". Be precise about what the site does and does not promise: the "4-hour response" published there is the response time on enquiries to our inbox, not an incident-response guarantee, and no SLA terms are published anywhere on the site. Response commitments for a managed engagement are scoped per contract, so get them in writing before you rely on them. The short version: if what you need is someone owning a running system, that's a different conversation than this page is having.
What argues against us whatever the service is work that gets decided in the moment: live product discovery, and pairing with a product owner who thinks out loud and settles it on the call. Those want same-hours overlap. Colombia sits at a zero-to-one-hour gap from US Eastern with a full business-day overlap year round [T5]. That's unarguable, and no quantity of good written process substitutes for it.
The honest test sits upstream of geography: can the work be specified before it starts? If yes, the 12-hour gap is an overnight cycle. If no, it's a 12-hour gap — and your options are to move the schedules two hours toward each other, buy a different service, or buy a different coast.
