The client already had a developer and a requirements owner. One more contractor on top of that team would only have added borders: a separate task list, separate decisions, separate accountability.
We chose a different shape. Two of our engineers joined the client’s team, we took technical leadership, and for 632 days we worked inside one shared process. The goal was plain: the product had to grow inside the company rather than stay a black box belonging to an outside supplier.
Snapshot
| End-client sector | manufacture and installation of glass structures |
| End client | under the code-name Glass Configurator, Russia |
| Engagement | 2 bureau engineers inside the client’s team; technical leadership on our side |
| Task | strengthen the team building an industry-specific product |
| Cadence | 2-week sprints, up to 20 analyst hours per sprint |
| Engineering baseline | code review, separate development and production environments, automated build and deploy |
| First release | 69 days after the model started, into pilot use |
| State as of 5 August 2026 | the code and its development stay inside the client’s team; there has been no formal handover of the product |
The problem
By the time of the restart the client had their own developer and their own requirements owner. Before that the bureau ran the whole project. Now accountability had to be split so that we would not end up with 2 teams editing the same code in turns.
The client decided to lead development in-house and bring our specialists in at partial load. Not a separate contract sitting alongside, but the missing roles filled inside their own team.
We covered analysis and the front end, and our analyst became technical lead for the whole team. The bureau owner did not have to turn into a dispatcher: of the 2,103 messages in the working chat, 11 were his. The engineers dealt with the client directly.
Why this is hard
The risk in this shape is not visible at the start. While a team is small you can push changes straight to the main branch, keep development and demos on one machine, and pass credentials around in chat. It all looks fast, right up until the code has to be reviewed, deployed without downtime, or handed to a new person.
In this model the client is not paying for a pair of hands. They need code that can be handed to other people 2 years from now without a rewrite. But an external technical lead is not the in-house developer’s boss. Every rule has to be won with an argument and a working example rather than a job title.
How we did it
1. Split accountability by role. The bureau supplied an analyst-developer and a front-end developer. The analyst also took technical leadership and code review across the whole team, including the client’s own developer. Engineers settled technical questions directly, owners settled financial ones. We worked in 2-week sprints, up to 20 analyst hours each.
2. Introduced review before merge. At the start, changes could go straight into the main branch. The new rule was simple: a branch per task, then a merge request and a review. The habit took 2 months to settle and needed a second conversation. After that the client’s developer worked to the new order on his own.
3. Separated development from production. The first proposal was to manage with one machine: early stage, few users. We insisted on a separate server for the running version, because launching someone’s branch could otherwise wreck a demo for the client. Automated build and deploy per branch came later.
4. Settled arguments with code. Our engineer wanted the generation logic moved into its own layer; the client’s developer disagreed. What settled it was not the technical lead’s authority but a code sketch, on which the new version read more clearly. The rule worked in the other direction too: the front-end developer showed the risk of hidden errors in editing hardware records, and a decision already taken was replaced by safe copying of a record within 3 days.
5. Took developers out of catalogue work. Hardware and cut-out parameters are entered through the interface. The client’s requirements owner loaded the catalogue himself and said, unprompted, that the editor was comfortable to use.
Incidents and response
This shape has a price. 3 working episodes show it better than any description.
The production server was down for 2 hours 5 minutes. After a restart the database, cache and file storage did not come back up: no automatic restart policy had been set for the containers. Along the way we found passwords sitting in a plain config and moved user management into console commands. The sources do not confirm that the restart policy was added afterwards. We are not masking that debt.
Hardware coordinates drifted apart: 37 hours to a fix. The layout changed on the back end while the geometry builder on the front end stayed as it was. The client’s developer rewrote someone else’s front-end script himself instead of handing the task to the person who owned that code. It was fixed overnight. The rule about checking the result on a test server appeared after the incident rather than before it.
A branched migration history: 1 hour 52 minutes of night-time work. After merging branches the back end refused to start: the order of migrations had diverged from what was already applied on the server. After 2 failed attempts the schema was reconciled by hand, bypassing the standard mechanism. The archive ends here, so we make no claim that the remaining defects were closed.
There were standing costs as well. Code review depended on 1 person and piled up while he was on holiday. Partial load stretched out the calls. And decisions made by voice went missing: once the team spent half a day reconstructing why a branch existed, and nobody involved could recall the reason.
Results
| Metric | Value |
|---|---|
| Work inside the client’s team | 632 days as of 5 August 2026 |
| To the first version | 69 days, then pilot use |
| Analyst cadence | up to 20 hours per two-week sprint |
| Engineer autonomy | 11 of the 2,103 working-chat messages came from the bureau owner |
| Practices that stuck | branch per task, code review, separate environments, automated build and deploy |
| Catalogue work | done by the client through the interface, without developers |
| Open limitations | code review depends on 1 person; decisions from calls did not always reach the documents |
The code did not stay with an outside supplier. The client’s team takes part in development, loads the catalogue itself, and can keep working without routing approvals through the bureau owner. The price of that independence is visible too: the rules took time to settle, and the weak spots in the process had to be found on real failures.
Team
- Analyst-developer from the bureau, technical leadership and code review across the team
- Front-end developer from the bureau, the configurator interface and the 3D scene
- Anton Hersun, Xaver Pro, project manager
If you have your own team but lack people or domain experience, describe the stack, the tasks and how your process works. We will tell you who is worth adding to the team, under which working rules, and what you get at the end of the first month. The first conversation is free.