Idealump has been building software between Tunis and Tokyo since 2013, with a Paris studio added since. Three time zones, three working cultures, one delivery team. Here's what actually makes that work, and where it took years to get right.
The overlap that matters is Tunis-Paris, not Tunis-Tokyo
Tunis and Paris sit in the same time zone for most of the year. That overlap does the heavy lifting: daily standups, live code review, pairing on a hard bug, all happen in real time without anyone adjusting their schedule. It's easy to underrate how much this changes day-to-day delivery until you've worked the alternative — a nine-hour gap where every miscommunication costs a full day to resolve, because by the time someone reads your message, they're asleep.
Tokyo is the harder edge, seven hours ahead of Tunis. We don't pretend that gap doesn't exist. Client conversations and requirements work happen in Tokyo's morning, which lands as late morning in Tunis — a real overlap window, not the "send an email and hope" pattern that defines most offshore relationships across a full time zone flip. Engineering work that needs deep, uninterrupted focus happens in the Tunis afternoon, after the sync window closes, which turns out to be a reasonable trade: real-time alignment on what to build, followed by uninterrupted time to build it.
Why the same people plan and ship
A structural choice that shapes everything else: the designers and engineers who scope a project are the ones who build it, from the first sketch to the servers it runs on. No handoff from a sales team's understanding of the brief to a delivery team's interpretation of it, no lossy translation between the person who talked to the client and the person who wrote the code.
This sounds like a small process detail, but it removes a failure mode that shows up constantly in outsourced software work: a client explains a nuance in the first call, it doesn't make it into the written spec, and the team that eventually builds the feature never heard the nuance at all. When the same person is in the client call and the pull request review, that nuance doesn't get lost — it doesn't have to survive a handoff to reach the code.
What a decade of doing this taught us
Some of what we do now looks obvious in retrospect and took real friction to learn:
- Overlap windows should be short and dense, not long and thin. A two-hour block where both sides are fully present and focused resolves more than a six-hour window where everyone's half-attending between other work.
- Async updates need to answer a question, not just report status. "Here's what we did today" is filler if it doesn't tell the other side whether a decision is needed from them before tomorrow's overlap window.
- Written specs still miss things a live conversation catches. No amount of documentation discipline replaces having the person who'll build a feature in the room when it's being defined — which is exactly why we don't separate those roles.
Why this structure, and not a bigger office in one place
Consolidating into a single location — an all-Tokyo team, or an all-Tunis team — would remove the time zone coordination problem entirely. It would also remove the reason clients in Japan and France work with us: access to a studio that understands what a Tokyo client needs and a European client needs, staffed by engineers who've spent over a decade building exactly this kind of cross-border delivery muscle, rather than assembling a team for a single project and disbanding it after.
The coordination cost is real. It's also the same cost that produces the thing clients are actually paying for: a team that ships software fluently across working cultures that don't naturally overlap on their own.