Software built for San Francisco companies, from India.
We design, build and ship software for companies in San Francisco. Every developer who does it sits in Vadodara, India, and nobody here is at a desk while San Francisco is.
- When we are actually at our desks
Monday to Friday, 10:00 to 19:00 IST, which is 04:30 to 13:30 UTCThe conversion never drifts, because India observes no daylight saving.
- What that is on the Pacific coast
20:30 the previous evening to 05:30 under PST in winter, and 21:30 to 06:30 under PDT in summerBoth ends of a Pacific day move together by the same hour, so the arithmetic below holds in either season.
- Who is in San Francisco
NobodyEvery developer who does the work sits in Vadodara, India. Nobody here is at a desk while San Francisco is.
A weekday in 24 hours: our published 10:00 to 19:00 IST window against an assumed 09:00 to 17:00 San Francisco office day
The arithmetic that decides this is worth doing in the open. Set our window against an ordinary San Francisco office day of 09:00 to 17:00 and the two never touch. Zero, in winter and in summer alike. Our clock never moves, and the Pacific shift moves both ends of yours together by the same hour.
Show data table
| Segment | Value (hours) | Share |
|---|---|---|
| Both working | 0 | 0% |
| Only Atyantik working | 9 | 37.5% |
| Only San Francisco working | 8 | 33.3% |
| Neither working | 7 | 29.2% |
It stays at zero until somebody in San Francisco starts work before six in the morning.
What the zero actually costs, in the terms that matter
The problem is arithmetic, and its unit is the round trip.
The unit is a round trip
A question asked at four in the afternoon is answered while you sleep and read the next morning. One exchange costs a night. Four exchanges cost four nights. A review that would take an hour side by side is routinely four exchanges.
Four steps, four days
A change is requested, made, re-read and approved. Side by side those fit inside an afternoon. Across a full-day gap each takes a night of its own. Work that was going to be finished on Monday is finished on Thursday.
A date already said out loud
Somewhere behind the schedule is a date given to a board or a customer. It assumed people would land in time. They did not. When it moves, the lost week is the smaller problem. The larger one is having been wrong in public, in front of people who will remember.
Count the round trips a piece of work needs before anyone commits to a date. That number is the one to measure a partner on. Everything below is about how we keep it small.
Nine hours with nothing interrupting them
The gap that makes a meeting impossible is the same gap that hands a piece of work an uninterrupted night. Whatever leaves your desk at the end of a San Francisco afternoon gets our entire working day. It moves before your next morning starts.
- You hand over
You leave the open questions in writing before you close the laptop. Nothing waits on finding a time to talk.
- Our day starts
20:30 PST in winter and 21:30 PDT in summer.
- Nine hours
One team works the surface end to end, with no interruptions and no context switch.
- It is on your desk
Our day ends at 05:30 PST in winter and 06:30 PDT in summer.
What gets written down instead of said
The architecture decision
Recorded beside the code, in the repository. Kept in source control it stays in sync with the code itself. Ours live in the technical requirement specification.
The review
Done in writing, on the change itself, by a senior software engineer. Google Cloud's DORA programme reported this in its 2019 State of DevOps Report. Change approvals work best as peer review during development, supplemented by automation. DORA found no evidence that a more formal external review process was associated with lower change fail rates. That is a null result, and we report it as one.
What arrives at each stage
01
Scoping
Coordination runs asynchronously by default, and that is settled here before anything starts.
You get
An overlap commitment exists for engagements that genuinely need one. It is agreed at this stage rather than assumed later.
02
Documentation
Every project starts with documentation.
You get
Architecture decisions are recorded in the technical requirement specification, readable before anyone needs them.
03
Build
Every change goes through code review by a senior software engineer.
You get
The assigned team holds its own daily standup, inside our hours.
04
Every two weeks
A sprint review.
You get
A demo of working software you can open and use yourself.
05
When risk appears
You hear about it in the week the risk emerges.
You get
In writing, not the week before delivery.
The decision that sets what the zero costs
Zero overlap is expensive in elapsed time when work is interleaved through somebody else's sprint at ticket granularity. It costs almost nothing in elapsed time when one team owns a whole surface from scoping to production. That gets decided at scoping, before anything starts.
One team owns a surface
Choose this when
We take a whole area end to end. The decisions inside it are ours to make and to write down.
It costs you
The number of round trips is small by construction.
Interleaved with your team
Choose this when
Our people work tickets inside your sprint, alongside yours. That is sometimes the right answer.
It costs you
It is also the case where round trips multiply and the clock charges you most for them.
Start a conversation about the surface
Tell us the surface you want owned and the date it is against. We respond within one business day.
Writing things down is the kind of claim every partner makes about itself.
Here is somebody else's measurement of it. Teams whose internal documentation scores above the sample average see a far larger lift. That holds for every one of the four practices DORA measured. Documentation quality is the thing an asynchronous arrangement has to be good at. It is what we are built around.
| Technical practice | Teams with above-average internal documentation | Teams with below-average internal documentation |
|---|---|---|
| Trunk-based development | Teams with above-average internal documentation1,525% | Teams with below-average internal documentation36% |
| Continuous integration | Teams with above-average internal documentation750% | Teams with below-average internal documentation34% |
| Continuous delivery | Teams with above-average internal documentation656% | Teams with below-average internal documentation63% |
| Loosely coupled teams | Teams with above-average internal documentation313% | Teams with below-average internal documentation46% |
Herbsleb and Mockus, IEEE Transactions on Software Engineering, June 2003: self-reported typical wait for information, about 92 respondents at Lucent Technologies, 1997 to 1999
The honest answer is that this is slower, and that there is a class of work it makes harder.
Show data table
| Item | Value |
|---|---|
| Waiting on someone at your own site | 0.9 days |
| Waiting on someone at another site | 2.4 days |
What we have actually done
None of the argument above is a theory we are trying out for the first time.
Atyantik delivery record
Atyantik delivery record
Atyantik delivery record
Atyantik delivery record
*Disclaimer: All of them run from India. Measured from intake to first production deploy once scoping is locked, which is an initial milestone rather than a feature-complete product.
What you hold the whole time
You worry the code is ours until the invoice clears.
What we commit to
From day one every line of code is your IP, and it lives in your repositories, under your account.
You need to leave.
What we commit to
The handoff runs as a planned process with a schedule and a named owner. There is no artifact of ours to buy back.
You send a question into the dark and hear nothing.
What we commit to
We respond within one business day.
You want to hear it from somebody who writes code.
What we commit to
On request, a technical person joins within one business day to answer architecture and stack questions directly. The bound is real: it happens when you ask for it.
You worry the scope quietly grows.
What we commit to
A change request becomes a written change note, and nothing in the build moves on a re-scope you have not explicitly accepted.
Three shapes this work takes
What moves a project between them is how much of a surface we own end to end. Place yourself before you write, and the first conversation starts a stage further along.
| A defined build | A continuing arrangement | A team you direct | |
|---|---|---|---|
| What we own | A defined buildA whole surface, end to end, from scoping to production. | A continuing arrangementThe same surface, still ours, after it is live. | A team you directYour backlog runs the work, our people do it. |
| Who directs the work | A defined buildWe do, against an agreed scope. | A continuing arrangementWe do. | A team you directYou do. |
| Where it fits | A defined buildSomething that does not exist yet and needs building. | A continuing arrangementSomething live that needs to keep moving. | A team you directYou have the direction and need the hands. |
When this is the wrong arrangement
Before you decide against it
Where an engagement genuinely needs live overlap, a project coordinator can host a sync.
An overlap shift can be arranged on request.
That is a specific arrangement for a specific need, and it stops well short of cover around the clock.
Where we are the wrong call
Your direction changes hour to hour. Exploratory work whose shape moves through the day holds on to live contact hardest. If somebody needs to be at your elbow while it changes, an overnight cycle will frustrate both of us. That is our own read on the class of work.
Your busiest hours are a US afternoon. Our day has ended by then in either season. If the work that matters most happens while we are asleep, this barely touches it.
The work has to sit inside your sprint, ticket by ticket. That is where round trips multiply and where the clock genuinely costs you days. It is sometimes the right answer, and it is the arrangement we are least suited to.
Questions worth answering before you write
How do you work with a company in San Francisco when there is no overlap in working hours?
Can I talk to the software engineer who will write the code, before we sign?
Who reviews the code, and against what standard?
Who owns the code and the cloud accounts?
What happens overnight, and how fast do you reply?
How long before something is running?
When is this the wrong arrangement?
Tell us what needs building
Two sentences is enough to start: what needs building, and the date it is against. We respond within one business day. On request, a technical person joins within one business day to answer architecture and stack questions directly.
There are two good endings to that conversation. Either the surface can be owned end to end, and we say what scoping it would take. Or it cannot, and we say that instead. You get a straight answer either way.
- Everything you send stays between us.
- A technical person on the first call, on request.
- A straight answer either way.