What a partner costs you to coordinate, and who answers when it breaks
Your organisation already builds software. Two questions decide this one. One is whether another team costs you more of your own senior people's attention than it buys you in throughput.
Tell us the shape you are considering and the constraint you are working inside
On request, a technical person joins within one business day to answer architecture and stack questions directly.
The other is who picks up at two in the morning. Our answer starts in one line. A core team assigned only to your project, with a lead software engineer you talk to directly. No rotation, and no handoffs you did not agree to.
Most of what a partner costs you never reaches the invoice
It shows up as hours your own senior software engineers spend. Explaining a decision twice. Re-reviewing work that missed a standard nobody wrote down. Answering questions that route to them because there is nowhere else for those questions to go.
That cost has been measured. James Herbsleb and Audris Mockus published it in IEEE Transactions on Software Engineering in 2003. Their data was 2,227 modification requests at Lucent between 1997 and 1999. Work split across sites took about 2.5 times as long, 12.7 calendar days against 5. A second department replicated the gap across 4,974 items, 18 days against 7.
The same paper then takes its own headline apart. Its regression states it plainly: "Surprisingly, given all other factors, distributed MRs do not have significantly longer intervals than single-site MRs". Once the number of people pulled into each item and the size of the change are controlled for, distance stops explaining the delay. What was left was how many people had to be involved to move one thing forward.
So the variable is coordination load. That is something you can specify before you sign, and ours is specified. You get a lead software engineer you talk to directly, and no ticket wall in between. When something is ambiguous, one named person on our side owns resolving it. That person is not one of yours.
QSM comparison of 1,060 IT projects: the same amount of work, different team sizes
Before this gets sized in headcount, look at how projects of the same size compare when different team sizes deliver them.
Show data table
| Item | smaller teams, indexed at 100 |
|---|---|
| Schedule | 94 |
| Effort | 400 |
| Defect density | 300 |
Six percent of a schedule is small. Four times the effort and three times the defect density are not. On work that is already scoped, a larger team is an expensive way to buy a little time. That moves the decision from size to structure, and there are four structures.
These are not tiers of the same thing. A different condition selects each one, and each costs your own team a different amount of attention.
Four shapes, and one of them is not us
Software engineers embedded in your team
Choose this when
You own the roadmap, the review standard and the on-call rota. You need more hands working inside them.
It costs you
This costs you the most coordination, because your leads assign and accept the work. Every change goes through code review by a senior software engineer on our side first. What lands in your queue has already cleared one review.
A core team owning a workstream end to end
Choose this when
There is a piece of the product you can hand over whole. Describe it as an outcome rather than a backlog.
It costs you
This costs you the least coordination. The team is assigned only to your project, with a lead software engineer you talk to directly. No rotation, and no handoffs you did not agree to.
A full-team buildout
Choose this when
Something new has to exist and there is nobody internally to spare for it.
It costs you
It is the largest shape by some distance. For full-team buildouts we pair developers with at least one DevOps and one QA engineer. That carries more people than an embedded software engineer, and it is planned that way from the start.
Where the boundary sits, area by area
Every place two teams normally collide, with the decision rights named and the artifact that records them.
| Area | Who decides | What exists in writing |
|---|---|---|
| Architecture | Who decidesYou decide, argued out with our lead first. | What exists in writingA TRS documents the architecture decisions and the reasoning behind them. |
| Code quality | Who decidesYour standard governs. | What exists in writingEvery change goes through code review by a senior software engineer. Work runs on GitFlow, with unit and integration tests and CI/CD gates on every merge. |
| Scope changes | Who decidesYou decide. | What exists in writingNothing in the build moves on a re-scope you have not explicitly accepted. Every change carries a documented change note, with time, effort and cost laid out before approval. That applies during the build and post-launch on AMC or lean-mode arrangements. |
| Code, repositories and cloud accounts | Who decidesYours from Day 1, when every line of code becomes your IP. | What exists in writingIf you have your own Git hosting, cloud accounts and storage, we work inside them. If you do not, we provision them, set them up and hand the keys over. |
| Availability of what we run | Who decidesOurs, inside a stated scope. | What exists in writingPipelines that target 98-99 percent uptime under normal operating conditions. Cloud-provider outages sit outside that scope. Everything within it is our responsibility. |
| Running it after handover | Who decidesYours. | What exists in writingWe hand over a written runbook. The same software engineers stay on it across years, so the people who wrote it are still reachable. |
What happens when something breaks
The escalation path in order, with the hours it runs in and what it does not cover.
- It reaches a person, not a queue.
No ticket walls. Your team raises it with the lead software engineer on the account, by whichever channel you already use.
- Inside our working day, which runs 10:00 to 19:00 IST, or 04:30 to 13:30 UTC.
Those two are fixed and never shift with a clock change. You can convert them against your own hours.
- Outside those hours, by default, our day has ended.
We do not run a standing overnight rota and we will not tell you we do. Where you need live cover or a session inside your own window, say so. A project coordinator can host it, or an overlap shift can be arranged on request. Say so early and it gets built into the arrangement.
- When it is serious, it reaches the top quickly.
Our co-founders Tirth Bodawala and Ajay Patel still take production calls. That has not been delegated as we have grown.
- After handover, your own on-call acts without waiting for us.
The written runbook is the point. The same software engineers stay across years, so the person who built it is still there when you call.
DORA 2022: how success on each practice tracks with documentation quality
Documentation is usually the first thing to slip when a team is busy. DORA measured what teams with quality documentation report, across four practices at once.
Show data table
| Dimension | Teams reporting quality documentation | Teams reporting poor documentation |
|---|---|---|
| Trunk-based development | 1,525% | 36% |
| Continuous integration | 750% | 34% |
| Continuous delivery | 656% | 63% |
| Loosely coupled teams | 313% | 46% |
The gap holds across all four, which is a stronger signal than the same gap on one. DORA reports it as an association rather than a cause. Our answer is a TRS documenting architecture decisions. It is written while the work happens rather than assembled at the end. Ask the same question of your own team, not only of us.
What to ask to see before you sign anything
None of this needs our permission to ask for, and all of it exists on a real engagement.
- A redacted TRS from a comparable engagement, showing the architecture decisions and the reasoning. It exists from the first sprint.
- The GitFlow branching model and the CI/CD gates that would run on your merges. Both are defined before the first commit.
- The test layers, unit and integration, and what each gate blocks when it fails.
- The change note format: time, effort and cost laid out before approval. You can see what an approval will look like.
- The written runbook we hand over, and the exit artifact list: architecture, deployment, CI/CD pipelines, BRD, SRS, change notes.
- References from engagements that have run for years, available when you are ready to verify.
Tell us the shape you are considering and the constraint you are working inside
On request, a technical person joins within one business day to answer architecture and stack questions directly.
Ask us for these in the first conversation, and ask whoever else is bidding for theirs in the same form.
Terms are easy to write and hard to keep. Two things below are worth keeping apart. The first is firm-wide: 50-plus engagements across 7 countries. The longest engagement still running is past ten years, with the same software engineers on it. Our co-founders still take production calls on that work. There is an offboarding process in writing, and so far no client has needed to use it. The second is one named client, speaking about their own engagement and nothing else. The ten-year figure is firm-wide and is not theirs. When you are ready to verify, we will put you in touch with people who have lived it.
We stopped distinguishing between their engineers and ours.
That is the outcome worth aiming at. The seam stops being something anyone manages, because there is nothing left at it to manage.
The four ways this normally goes wrong
Their work arrives in our review queue below our standard, and our seniors become a filter.
What we commit to
Every change goes through code review by a senior software engineer here. CI/CD gates run on every merge, before it reaches your queue at all.
The people we met get moved onto another account three months in.
What we commit to
A core team assigned only to your project. No rotation, no context-switching, and no handoffs you did not agree to.
We inherit decisions nobody signed off, and we are still living with them in three years.
What we commit to
Nothing in the build moves on a re-scope you have not explicitly accepted. Every change carries a documented change note, with time, effort and cost laid out before approval.
We want out, and leaving costs more than staying.
What we commit to
The handoff is a process, not a hostage situation. Architecture, deployment, CI/CD pipelines, BRD, SRS and change notes are handed over, and the accounts were yours the whole time.
When this is the wrong call
Where we fit
There is already a review standard on your side, and the requirement is that partner work is held to it.
The code and the accounts have to be yours from day one. That holds whether you already run your own cloud accounts or need them provisioned and handed over.
You want the boundary written down before anyone signs, including the places where the answer is no.
Where we are the wrong call
The primary responder at two in the morning your time has to be the partner. Our day runs 10:00 to 19:00 IST, 04:30 to 13:30 UTC. A project coordinator can host a session in your window, or an overlap shift can be arranged on request. Plenty of arrangements work that way. If the first page at 02:00 must land on us by default, buy that capability where it lives.
how a maintenance and support engagement is staffed and escalated
You want people swapped in and out without being asked each time. Nobody moves off your team without your agreement. Capacity itself is not the limit. If the scope needs more people in either area, we staff for it as part of engagement planning. If a shortlist does not produce the right fit, we send another. The one thing that does not happen is a change of people you did not agree to.
You want to change direction weekly without writing anything down. Every change carries a documented change note with time, effort and cost laid out before approval. That is slower than a verbal yes, on purpose.
If those three describe your situation, start the conversation.
Start the conversationOperational questions, answered
What hours does the team work, and what happens outside them?
Who reviews the code, and against what standard?
Who owns the code and the cloud accounts?
How do scope changes work once we have started?
What availability do you commit to on systems you run?
Are DevOps and QA included, or do we add those ourselves?
What happens if we want to stop?
Can we talk to someone technical before committing to anything?
Tell us the shape and the constraint
Send the shape you are considering and the constraint you are working inside. Whatever cannot move: a delivery date, the standard your work has to clear, or a system you cannot take offline. On request, a technical person joins within one business day to answer architecture and stack questions directly. No ticket walls, and no account manager carrying messages between you and the people who would do the work.
Two outcomes here are both good. One is a scoped conversation and a structure you can defend to your own board. The other is a clear no after one exchange, with the reason written down. Finding that out now costs an email, and finding it out in month three costs a quarter.
- Our co-founders Tirth Bodawala and Ajay Patel still take production calls, so the person who answers is the person accountable.