Seventy-three code-generation runs delivered the thirty-one items, roughly 2.4 per item once reworks are counted. The queue was almost never idle.
Case study · Chauffeur app, UAE
Salvaging a chauffeur app in the UAE
Turning an inherited 180,000-line codebase into a controlled delivery pipeline.
A client commissioned and accepted a completed software product, then left it idle for five months. It was live, complex and entirely unfamiliar to the Brunelly team. The brief was not to rebuild it, but to make reliable, governed changes to a system Brunelly had no part in creating.
- items delivered: 29 production defects, 2 stories
- 31
- active delivery days
- 5
- median from accepted brief to dev complete
- 72min
- pull requests merged, of 32 opened
- 30
- items reworked after human acceptance
- 0
01 · The challenge
A finished system, and a hard question.
A client had commissioned and accepted a completed software product. It had been built over seventeen months by nineteen contributors, and comprised roughly 180,000 lines of source across four applications: a Node and Mongo backend, two React Native apps for customers and dispatchers, and a React administration console. Development had then stopped for five months.
The brief was not to rebuild it. The client brought a defined backlog of production defects, and the question was narrower and harder: could Brunelly understand a large system it had no part in creating, make reliable changes to it, and move that work through a governed delivery process without losing control of what was happening?
The product was live, complex, and entirely unfamiliar to the Brunelly team.
- lines of source
- 180,000
- applications: a Node and Mongo backend, two React Native apps and a React console
- 4
- previous contributors, over seventeen months
- 19
- months idle before Brunelly
- 5
02 · What Brunelly did
One controlled queue,
one item at a time.
The inherited codebase was brought into Brunelly and work was processed through a single controlled queue. For each item, Brunelly used the accumulated project and codebase context to move through the same governed sequence.
- Step 01
Interpret the brief
Read the accepted brief against the accumulated project and codebase context.
- Step 02
Analyse the system
Examine the relevant parts of the existing software it did not write.
- Step 03
Generate and implement
Produce and apply the change to the live codebase.
- Step 04
Raise a pull request
Open the change for review, with its diff and context attached.
- Step 05
Review and rework
Respond to review feedback, including the platform’s own review, and rework wherever the review requires it.
- Step 06
Human acceptance
Hold the item open until a person accepts it. Nothing closes on its own.
That last step is the design constraint, not an afterthought. No item closed without human acceptance, and the record of each acceptance is retained.
03 · What came back out
Thirty items closed in five active working days.
Only items that reached Dev Complete are counted; everything still in Draft or Ready is excluded. Median time from accepted brief to Dev Complete was 72 minutes for work that did not span an overnight or weekend break; across all thirty-one items it was 101 minutes.
| Items delivered 29 production defects, 2 stories | 31 |
|---|---|
| Pull requests merged of 32 opened | 30 |
| Lines of fixes across 156 files | 6,411 |
| Code-generation runs about 2.4 per item | 73 |
- 15
- 16
- 17
- 18Weekend
- 19Weekend
- 20Inactive
- 21
- 22
Thirteen production defects closed on 16 April alone. 18 to 20 April was a weekend and a Monday with no activity; the queue resumed where it left off.
20secmedian gap between items
~12mintotal idle across 30 handoffs
The constraint on throughput was the supply of briefs, not the platform.
| Measure | Items | Min | Q1 | Median | Q3 | Max |
|---|---|---|---|---|---|---|
| All delivered items | 31 | 23 | 45 | 101 | 170 | 5,834 |
| Items not spanning a night or weekend | 24 | 23 | 37 | 72 | 105 | 193 |
The elapsed clock keeps running overnight, so seven of the thirty-one items carry a break inside their measured time, which is why the median is quoted and the mean (419 minutes) is not. Two pull requests were abandoned rather than merged; 167 review comments were raised across the set.
04 · What it took
What the work actually cost.
One developer on the client side spent roughly five hours, mostly reviewing and accepting work. An estimate from observation, not a measurement.
This engagement was one of four pilots run free by design.
Agency day-rate model · thirty-one defects
| Effort assumed per defect | Days, 31 defects | Modelled cost |
|---|---|---|
| Half a day | 15.5 | £10,850 |
| One day | 31 | £21,700 |
| Two days | 62 | £43,400 |
Modelled at a UK agency day rate of £700, applied to thirty-one defects: somewhere between £10,850 and £43,400 depending on the effort assumed. A model with its assumptions stated, not a quotation, and it leaves out review time on both sides.
05 · The wider finding
The condition it arrived in.
Automated assurance work against the same codebase showed how difficult the inherited environment actually was. None of these findings appeared on the client’s original backlog: they had paid for this product and accepted it as finished.
Code Assurance63
critical findings · code assurance reviewSecurity review13
critical vulnerabilities · authentication, authorisation, data exposure, financial controlsCritical-severity findings only, drawn on a shared scale. The two reviews examined the same codebase independently, so their findings overlap to an unquantified degree and are not summed. They describe the code as it was received, not issues fixed during the campaign.
06 · Conclusion
Key observations.
The engagement showed that Brunelly could enter a large, unfamiliar and structurally compromised software estate and begin delivering production remediation within hours, without giving up the approval boundary.
The result was not faster code generation. It was a delivery model in which the system reads existing software it did not write, executes continuously against a queue, routes its work through review, and stops at a human for acceptance every time. The audit trail of what changed and who approved it reconstructs four months later, which is the property that matters when the codebase handles other people’s money or their location.
Twenty-nine production defects and two stories. Five active days. An unfamiliar 180,000-line system. Governed from brief to accepted change.
Method and sources
Every figure is recomputed from primary records rather than read from a dashboard: the production billing ledger of 367 transactions, 32 pull request diffs, 1,634 work-item history entries, two independent automated audits, and repository history covering 3,320 commits from July 2024. Only items reaching Dev Complete are counted; work remaining in Draft or Ready is excluded, as is any work not produced through the platform. This engagement was one of four pilots run free by design.
Get started
Make software engineering repeatable.
Every engagement starts with a scoped pilot on one problem that matters, measured against how your team works today.