We run a software development operation across the UK and Sri Lanka. It's not always easy. But after doing it for a while, we've figured out what works, what doesn't, and what we wish someone had told us earlier.
This isn't a sales pitch. It's an honest look at distributed team dynamics from a company that lives it every day.
The time zone thing isn't as bad as people think
UK and Sri Lanka have a 5.5-hour time difference. Sounds like a lot. In practice, it gives us a solid 4-5 hour overlap during the working day, which is more than enough for standups, planning sessions, and quick questions.
The unexpected benefit? Work continues while one side sleeps. A developer in Sri Lanka can finish a feature in the evening UK time, and the UK team reviews it first thing in the morning. It's not quite "round-the-clock development" — that phrase is overused — but it does mean things move faster than you'd expect.
Communication needs to be deliberate
In an office, you overhear things. You catch context passively. Remote doesn't have that. So you have to be intentional about it.
What works for us:
- Short daily standups. 15 minutes max. What did you do, what are you doing, anything blocking you.
- Written updates. Not everyone can make every call. A quick summary in Slack means nobody's out of the loop.
- Async by default, sync when it matters. Most things can be a message. Some things need a call. Knowing the difference saves everyone time.
What doesn't work: hour-long meetings that could've been a paragraph. We've all been in those. We try not to inflict them on each other.
Language is an advantage, not a barrier
Our team speaks English and Tamil. For a lot of our clients — especially those in the Tamil-speaking community in the UK and Sri Lanka — this is genuinely valuable.
It's not just about translating words. It's about understanding context. When a client in Jaffna describes their business process, they can do it in Tamil, and our team understands the cultural context behind it. That leads to better software because fewer things get lost in translation.
For our UK clients who speak English only, communication is straightforward. Everyone on the team is comfortable working in English.
Trust takes time, and that's fine
Early on, there's always a phase where the client isn't quite sure if the remote team is actually working when they can't see them. That's human nature, not disrespect.
We handle it by being transparent. Clients get access to our project boards. They can see what's in progress, what's done, and what's next. We send weekly summaries with actual screenshots of progress, not just status labels.
After a few weeks, the trust is usually there. By the end of the first project, most clients stop checking the boards because they know we'll flag anything important.
The cost advantage is real, but context matters
Yes, development costs in Sri Lanka are lower than in the UK. That's not a secret. But the cost difference isn't about "cheap labour" — it's about cost of living. A skilled developer in Colombo has the same capabilities as one in London; they just don't need a London salary to live well.
That said, the cheapest option is rarely the best option. We price our work fairly — enough to attract and retain good developers, not so much that clients overpay. The goal is long-term partnerships, not one-off bargains.
What we'd do differently if we started over
Invest in tooling earlier. We underestimated how much good project management tools matter. Switching from spreadsheets to proper boards and documentation saved hours every week.
Set expectations about response times. Early on, some clients expected instant replies across time zones. Now we set clear expectations upfront — you'll get a response within a few hours during overlap, and by next morning for anything sent outside those hours.
Document everything. When your team is distributed, the answer to "why did we build it this way?" can't be "ask Dave, he was there." It needs to be written down.
Would we recommend this model?
For building software? Absolutely. The combination of UK presence (for trust, compliance, and client meetings) with Sri Lankan talent (for deep engineering and cost efficiency) works really well.
It's not magic. It takes effort, structure, and a genuine commitment to communication. But when it works — and it does work — you get a team that delivers quality software at a fair price, with the flexibility that pure-local teams can't match.
If you're considering working with a distributed team and want to talk through what that looks like in practice, we're always happy to share more.