Delhi (DL), India
AI development for Delhi teams, handed over in writing
We build AI products from Vancouver, British Columbia, and we work with Delhi teams without a single shared working hour. No office there, no staff there. What replaces the shared day is a written handoff, decisions logged as they are made, and review that happens on your morning rather than in a call.
- base
- vancouver, bc, canada (UTC-08:00)
- market
- Delhi, India
- your clock
- UTC+05:30 (Asia/Kolkata)
- overlap
- none on the same date, written handoff instead
- presence
- remote only, no office in Delhi
No shared working day, so the loop is written
Delhi is 13.5 hours ahead of Vancouver. When we start at 09:00 it is 22:30 on the same day for you, and when we stop at 17:00 it is 06:30 on the next day. On the same calendar date there is no hour where both sides are at work.
There is a real cost and it is worth naming: an answer to a blocking question can take a working day to reach you. We handle it by sending the proposed answer with the question, so silence means agreement rather than a lost day.
- Everything built during our day lands in one written note before we close the laptop. No status meeting stands in for it.
- Your morning starts with that note and a set of pull requests to review, which is a better start than a calendar invitation.
- Every decision worth arguing about is written down where the code is, with the reasoning and the date attached.
- Questions come with a recommendation, because a question that needs a reply before work continues costs a full day here.
One live call a week, and it is scheduled honestly: 19:30 in Vancouver is 09:00 in Delhi on the next day. That hour is outside our working day and inside yours. We take the awkward end of it, because it is our job to be reachable.
What Delhi buyers usually bring us
The record for Delhi lists two industries. Here is the part of each one that turns into an engagement, and the service line it lands under.
public administration
Legislation, guidance and internal procedure answer most questions, provided retrieval quotes the passage and shows which version it came from.
Chunking follows the structure of the document instead of a character count, which is the whole difference between a useful index and an expensive one.
Closest service line: Knowledge bases and retrieval
business services
The people doing the work know where the time goes. Teaching them to drive the tools on their own files beats a platform rollout nobody asked for.
The measure is what the team does two months later, not the feedback form at the end of the afternoon.
Closest service line: Training and enablement
Contracts, currency and where the data sits
Invoices are in US dollars. Contracting with a Canadian vendor is common enough that your finance team will have the paperwork pattern already.
Beyond that, the shape of an engagement does not change with distance: a scoping call, a thin end-to-end slice, then weekly increments against acceptance criteria fixed in advance. If we are not the right shop for Delhi work, you get told that in the first reply rather than after a proposal.
The five lines we sell
Same five lines everywhere, Delhi included. Most engagements are one of them, sometimes two.
- AI products, built end to end
- Knowledge bases and retrieval
- Codebase and team optimization
- Training and enablement
- Forward-deployed engineering
The languages, models and infrastructure underneath all five are listed on the Magic Ship stack page, with what each one is good for and where it is the wrong choice.
Other markets in India
More of India, all of it worked remotely from Vancouver.
Start a project
Send the problem. If it is a fit, you get scope and a timeline. If it is not, you get told that in the first reply instead of after a discovery process.