The Release Tax
The code compiles. The benchmarks are documented. Internally, the project is done.
It does not exist yet.
The local environment is a private fiction. What follows is not engineering. No algorithm improves. No test is added. The work is pure administration: repository splits, license headers, CI pipelines, registry metadata, README variants for three different rendering surfaces. Each task is bounded and mechanical. Together they form a shadow project, running on the same schedule, with no additional time allocated.
On a team, this friction distributes. Someone owns the pipelines. Someone handles the license audit. Someone writes the registry descriptions while someone else reviews the CI matrix. The context switches happen in parallel, absorbed by the organization.
A single-operator execution runs them sequentially. Splitting a monorepo into 15 repositories means 15 separate CI configurations with no shared state, 15 sets of registry metadata, 15 README files written for an audience that has never encountered the code. A bug in the pipeline scaffold shows up after the first push. Some bugs wait for the first external user to exercise a path the harness did not cover.
The first release has no prior state to diff against. Every decision is made from scratch. The automation that would reduce the overhead does not exist yet, because building the automation is part of the release.
None of this appears in the commit history as progress. License headers register as noise. YAML files read as structural bureaucracy. The effort is invisible in the artifact and unaccounted for in any estimate that focuses on the logic.
A project that ships is not a project that compiles.
It is a project whose administrative infrastructure has been built under the exact same constraints that produced the implementation. For a single operator, those constraints never expand.