Follow-the-Sun Software Delivery: 24/7 Engineering Across 3 Hubs.

The model

Three synced hubs: Paris (CET), Montréal (EST), Tokyo (JST). Every ticket follows the sun — Paris starts in the morning, hands off at 6 PM CET to Montréal, Montréal hands off at 6 PM EST to Tokyo, Tokyo hands off at 6 PM JST back to Paris. Roadmap moves while you sleep. No magic: just disciplined orchestration.

• Paris 9 AM–6 PM CET → handoff 6 PM CET (= 12 PM EST) → Montréal picks up
• Montréal 12 PM–9 PM EST → handoff 9 PM EST (= 10 AM JST D+1) → Tokyo picks up
• Tokyo 10 AM–7 PM JST → handoff 7 PM JST (= 11 AM CET) → Paris picks up
• Structured 1-hour overlap at start/end of each hub: the baton is never dropped

Why this is not offshoring

Classic offshoring sells low-cost man-days from India or the Philippines with a PM who translates. The result: slowing roadmap (zero overlap with France), degrading quality (zero client context), compliance backlash (GDPR, banking secrecy). Abbeal's tri-geo is the architectural opposite:

• Tokyo / Montréal / Paris hubs = same senior day rate (not low-cost)
• Local hiring by engineers (not HR recruiters)
• Daily 1h × 2 overlap between hubs (vs 0 in offshoring)
• End-to-end ownership per hub (vs ticket-ping-pong) — 3 autonomous squads
• Native European compliance (GDPR, ACPR, SecNumCloud) across all hubs

How it works concretely — 5 pillars

1. Written handoff, not verbal

At end of day, the leaving hub writes a state-of-play: 3 lines per ticket-in-progress, identified blockers, expected next action. No handover meeting — context fits in a ticket comment readable in 90 seconds. The incoming hub reads before coffee.

2. Sacred overlap — 1h × 2 per day

Overlap windows (Paris 5-6 PM ↔ Montréal 11 AM-12 PM, Tokyo 6-7 PM ↔ Paris 10-11 AM) are sanctuarized: no internal meetings allowed, reserved for active handoff and synchronous client questions. If nothing to say during overlap, fill it with PR review.

3. Calibrated ticket size

A ticket must complete in one shift or be explicitly passed at overlap. If a ticket exceeds 2 person-days, we split it. Not for abstract agile reasons — so context fits in a written handoff.

4. Ownership by time zone

Each hub squad owns technical responsibility for a functional domain (e.g. Paris = backend payment, Montréal = data ingestion, Tokyo = mobile API). Avoids the "who touched what" syndrome that destroys offshoring.

5. Full local run per hub

Each hub must run the full environment locally (docker-compose or equivalent). No critical dependency on a stack that only runs in Paris. That's why Tokyo can ship a prod fix at 3 AM Paris time without waking anyone.

Use cases: what's running in production

Three concrete examples, drawn from already-deployed client cases:

• European FinTech SaaS — ISO 27001 delivered in 9 months (vs 18 estimated) thanks to tri-geo. DevSecOps audit Paris, pipeline automation Montréal, compliance docs Tokyo. SOC 2 chained right after.
• Sports e-commerce leader — PWA refactor, +18% mobile conversion in 6 months. Frontend Paris, Lighthouse perfs Montréal, A/B testing JP. Lighthouse 92 mobile score.
• Japanese industrial robotics — fleet of 80 ROS 2 AGVs, +40% warehouse throughput. Embedded Rust stack Tokyo, Isaac Sim Paris, monitoring Montréal.