How review and handoffs work on a client build
Every piece of client work is reviewed before it leaves, and every build is written up for whoever touches it next. This is what that looks like from the inside, and what a reviewer here is actually checking for.
Two things happen to every piece of work before it is considered finished here. Someone other than the person who built it reviews it, and it is written up so that somebody else could pick it up without a call. Neither is optional and neither is a formality. Candidates tend to ask about the first one in interviews. The second one is where most of the habits actually get formed.
What gets reviewed, and against what
A typical assignment arrives with four things: the brief, the client context, the relevant SOP, and the name of whoever reviews it. The reviewer is known before the work starts, which means the work is written for a reader from the first commit rather than tidied up for one at the end.
| Work | Reviewed against | What that means in practice |
|---|---|---|
| Design | The brief | Does it solve what the client asked for, including the empty, error and long-text states, not only the hero section |
| Code | The standards | Readable by the next person, consistent with the rest of the codebase, and buildable from the readme |
| Automation | Real data | Tested with real records before it touches a live account, with the failure path checked before the happy one |
The automation row is the one new joiners underestimate. A workflow that is ninety per cent right silently drops the other ten per cent of a client's leads, and nobody notices for a fortnight. A review that only runs the happy path has not reviewed it.
How feedback is given
Feedback is written down and points at the thing, not at the person. That is partly a culture choice and partly a practical one. A spoken comment in a call is forgotten by the next morning. A written one can be checked off, argued with, and turned into an edit to the SOP if it turns out the same mistake is being made by everyone who follows the document.
Expect it to be direct. Nobody softens a review until it stops being useful, and nobody treats a long review as a verdict on the person who received it.
How the review loosens over time
Juniors are paired with a senior on real client work from the first week. On automation work, where the pattern is most visible, the first build of a given kind is done with a senior reviewing every step. The second is done with a review at the end. The third is yours, and the review becomes the same one everyone else gets.
That last step is the one people sometimes miss. Seniors are reviewed too. Being trusted to own a build does not mean it leaves without a second pair of eyes on it.
What a handoff contains
A build nobody else can maintain is not finished. Whether the next person is a teammate, the client's own staff or the same developer six months later, the handoff carries the same things.
- Handover notes that say what was built, what was decided and why, and anything deliberately left out.
- Credentials in the right place, never pasted into a chat thread or held in one person's head.
- A short readme for whoever picks it up next, enough to run and deploy it without asking.
- For design, the handover happens with the developer in the room, not over a comment thread.
- Any change to scope agreed on a call, written in a message that says what changed. That message is what the build follows.
If it was not written down, it did not happen, and nobody is expected to have absorbed it by osmosis.
Where the judgement is
None of the above is hard to describe. What takes practice is writing a handover for the reader who will actually receive it. A note for another developer on the team, a note for a client's in-house marketer who will edit the site, and a note for a North American client reading it at the start of their day are three different documents. Getting that right is most of what separates a build that stays healthy after launch from one that generates support tickets.