Overseas delivery
Built in India. Accountable in your time zone.
We publish and contract a daily overlap window for every market we serve, from four and a half hours for North America to eight hours for the Gulf, and we staff shifts to hold it. On top of the hours sits the part that actually decides whether overseas delivery works: a named delivery lead, a written communication protocol with response-time commitments per channel, a three-tier escalation ladder, and an asynchronous-first working discipline.
- 10 delivery markets with a written overlap commitment each
- A named delivery lead in the contract, not an account manager
- Escalation to the founder within one business day, with names and numbers
- Written decision records and recorded demos as standard practice
Delivery facts
- Delivery hubs
- Dehradun and Bengaluru, India
- Overlap commitment
- 4–8 hrs daily, contractual by market
- Working week
- Monday to Friday, plus Sunday to Thursday cover for Saudi Arabia
- Standard hours
- Monday to Friday, 09:30 to 19:00 IST
- Escalation tiers
- Delivery lead, engagement head, founder
- Contract law options
- India, England and Wales, Singapore, New York
- Invoicing currencies
- USD, GBP, EUR, AED, INR
- Engagement lead
- Nitesh — nitesh@redcubical.com
- Delivery markets
- 10
- Committed daily overlap
- 4–8 hrs
- Client retention
- 96%
- Working days to first commit
- 10
Time zones
Committed daily overlap, by market
Overlap is measured against your local business day and written into the statement of work as clock times in both time zones. It is a staffing commitment, not an average of what happened last month.
How much overlap you get
We serve 10 markets and publish a committed overlap figure for each. The Gulf gets the most at eight hours because the time difference is only 90 minutes to two hours. North America gets the least at four and a half, held by running a 13:30 to 22:00 IST shift so the Eastern morning and the Pacific start of day are both live. The figure is contractual and staffed, not aspirational.
| Market | Committed overlap | Coverage pattern | Typical IST shift |
|---|---|---|---|
| United States | 4.5 hrs | ET/CT/PT morning overlap | 13:30 – 22:00 IST |
| United Kingdom | 7 hrs | Full UK working day | 11:30 – 20:00 IST |
| Germany | 6.5 hrs | CET business hours | 11:00 – 19:30 IST |
| Netherlands | 6.5 hrs | CET business hours | 11:00 – 19:30 IST |
| United Arab Emirates | 8 hrs | Near-identical day | 09:30 – 18:30 IST |
| Saudi Arabia | 8 hrs | Sun–Thu week supported | 09:30 – 18:30 IST, Sunday to Thursday |
| Singapore | 7 hrs | SGT afternoon overlap | 08:00 – 17:00 IST |
| Australia | 5 hrs | AEST morning overlap | 06:30 – 15:30 IST |
| Canada | 4.5 hrs | ET/PT morning overlap | 13:30 – 22:00 IST |
| India | Full day | Domestic delivery | 09:30 – 19:00 IST |
Shifts are indicative standard patterns and are adjusted per engagement. Two honest caveats. First, daylight saving in your market moves the window by an hour twice a year and we adjust the shift rather than letting the overlap shrink. Second, for a US west-coast team wanting a full Pacific afternoon we would need a night shift in India, which we will run with a disclosed allowance in the rate, but we will not pretend a standard shift covers it.
How we spend the overlap
Overlap is scarce, so it is scheduled deliberately rather than filled with meetings.
- First 30 minutes: stand-up and the question queue. Anything our engineers were blocked on overnight gets answered while you are awake.
- Middle block: protected focus time on both sides. No standing meetings. This is where most of the actual work happens and we defend it.
- Last 60 minutes: pairing, code review conversations, design discussions, and the handoff note that sets up the next Indian morning.
- Demos and planning scheduled at the start of the overlap, never at the end, so that a discussion running over does not push our engineers past their day.
- Nothing important scheduled in the last 30 minutes. A decision made at the edge of the window with a tired team is a decision that gets revisited.
What overlap cannot do
- It does not make synchronous working viable. Four and a half hours is enough for decisions and unblocking. It is not enough to run a team that depends on tapping someone on the shoulder.
- It does not survive a habit of unwritten requirements. If a decision only exists in a call, the nineteen hours outside the window will produce the wrong thing.
- It does not cover a night-time incident window on its own. Sub-two-hour response inside a US overnight period needs a paid on-call rota, which we will quote, or an onshore arrangement.
- It cannot fix an absent decision-maker. Eight hours of overlap with nobody available to answer is worth less than two hours with someone who is.
Governance
Named people, a RACI, and response times per channel
Every engagement has a named delivery lead in the contract. Not an account manager, not a coordinator: an engineer accountable for the increment landing.
How the engagement is governed
Governance has four parts. A named delivery lead accountable for delivery, named in the statement of work. A RACI agreed at kick-off so nobody discovers a gap in month three. A communication protocol with a response-time commitment per channel. And a meeting cadence that is deliberately thin, because meetings consume the overlap that unblocking needs.
| Activity | You | Delivery lead | Our engineers | Engagement head |
|---|---|---|---|---|
| Product priorities and backlog order | Accountable | Consulted | Informed | Informed |
| Requirement clarity and acceptance criteria | Accountable | Responsible | Consulted | Informed |
| Technical design and architecture decisions | Consulted, with veto | Accountable | Responsible | Informed |
| Estimation | Consulted | Accountable | Responsible | Informed |
| Sprint commitment | Consulted | Accountable | Responsible | Informed |
| Code quality and definition of done | Consulted | Accountable | Responsible | Informed |
| Release decision to production | Accountable | Responsible | Consulted | Informed |
| Environment and cloud account ownership | Accountable | Consulted | Responsible | Informed |
| Incident response during agreed hours | Informed | Accountable | Responsible | Informed |
| Team composition and roster changes | Consulted, with veto | Responsible | Informed | Accountable |
| Commercial changes and rate reviews | Accountable | Informed | Informed | Responsible |
| Escalated risk resolution | Consulted | Responsible | Informed | Accountable |
The two rows that prevent the most arguments are requirement clarity and the release decision. Requirement clarity is yours to be accountable for and ours to be responsible for driving, which means we will chase you for it in writing. The release decision is always yours, even when we are confident.
| Channel | Use it for | Response inside overlap | Response outside overlap |
|---|---|---|---|
| Shared chat channel (Slack or Teams, your workspace) | Day-to-day questions, blockers, quick decisions | Within 30 minutes from a named human | By the start of the next overlap window |
| Issue tracker comment (Jira or Linear, your instance) | Anything tied to a ticket. The durable record | Within 4 working hours | Next working day |
| Email to the delivery lead | Formal requests, sign-offs, anything needing an audit trail | Within 4 working hours | Next working day |
| Direct call or video to the delivery lead | Anything ambiguous enough that text is costing more than it saves | Immediately if free, otherwise a slot within 2 hours | Scheduled into the next window |
| Production incident path (on-call rota) | Live production impact only | Acknowledged within 15 minutes | Acknowledged within 30 minutes where a support agreement is in place |
| Escalation to engagement head | Delivery concern the lead has not resolved, or a commercial issue | Within 4 working hours | Within 1 business day |
| Escalation to founder | Anything unresolved after the first two tiers | Within 1 business day | Within 1 business day |
One rule underneath all of this: a response is a human answer or a committed time for one, never an acknowledgement bot. And any decision reached on a call is written into the ticket or the decision log by us within the same working day. If it is not written down, it did not happen.
| Meeting | Frequency | Duration | Who attends |
|---|---|---|---|
| Stand-up | Daily, start of overlap | 15 minutes | Team, delivery lead, your product owner optional |
| Backlog refinement | Weekly | 45 minutes | Delivery lead, two to three engineers, your product owner |
| Sprint planning | Fortnightly | 60 minutes | Full team, your product owner |
| Demo of working software | Fortnightly | 45 minutes | Full team, your product owner, your stakeholders |
| Retrospective | Fortnightly | 45 minutes | Full team, delivery lead. You are welcome and it is honest either way |
| Delivery review | Monthly | 60 minutes | Delivery lead, your engineering and product leads |
| Steering or commercial review | Quarterly | 90 minutes | Your sponsor, Nitesh, delivery lead |
Total standing commitment for your product owner is roughly three and a half hours a fortnight, plus availability for questions inside the window. We keep this deliberately thin. If a meeting on this list stops producing decisions, we propose cancelling it rather than protecting it.
Operating rhythm
What happens daily, weekly and monthly
The rhythm below is what an engagement feels like from your side. Times are given in IST and in a UK client window as an example; the same shape shifts to your market.
| What happens | When (IST) | When (UK) | Who attends | Output |
|---|---|---|---|---|
| Team starts, reads the overnight handoff note | 09:30 – 11:30 daily | 04:00 – 06:00 | Our team only | Work resumed on written context, no waiting for your day to start |
| Overlap opens. Stand-up | 11:30 – 11:45 daily | 06:00 – 06:15 | Team, delivery lead, your product owner optional | Blockers surfaced, question queue triaged |
| Question window and unblocking | 11:45 – 13:00 daily | 06:15 – 07:30 | Delivery lead, your product owner and engineers as needed | Decisions taken and written into tickets the same day |
| Protected focus time, both sides | 13:00 – 17:00 daily | 07:30 – 11:30 | Nobody. No standing meetings | The block where most code is written |
| Pairing, review and design conversations | 17:00 – 19:00 daily | 11:30 – 13:30 | Our engineers with yours, ad hoc | Reviews cleared, design questions closed inside the window |
| Handoff note written and posted | 19:00 – 19:30 daily | 13:30 – 14:00 | Each engineer, plus a team summary from the delivery lead | What moved, what is blocked, what needs your answer by tomorrow |
| Backlog refinement | Wednesday 12:00 – 12:45 | Wednesday 06:30 – 07:15 | Delivery lead, two to three engineers, your product owner | Next sprint candidates meeting the definition of ready |
| Weekly delivery report issued | Friday by 18:00 | Friday by 12:30 | Written and circulated, no meeting | Progress, burn, risks, decisions awaiting you, next week plan |
| Sprint demo and planning | Alternate Thursday 12:00 – 14:00 | Alternate Thursday 06:30 – 08:30 | Full team, your product owner and stakeholders | Working software demonstrated in your environment, next sprint committed |
| Retrospective | Alternate Thursday 17:00 – 17:45 | Alternate Thursday 11:30 – 12:15 | Full team, delivery lead | Two or three dated actions, carried into the next sprint |
| Recorded demo published | Within 24 hours of each demo | Same | Anyone who could not attend | A 10 to 15 minute recording, timestamped, kept in your workspace |
| Monthly delivery review | First Tuesday 13:00 – 14:00 | First Tuesday 07:30 – 08:30 | Delivery lead, your engineering and product leads | Trend view: velocity, defect escape rate, risks, team health, budget |
| Monthly report and invoice | By the third working day | Same | Written to your finance and engineering leads | Cumulative delivery, budget consumed against plan, roadmap position |
| Quarterly steering review | Scheduled, 90 minutes | Same | Your sponsor, Nitesh, delivery lead | Team shape, commercial position, roadmap horizon, escalated risks |
Two design choices in this table are worth naming. The handoff note is not a status report for management, it is a working document for the next person to pick the thread up. And the weekly report is written rather than presented, so it does not consume overlap that unblocking needs.
Escalation ladder with response times
Named people, published response times, and no requirement to go through a service desk. You get all three names and contact routes at kick-off.
-
Delivery lead — within 4 working hours
The first and usually the last stop. Sprint scope, quality concerns, an engineer not performing, a dependency slipping, a design disagreement. They own the plan and can change it. Reachable in the shared channel, by email and by direct call inside the overlap window. Around 90 percent of escalations end here.
-
Head of Global Engagement, Nitesh — within 1 business day
Escalate here when the delivery lead has not resolved something within an agreed timeframe, when the issue is commercial rather than technical, when you want a roster change, or when the relationship itself needs attention. They can change the team, change the commercial terms and change the delivery lead.
-
Founder and CEO, Ashish Uniyal — within 1 business day
For anything unresolved after L1 and L2, and for anything where you need a decision that binds the company: a credit, a contract variation, a commitment we have failed to meet. This is a real path, not a courtesy line, and we would rather you used it than quietly decided not to renew.
-
Production incident path — acknowledged within 15 minutes in hours
A separate, parallel path that does not queue behind delivery escalation. Inside agreed support hours, acknowledgement within 15 minutes and an incident commander named within 30. Outside them, acknowledgement within 30 minutes where you hold a support agreement with an on-call rota. Updates on a fixed clock thereafter, even when there is nothing new to report.
Working practice
Asynchronous first, holidays, and communication quality honestly addressed
Why async practice beats overlap hours
Overlap hours get the attention, but asynchronous discipline matters more. Nineteen hours of every day are not shared. What determines whether those hours are productive is whether decisions are written down, demos are recorded, and handoffs are documented. Teams with two hours of overlap and excellent written practice out-deliver teams with six hours and a verbal culture.
Asynchronous-first practices we operate
- Written decision records. Every material technical decision gets a short record: the context, the options, the choice, the trade-off accepted, and who decided. Written at the time, in your Confluence or Notion. Documentation written afterwards omits exactly the reasoning you need in month nine.
- Daily handoff notes. Each engineer posts what moved, what is blocked and what needs an answer before their next morning. The delivery lead posts a team summary. This is the mechanism that makes the non-overlap hours useful.
- Recorded demos. Every demo recorded, 10 to 15 minutes, timestamped, published within 24 hours into your workspace. Your stakeholders in other time zones watch it at their convenience. Attendance stops being a bottleneck on progress.
- Questions asked with a proposed answer. Our engineers are trained not to send "how should we handle X" but "we propose A because of B, we will proceed unless you object by your end of day". A question with a default answer costs you 30 seconds. An open question costs a day.
- Pull requests that explain themselves. A description covering what changed, why, what was considered and rejected, and how it was tested. Reviewable without a call.
- Documented handoffs at ownership change. When work moves between engineers, a written handover in the ticket rather than a conversation. This is also what makes attrition survivable.
- Meeting notes and actions within the same working day, written by us, posted where you can correct them.
- Default to the channel, not the direct message. Decisions in private messages are invisible to the next person and to you.
Public holidays in both countries
India observes around 12 to 14 holidays a year depending on state, against roughly 8 in England and Wales and 10 to 11 in the United States. Some Indian holidays cluster, most notably the Diwali period in October or November, which is also the point in the year when people take extended leave.
- Published in January. You get the full observed calendar for the year at the start of it, alongside your own, with the overlapping and non-overlapping dates marked.
- Sprint capacity reduced in the plan. A sprint containing two Indian holidays is planned at 80 percent capacity. We do not commit full capacity and then explain the shortfall afterwards.
- A 25 percent cap. No more than a quarter of any team is on optional or discretionary leave on the same working day, enforced through the leave approval process.
- Skeleton cover on every holiday. Nobody has to work, but on-call and a nominated responder are always rostered, including Diwali.
- The Diwali period is planned around. We will not schedule a go-live or a cutover into that window, and we will say so early rather than agree to a date we then negotiate.
- Saudi Arabia and the Gulf. Sunday to Thursday working weeks are supported with a rostered shift. Ramadan working hours in the region are accommodated in the schedule.
- Your holidays too. We plan around your Christmas shutdown, Thanksgiving, August in Germany and the Netherlands, and Eid where relevant. A sprint that needs your product owner in the week between Christmas and New Year is a planning failure on our side.
Language, accent and communication quality, without the marketing gloss
This is the question every prospective client wants to ask and most are too polite to. Here is the direct answer.
- Written English is strong. It is a hard gate in our vetting funnel and we reject technically capable engineers who fail it. This is deliberate: on overseas delivery, written communication carries more of the load than speech, and an engineer who cannot write a clear asynchronous update generates more cost than their code saves.
- Spoken English is clear but accented. On a first call you should expect to ask for a repeat occasionally, in both directions. Our engineers find some regional accents difficult too, particularly strong Scottish, Geordie, broad Australian and deep-South American accents. It fades within two to three weeks of regular contact and we treat it as a real onboarding cost rather than pretending it is not there.
- What we train for specifically. Saying "I do not know, I will find out by tomorrow" rather than guessing. Disagreeing with a client directly rather than deferring and then doing something else. Giving bad news early. Asking a clarifying question rather than making an assumption. These are the behaviours that decide whether an engagement works, and none of them is a language skill.
- Hierarchy and deference. A genuine cultural difference worth naming. Indian workplace norms lean towards deference to seniority, which in an offshore context can present as agreement where there is actually doubt. We coach against it explicitly, and our retrospectives are run so that disagreement is expected rather than tolerated. If you sense someone is agreeing rather than committing, say so directly. It works.
- Concrete adjustments that help. Video on for anything ambiguous. Confirm decisions in writing in the channel. Avoid idiom and sports metaphor in written specifications. Ask "what would you do differently" rather than "does that make sense", because the second question invites a yes.
- Where we will tell you it is not working. If an individual engineer's communication is genuinely holding your team back, we would rather replace them at our cost than defend the hire. Say it to the delivery lead and it is actioned, not debated.
Contracting, data and travel
Jurisdiction, data residency, currency and on-site presence
Contracting and jurisdiction
Our standard master services agreement is governed by Indian law with arbitration in Delhi, and we routinely accept English and Welsh law with arbitration in London or Singapore law under SIAC rules. Data residency is your choice across India, EU, UK, US, UAE, Singapore and Australia. We invoice in USD, GBP, EUR, AED or INR by SWIFT wire.
| Option | Governing law and forum | Typically chosen by | Practical note |
|---|---|---|---|
| Standard | Indian law, arbitration in Delhi under the Arbitration and Conciliation Act | Indian clients, and overseas clients with no strong procurement preference | Fastest to sign because there is no external counsel review on our side |
| England and Wales | English and Welsh law, arbitration in London under LCIA rules, or the courts of England and Wales | UK, and often Gulf clients who want a familiar common-law forum | Accepted routinely. Adds roughly one to two weeks for our counsel review |
| Singapore | Singapore law, arbitration under SIAC rules | Singapore, Australia, and Gulf clients wanting a neutral seat | The most common neutral choice. Enforcement against an Indian entity is straightforward under the New York Convention |
| New York or Delaware | New York or Delaware law, arbitration under AAA or ICDR rules | US clients with a mandated standard form | Negotiable on engagements above roughly USD 250,000. We push back on jury trial and unlimited indemnity |
| Client standard form | Whatever your procurement mandates | Enterprise clients with a supplier framework | We will work to your paper. Expect us to negotiate liability caps, IP carve-outs for our pre-existing libraries, and any obligation implying an entity or presence we do not have |
Two positions we hold consistently. Liability is capped at a multiple of fees paid, typically one to two times the trailing twelve months, with the usual carve-outs for confidentiality breach, IP infringement and wilful misconduct. And we will not sign an unlimited indemnity, in any jurisdiction, at any contract value. A supplier who does either has not read it or cannot honour it.
| Item | How it works |
|---|---|
| Currencies | USD, GBP, EUR, AED, INR. Quoted and invoiced in the same currency for the contract term |
| Payment route | International wire over SWIFT. NEFT, RTGS or UPI for INR |
| Bank charges | You pay sending charges, we absorb receiving charges. Intermediary deductions reconciled quarterly |
| Terms | 15 days standard, 30 days on request |
| Cadence | Monthly in advance for team-based work, monthly in arrears for time and materials, milestone-based for fixed scope |
| FX exposure | Ours, not yours. Rupee movement does not change your invoice |
| Tax | Export of services from India is generally zero-rated for GST to overseas clients. Withholding treatment depends on your jurisdiction and any double taxation treaty. Take your own tax advice |
| PO handling | We reference your purchase order on every invoice line where your process requires it |
Travel and on-site presence
- Included in the fee: a three to five day discovery or kick-off visit on engagements above USD 150,000, and a visit at a major go-live. We think being in the room at the start pays for itself and we do not want it to be a line item you decline.
- At cost thereafter: flights in economy on flights under six hours and premium economy above, accommodation, local transport and a per-diem. No mark-up, no agency fee, and we do not bill travel time as billable hours.
- Typical rhythm on a long engagement: a delivery lead visit once or twice a year, three to five days each, with a specific agenda. Visits without an agenda are tourism and we will not propose them.
- Your visits to us: always welcome and we do not charge for hosting. Clients who visit Dehradun almost always come away with a better calibrated view of the team, and a client audit visit is a contractual right on 14 days notice.
- Visa reality. Indian passport holders need visas for the UK, the Schengen area, the US, Canada and Australia. Lead times run three to eight weeks and occasionally longer. UAE, Saudi Arabia and Singapore are faster. This is a real planning constraint: if you need someone on site in ten days, that is usually not achievable and we will say so rather than promise it.
- Extended on-site placements of one to three months are possible for a critical phase, priced at a premium reflecting cost of living plus the visa work. We would usually argue for a shorter visit plus better async practice instead.
First 30 days
Onboarding a new client
Five stages across thirty days. First commit inside ten working days, first demo in week three, and a formal review at day thirty where you tell us what to change.
-
Days 1 to 5 — paperwork, access and people
Master services agreement and work order executed. Individual NDAs and IP assignments signed by every named engineer. Your supplier onboarding and security questionnaire completed. Accounts provisioned in your identity provider, repository, tracker and chat. Delivery lead named, escalation contacts exchanged in both directions, overlap window fixed as clock times and put in both calendars.
-
Days 3 to 10 — environment, codebase and first commit
Local environments running with the test suite green. A guided walkthrough of the domain and the deployment path with your engineers. Your definition of done adopted or drafted. A deliberately small first ticket chosen to exercise the build, the tests and the release process end to end. First commit merged by day 10.
-
Days 8 to 15 — cadence, RACI and reporting established
Ceremony calendar agreed inside the overlap window. RACI signed off so nobody discovers a gap in month three. Reporting artefacts agreed: what you receive weekly, fortnightly and monthly, in what format, to whom. The decision log and handoff-note conventions set up in your workspace. First weekly report issued.
-
Days 15 to 22 — first increment and first demo
A demoable increment in your environment, not on our machines. Demo run live inside the overlap window and recorded within 24 hours for anyone who could not attend. First retrospective run, and it is honest even when the honest answer is that our onboarding missed something.
-
Days 22 to 30 — the 30-day review
A structured review that we run and you grade: velocity against expectation, code review quality, communication quality per engineer, whether the seniority mix was right, and whether the overlap window is landing where you need it. Anything not working gets changed, including people, at our cost. We ask directly rather than waiting for you to raise it.
- What we need from you in week one: a named product owner, access provisioning, and 90 minutes for the domain walkthrough
- What we need by week two: a backlog with at least one sprint of work meeting the definition of ready
- What we need by week three: a stakeholder list for the demo and a decision on who signs off releases
- What you get in week one: named delivery lead, escalation contacts, overlap window as clock times, signed RACI draft
- What you get by week two: first merged pull request, first weekly report, decision log live in your workspace
- What you get by week four: a demoed increment, a recorded demo, a retrospective output and a 30-day review document
The uncomfortable part
The real failure modes of offshore delivery, and where offshore is the wrong answer
Why offshore engagements fail
Offshore delivery fails for six recurring, structural reasons: insufficient overlap, verbal-only decisions, silent team rotation, no named accountability, status reports substituting for working software, and an absent decision-maker on the client side. Five of the six are preventable by contract design. The sixth is not ours to fix and no supplier can fix it for you.
| Failure mode | What it looks like in month three | How it is structurally prevented | Residual risk |
|---|---|---|---|
| Insufficient overlap | Every question costs a day. A three-message exchange takes a working week | A contractual overlap window per market, staffed by shift, written as clock times in both time zones and adjusted for daylight saving | A US west-coast afternoon needs a night shift we must price. We will not pretend a day shift covers it |
| Verbal-only decisions | Two versions of the requirement exist. Rework is blamed on "miscommunication" | Written decision records at the time of the decision, meeting notes the same working day, and any call outcome written into the ticket by us | Requires your side to correct the written record when it is wrong. We post it where you can |
| Silent team rotation | The engineer who knew the domain has gone and nobody told you | Named roster in the contract, 90-day no-swap commitment, 30 days notice with a named successor and an overlap plan thereafter | Resignation cannot be prevented. Sub-9 percent attrition and documented context reduce the cost, not the event |
| No named accountability | You escalate to an account manager who relays messages and owns no decisions | A named delivery lead in the statement of work with authority over the plan, plus a published three-tier ladder with response times to founder level | None structurally. If a delivery lead is not working, tell L2 and they are changed |
| Status reports instead of software | Percentage-complete charts rise steadily and nothing is deployable | A deployable increment every two weeks in your environment, demoed live and recorded. Fortnightly, not at milestones | Requires you to attend or watch the demo. A demo nobody watches is a status report with extra steps |
| Absent decision-maker on your side | Engineers guess, build the wrong thing, and the rework is invoiced | Not preventable by us. Mitigated by proposing a default answer with every question, a documented decision SLA, and escalation when it is breached | This is the one that actually sinks engagements, and it sits entirely on the client side of the line |
We would rather publish this table than a page of assurances. Five of these six are contract design problems and we have designed against them. The sixth is a client-side commitment, and the strongest predictor we have of an engagement going badly is not overlap hours, seniority mix or tooling. It is whether someone empowered on your side spends a few hours a week inside the window.
Where offshore is genuinely the wrong answer
Four cases. In each of them we would decline the work or scope it down at the first call, because taking it would waste your money and damage our reputation.
- Work requiring constant physical presence. Plant-floor commissioning, hardware bring-up, on-site installation, lab work, or anything where an engineer needs to touch the equipment daily. We can build the software and integrate remotely, but if the job needs someone in the building every day, hire someone in the building. We will happily work alongside an onshore team who does that part.
- Security-cleared work. We do not hold security clearances in any jurisdiction and we do not employ cleared personnel. UK government work at SC or above, US work requiring a clearance or ITAR-controlled material, Australian government work requiring an NV1: we cannot do it and no contractual structure changes that. We will say so immediately rather than proposing a workaround.
- Sub-two-hour incident response inside a US-only night window. If your critical window is 22:00 to 06:00 Eastern with a two-hour response commitment and no daytime component, that is 08:30 to 16:30 IST — technically our working day, but it requires a dedicated rota, not the delivery team on call. We will quote it as a paid follow-the-sun support arrangement with named engineers and a real rota, or we will tell you an onshore or nearshore arrangement is better value. What we will not do is imply the delivery team covers it as goodwill.
- Data a regulator prohibits from offshore access. Not "makes complicated" but prohibits. Some Saudi and UAE financial sector rules, some Canadian and Australian public-sector requirements, and certain payment data under RBI rules fall here. Where access is prohibited outright, an India-based team cannot do the work. We will tell you at the first call.
Cases where offshore works but costs more than you expect
- Very early-stage product discovery with a founder who thinks by talking. The overlap window is not the constraint; the mode of working is. This gets better once there is something written down, so a short onshore or workshop-based discovery followed by offshore build is usually the right sequence.
- Heavy stakeholder-facing business analysis across many internal departments in your organisation. Someone in your building does that better. We are happy to consume the output.
- Very small pieces of work. Under about six weeks of effort, the onboarding and context-acquisition cost is a large fraction of the total. A local contractor may genuinely be better value and we will say so.
- Work with an immovable date four weeks out. Ten working days of that is onboarding. The arithmetic rarely works and agreeing to it would be a disservice.
Answers
Overseas delivery questions
How much daily overlap do we actually get?
It depends on your market and it is contractual. United Arab Emirates and Saudi Arabia get eight hours, the United Kingdom and Singapore seven, Germany and the Netherlands six and a half, Australia five, and the United States and Canada four and a half. The window is written into the statement of work as clock times in both time zones.
What happens when we raise something urgent?
Inside the overlap window, a message in the shared channel gets a human response within 30 minutes and a production incident gets an acknowledgement within 15. Outside it, a production P1 raised through the on-call path is acknowledged within 30 minutes where you hold a support agreement, and by the next overlap window otherwise.
How do Indian public holidays affect our delivery?
India has around 12 to 14 observed holidays a year and a handful are clustered, notably Diwali. We publish the calendar at the start of each year, cap holiday absence at 25 percent of any team on any single day, and maintain skeleton on-call cover on every holiday. Sprint capacity is reduced in the plan rather than absorbed silently.
Will there be a language or communication barrier?
Written English is strong across the board because we gate on it in hiring and reject technically capable engineers who fail that stage. Spoken English is clear but accented, and on a first call you should expect to ask for a repeat occasionally. That fades within two or three weeks. We treat it as a real onboarding cost rather than pretending it does not exist.
Which jurisdiction governs the contract?
Our standard master services agreement is governed by Indian law with arbitration in Delhi. We routinely accept English and Welsh law with arbitration in London, and Singapore law under SIAC rules, which is the neutral option most Gulf and Asia-Pacific clients prefer. New York law is negotiable on larger engagements.
Do you ever come to our office?
Yes. Discovery and kick-off visits of three to five days are included in the fee on engagements above USD 150,000. Beyond that, on-site presence is at cost: flights, accommodation and a per-diem, with no mark-up and no billing of travel time. Visa lead time for Indian passport holders is the practical constraint, typically three to eight weeks.
What does onboarding a new client look like?
Thirty days in five stages: paperwork and access in week one, environment and codebase orientation in week two, first increment shipped in week three, governance and reporting established in week four, and a formal 30-day review where you tell us what to change. First commit lands inside the first ten working days.
When is offshore delivery the wrong answer?
Work needing constant physical presence, work requiring security clearance in your jurisdiction, sub-two-hour incident response inside a US-only overnight window without a paid follow-the-sun rota, and anything where a regulator prohibits offshore access to the data outright. We will tell you at the first call rather than after the contract.
Ask us the awkward questions first
Overlap, escalation, attrition, data residency, what happens when it goes wrong. You get a call with the engagement lead and the architect who would run the work, and written answers to anything we cannot answer on the call, within one business day.