When a client's own developers work in the same codebase as ours, the project succeeds or fails on agreements made in the first week: whose conventions apply, who reviews whose work, who owns each environment, and how a disagreement gets settled. Skip those and you get two polite teams quietly breaking each other's work and blaming the other one in private.
Whose rules apply?
The client's, if they have any. It is their codebase and they will live in it long after the vendor leaves, so we adopt their branch strategy, their linting, their pull request template and their release process. Where they have no rules, we propose ours and write them down as shared rules.
Setting that up takes about a day:
- Sixty minutes walking through their PR process, led by whoever actually merges.
- A list of who can merge to the main branch. It is usually shorter than anyone thought, and usually one person who is also the busiest on their team.
- A written note of which conventions we are adopting, sent to both teams the same afternoon.
- Agreement on review turnaround, in hours, before the first pull request is opened.
From the day that note goes out they are the shared rules rather than the vendor's rules, which is a small wording difference that changes how people argue about them later.
Who reviews whose work?
Both directions, always, with an agreed turnaround, and twenty-four working hours is the number I usually push for. The common failure is lopsided review, where the client's team reviews everything the vendor ships and nobody reviews what the client's team ships, usually out of politeness.
That politeness is expensive. It means half the codebase is unreviewed and the other half is slow. Reviews across the fence also do something no document can: they transfer knowledge in both directions, every day, without a handover meeting.
What about AI-generated code from either side?
It gets the same rule as everything else, agreed in week one. Both teams are using coding assistants and both are shipping faster, so review capacity becomes the constraint. Every change gets a human reader who did not write it, whatever produced the first draft.
If neither side's review process has caught up with that speed, you end up sharing a growing pile of code nobody has read closely, and the invoice for that arrives as the security bill for vibe-coding, typically after launch, addressed to whoever is holding the codebase at the time.
So anything touching authentication, payments, permissions or personal data gets a second reader as well. Same rule for both teams, which is what makes it enforceable. I raise it in week one now, rather than discovering the gap in month three.
How do you handle the human side?
Four agreements: one backlog so there is a single definition of priority, one shared channel so nobody forwards messages between camps, blameless incident notes written the same way whichever team caused the break, and a named escalation pair who talk before anything becomes a twelve-person thread.
| Week-one question | A good answer | What it looks like unanswered |
|---|---|---|
| Whose conventions apply? | Theirs, written down and shared | Two styles, two linters, noisy diffs |
| Who reviews whose work? | Both ways, inside a working day | Half the codebase unreviewed, half of it slow |
| Who owns each environment? | One named owner per environment | Staging "borrowed" in the middle of a demo |
| How is a disagreement settled? | A named escalation pair | A thread with twelve people on it |
I also watch for the small signs of drift: reviews left open for three days, an environment borrowed without a message, a decision made in a meeting the other team was not in. Each one is minor. Together they are how two teams become two sides.
At Shanti Infosoft I treat a shared codebase as one team with two payrolls, and I say that sentence in the kickoff so both groups hear it at the same time. It is the first thing I set up on any embedded software development engagement, and most of the friction disappears once nobody is waiting to see who gets blamed first.
If you share a codebase with a client's team today, could you say in one line who reviews what, and would they give the same answer?
Sonal Jain leads delivery at Shanti Infosoft, a CMMI Level 5 company whose 80+ engineers regularly work embedded with client teams.
Top comments (0)