Founder's Blog

Engineering notes, product updates and governance thinking — written by the founder.

150 builds, zero missing numbers

One build every 64 minutes on average. The number that matters is not 150 — it is zero gaps, zero duplicates, and build numbers in strict order with their timestamps.

150 builds, zero missing numbers

This is my build archive, B0001 through B0150.

The numbers

Builds                 150
Range                  B0001 – B0150
Missing numbers        0
Duplicates             0
Numbers match time     yes
First                  B0001   2026-08-28 13:04
Latest                 B0150   2026-09-04 04:15
Span                   6 days 15 hours
Average interval       64 minutes
Active days            8 · busiest day 29 builds

The product was renamed in the middle

This archive does not run under a single name.

NEXUS Control Tower    106 builds    B0001 – B0106
Entrovia NCT            44 builds    B0107 – B0150

The rename happened between B0106 and B0107. Both carry the same timestamp: 09-02 05:35.

The numbering was not reset. It did not start over at B0001, and no second numbering scheme was introduced.

That matters more than the 150. A product can be renamed, a company can be renamed, an interface can be rebuilt from scratch — but the record cannot break. The moment it breaks, the first 106 builds can no longer be connected to what came after.

Why every one is kept

Every build produces its own .app, numbered in sequence, timestamped, never overwriting the previous one.

Not as a souvenir. Because when something breaks, I need to know which build broke it.

If only the latest is kept, the only thing left to work from is memory. Memory cannot be verified.

The zero is the important column

150 builds, zero missing numbers, zero duplicates, numbers and timestamps in strict order.

That column matters more than the number 150.

150 can be padded. But if one number is missing, or two builds share a number, or B0100 is stamped later than B0101, the whole record loses its meaning.

A record that cannot prove its own continuity is not a record.

Sixty-four minutes

One build every 64 minutes on average, and 29 in the busiest day.

That rhythm is not a productivity metric. It says something else: the changes are small.

Change a little, build, verify. When something breaks, the range to roll back is small.

If I built once every two days, the changes piled up in between would make it impossible to tell which one caused the failure. At that point root cause analysis becomes guessing.

It now governs itself

At some point NCT started being used to manage the development of NCT.

The later half of these builds were produced under its own governance.

That is the hardest test and the easiest place to cheat — because the person who wrote the rules is me, and the only person able to bypass them is also me.

If the discipline does not hold, it breaks here first.