The Build Is Part of the Product
Published: August 31, 2026 · Read Time: 5 min read · Category: Systems
Author: Abhishek Shivakumar (Systems & Audio Engineering)
A product is not shippable when the feature works once. Builds, signing, CI and verification are part of the thing customers actually receive.
The Last Mile Is the Product
A plugin can sound correct in a developer's build and still not be a product. Customers need an installer that runs, a binary that is signed, a bundle that hosts can validate, and an update path that does not make them distrust the next release.
The build system is where those promises become executable. It decides which source and dependencies are present, which architectures are produced, how resources are packaged, and whether two machines can produce the same result.
A Release Is a Chain of Claims
Every release makes a series of claims: this is the code we intended to ship; it contains the formats we advertised; it has not been altered; it installs on a supported machine; and it behaves like the version we tested.
Those claims need cheap checks. Compile every target, run pluginval, inspect bundle identifiers, verify signatures, install into a clean environment, and retain the artifacts and logs. A green unit-test run answers only one small part of the question.
Release minimumA releasable audio build should have a clean-machine build, format validation, signature verification, installer testing and an archived manifest of inputs.
Put the Checks Near the Failure
The useful CI check is the one that fails close to the mistake. A missing resource should fail during packaging before any customer encounters an issue. A wrong bundle identifier should fail before notarisation. A stale generated file should fail before the compiler sees it.
This also keeps failures legible. One job that builds, signs, uploads and publishes can be efficient, but it is difficult to diagnose. Separate compilation, validation, packaging and publishing steps make the dependency chain visible.
The Handover Test
The final test is whether another engineer can make a clean checkout produce the same artefacts without a private machine, undocumented environment variable or remembered incantation. If they cannot, the product still depends on its author.
Build speed matters because it determines how often the team can run this loop. That is why build work such as schmoothie is not housekeeping: it increases the number of verified changes a team can afford to make.