Production delivery case study
When delivery output outpaced verification capacity
Barn2Buyer is a production SaaS marketplace for horses, ponies, tack and equipment. This internal operating case study reports measured delivery data from the platform. It is not a client testimonial or guaranteed outcome.
Evidence boundary. These figures describe two different bounded Barn2Buyer work windows. This observational comparison does not isolate the process changes' effect. They are not a forecast or promise for another team.
26
pull requests merged in Run 1
11 hours, 47 minutes
31
pull requests merged in Run 2
10 hours, 28 minutes
About 34%
higher measured merge throughput
2.2 to 3.0 pull requests per hour
13 to 9
median changed files per pull request
smaller review units in Run 2
No revert pull requests appeared in either bounded run.
The delivery problem
Implementation became fast. Verification did not.
In the first run, writers could finish a change and then sit idle while CI ran. Larger work packets created more review work. Main builds could cancel one another, which left the combined result unverified for longer than any individual change. Unit tests also competed with integration and browser tests for the same shared test lock.
The answer was not more coding agents. More writers would have added work to a verification system that was already full.
What changed before Run 2
Four operating rules aimed to reduce avoidable waiting and unresolved work entering review.
- 01
Hand work back when the pull request opens
The integration owner watches CI and calls a writer back only when a correction is required.
- 02
Make work packets smaller and decision-complete
Each packet names expected behavior, boundaries, tests, and the claims a reviewer needs to challenge.
- 03
Let main builds finish
One build can run while one waits, so the combined branch receives a real verification result after merge bursts.
- 04
Reserve the shared test lock for constrained tests
Integration and browser tests use the shared resource. Unit tests no longer wait for it.
What moved
The second run cleared more work in less time, with smaller review units.
Run 1 merged 26 pull requests between 04:10 and 15:57 UTC on 18 October 2026. Run 2 merged 31 pull requests between 00:12 and 10:40 UTC on 19 October.
Measured merge throughput was about 2.2 pull requests per hour in Run 1 and about 3.0 in Run 2, about 34% higher in the second run after the process changes. Median changed files per merged pull request fell from 13 to 9.
The bottleneck moved to CI. Writers could now produce review-ready work faster than the available verification capacity could clear it. That movement mattered more than the raw pull-request count because it showed where the next control needed to go.
Run comparison
| Measure | Run 1 | Run 2 |
|---|---|---|
| Merged pull requests | 26 | 31 |
| Window length | 11h 47m | 10h 28m |
| Merge throughput | 2.2 per hour | 3.0 per hour |
| Median changed files | 13 | 9 |
| Revert pull requests | 0 | 0 |
The next run exposed a different blind spot
More review caught more, but each check still had a limited field of view.
21
new pull requests merged before the freeze
No revert pull requests appeared. A new visual-review gate recorded about 50 layout, consistency, and interaction findings before owner retesting.
A production-build crash passed the earlier controls.
One server-rendered page imported code that worked in unit tests and the normal CI build but failed when the page ran in a production build. Unit tests, CI, code review, and static visual review all passed it. A production-build browser run in another lane exposed the crash about 90 minutes later.
The lesson was concrete. More review does not guarantee safety. Code structure, runtime behavior, visual state, and real-device interaction need different checks.
Control-change diagram
The failed control led to a check at each evidence boundary.
Observed gap
Production runtime behavior was not exercised.
Earliest useful control
Run the affected route in a production build.
Required evidence
Browser execution, visible route output, and a passing guard.
Code structure
Repository guard for the invalid import pattern
Runtime behavior
Production-build browser checks for affected UI changes
Visual state
Open menus and controls during visual review
Real-device behavior
Walk the main flows on a real phone before a demonstration or release decision
What the evidence supports
A narrow operating claim, not a universal result.
After the delivery-process changes, measured throughput was about 34% higher in the second bounded run, median pull-request size was smaller, and verification capacity emerged as the next constraint. This observational comparison does not isolate the changes' effect.
It also shows the KingBee method in practice. Trace a visible problem through the workflow. Separate measured facts from assumptions. Locate the earliest useful control point. Change the smallest part of the system that can control the risk. Measure again, then record what the new checks still cannot see.
Start with fit
Find the first control gap in your own delivery workflow.
The standalone $2,000 AI SDLC Governance Blueprint traces one real failure pattern and recommends the highest-leverage next intervention.
Measurement windows and source records are retained by KingBee. GitHub supplied pull-request counts, merge times, changed-file medians, and revert checks for the stated windows. The contemporaneous internal run ledger supplied the Run 3 visual-review count and production-build incident. Participant names, private environment details, and security-sensitive implementation information are excluded.