The time zone, as arithmetic rather than a promise
Your working day against India Standard Time (IST, UTC+5:30)| Your location | Your 9:00 am in Delhi | 6:30 pm in Delhi, your time |
|---|
| London (BST, summer) | 1:30 pm | 2:00 pm |
|---|
| London (GMT, winter) | 2:30 pm | 1:00 pm |
|---|
| New York (EDT, summer) | 6:30 pm | 9:00 am |
|---|
| New York (EST, winter) | 7:30 pm | 8:00 am |
|---|
| San Francisco (PDT, summer) | 9:30 pm | 6:00 am |
|---|
| Dubai (GST) | 10:30 am | 5:00 pm |
|---|
| Singapore (SGT) | 6:30 am | 9:00 pm |
|---|
We work from Delhi NCR, on IST. Against a UK working day the overlap is comfortable: a 2:00 pm IST start meets a UK morning with several hours in common. Against US Eastern the workable window is an early-evening IST session against a US morning, and against US Pacific it is narrower still and has to be planned rather than hoped for.
What matters is agreeing that window before the engagement starts and staffing it deliberately, so the people who can answer a question are online when the question gets asked. An engagement that relies on someone being awake at midnight is not a schedule; it is an accident waiting for a deadline.
Written decisions, because the corridor conversation does not exist
Co-located teams absorb a lot of context informally. Distributed ones do not, so context has to be written down: what was decided, what it rules out, and who to ask when it turns out to be wrong.
Our seven delivery stages each carry a named owner and a deliverable for exactly this reason. It is process that exists to remove guesswork rather than to add ceremony — the difference between documentation that helps and documentation nobody reads.
We already build for overseas markets
Three Lock Box is a paperless escrow and payment platform serving the US construction industry, built with ASP.NET Core and MongoDB. EZRater is a comparative rating platform for US surplus lines insurance, solving ACORD interoperability across more than forty carrier integrations.
Both are domains where a misunderstanding is expensive and the regulatory detail is unforgiving. Neither is a market we could have served by treating requirements as a list of tickets to implement.
How to evaluate any offshore vendor, including us
- Who owns the code, and is it in your repositories from the first commit or handed over at the end?
- Which hours overlap with your working day, and who is actually online during them?
- Where are decisions written down, and can you read them without asking?
- How often do you see working software rather than a status report?
- Can you speak to a client whose project resembles yours, in your own market?
- What happens to the work, the documentation and the deployment access if the engagement ends?
A vendor worth hiring answers all six without hesitation, and in writing. Vague answers to the first and the last are the ones to take most seriously, because they decide whether you can walk away with a running system.
What stays in your hands
Your repositories, your cloud accounts, your documentation — from the first commit rather than at handover. Distance makes this more important, not less: the protection against an offshore engagement going wrong is that you can always see and always take back the work.
The stack is the same one we use for domestic work: React, Next.js, Angular or Vue; Node.js, Django or .NET; PostgreSQL, MySQL or MongoDB; Docker, Kubernetes and CI/CD pipelines on AWS, Azure or Google Cloud.
