Results · one product, measured

Everything below comes from one build. Ours.

One operator and twelve specialist roles, on a live cybersecurity product. Position as at 2 August 2026, recomputed from the work record — not a snapshot anyone typed in.

These are a dated capture, not a live feed. The board they come from keeps running, and the figures move with it — up and down.

Read this first

This is a case study, not a track record. Every figure on this page comes from a single product that we built for ourselves, which means we also wrote the requirements and set the deadlines. That is an easier problem than a client engagement, and you should discount accordingly. The full case study says what it does and does not prove.

98%

Work completed

1,355 of 1,381 items closed

182/184

Features delivered

99% of the planned programme

2.64

Defects per 1,000 lines

every line shipped — within the 1–5 published for a disciplined team

17 days

To reach this scope

against a 9–18 month norm — see /results for the caveat

80.6

Quality score

coverage, checks passed and defects, combined

10.9 h

Active work per item

time actually spent, not elapsed

87%

Steps with no human

of the process runs unattended

165,000

Lines of working software

the product these numbers come from

The factory's own board showing issues closed, work packages completed, total lines, quality index, defect density and gate pass rate. — The board these figures are read from — not a slide rebuilt for this page, and captured on 2 August 2026 so every number above can be checked against it. The cost row is cropped: what a delivered item costs us to produce is not a price, and publishing it next to no price invites the wrong comparison.

What the same board says that is not flattering

Time lost to queueing rose sharply as more work ran in parallel, and that reading is on the board today. 43% of work was later redone. 12.1% of spend went on rework.

We publish these because a board that can only show good news tells you nothing on the day something goes wrong — which is the only day you urgently needed it.

Why we publish these →

Efficiency

We can tell you what a change costs before you commit to it.

Cost is metered per item, per feature and per specialist, on the same board that reports progress. That is unusual enough to be worth saying plainly — and it changes what a scope conversation can be about.

Metered per item, not estimated

We can tell you what a delivered item cost to produce, because the price of the work and the proof of the work come out of one record. Most suppliers can give you a day rate multiplied by a guess.

Rework is its own line

Measured and shown separately rather than absorbed into the total. A rework figure you cannot see is a rework figure nobody manages.

Scope becomes a value question

When the unit cost of delivery is visible, you can ask whether a change is worth what it costs to produce — a better question than whether it is worth three developer-days.

What an engagement costs →

Comparison

Against what comparable work normally takes

Measure	This factory	Typical for comparable work	Read
Work delivered as committed	94–96%	60–85%	Better
Time actually spent working	28%	10–20%	Better
Test coverage	80%	70–80% target	In line
Defects per 1,000 lines	2.64	1–5 for a disciplined team	In line
Effort to reach this scope	≈ 1 person-month	~200 person-months	Far lower
Calendar time to reach it	17 days	9–18 months	Far lower
Work later redone	43%	no published norm	Watch item

"Typical" means commonly published software-engineering ranges for work of comparable scope. The effort and calendar rows are an order-of-magnitude estimate, not a precise measurement — shown with that caveat rather than without it.

Proof

It is not built around one project.

The factory and its first product grew up together. The third product — an unrelated business, on an unrelated technology — is the evidence it transfers.

A cybersecurity platform

A live product analysing threat data for security teams. The build these numbers come from.

165,000 lines

The factory itself

It runs on its own line and passes its own checks. If it did not work, this is what would break first.

Proves it on itself

An education platform

A different industry, a different technology stack, documentation in another language. Brought onto the line in a day.

~147,000 lines

See what it reports about your system.

Pointed at a system nobody fully understands any more, the factory maps it and reports where the gaps are in about ten minutes — without overwriting a single existing document. Your prior work is input, not something we replace.

Talk to us