Maintenance Is the Real Cost

#concept

Summary

The cost of software was never in writing it — it is in running it after the first user arrives. AI collapsed the writing cost, which was always the small part, and left the real cost untouched. The trap of the vibe-coding era: "assemble in two weeks — easy; carry it forward — impossible." An internal service is an internal business.

Current Understanding

The misconception being corrected: "we couldn't build our own Jira before, and now with AI we can." False on both ends — developers always could (by hand, with a team, in months); they didn't because they didn't want to operate the result. The blocker was never capability.
What arrives with the first user: bugs and regressions, feature requests, "something's not working / working wrong / didn't work," logs, monitoring, on-call, uptime responsibility. The project built "to save on a subscription" becomes a standing job with dedicated people — exactly the job the vendor was paid to do.
The two-business paradox: a company whose product is X, quietly carrying a self-hosted tracker/logger, is running two IT businesses. Bad for the company (pays for one product, staffs two) and for the developer (a primary job you're blamed for neglecting, plus a secondary one you're blamed for neglecting).
The pendulum case: March 2026 — a company builds its own Jira clone and migrates; July 2026 — the same (or a similar) company returns to a bought tracker (Linear). Status: tentative (second-hand tweets, fuzzy identification), but it is the corpus's only observed outcome of the build-your-own-tools thesis, and it's a reversal.
The build-vs-buy checklist (prescriptive): rewrite only small, non-evolving dependencies; if it needs ongoing support, cost it as a separate project; count the operational load; ask whether the business wants a second IT business inside itself. Otherwise keep paying the vendor — the money buys operational offload, not code.
Where it agrees with the vault's spine: "writing code was never the bottleneck" is the same premise as harness-over-model and make-more-cheap-code's verification bottleneck. The corpus now has three candidates for the real bottleneck — context (Thorsten), verification (Theo), maintenance (this source) — which are not rivals: they are the costs at authoring time, at shipping time, and over the artifact's lifetime, respectively.

Evidence

All claims, the pendulum case, the checklist, the Datadog self-report — 2026-07-29-what-if-we-vibe-code-it.
The objection was already latent in the vault before this source named it: explosion-of-internal-software ("nobody owns the result") and emacsification-of-software ("maintenance is assumed away") both flagged it as their own weakest point.

Concepts: explosion-of-internal-software (the thesis this bounds), emacsification-of-software (forks age too), code-as-throwaway (throwaway is safe because unmaintained), make-more-cheap-code (the ship/no-ship line is also the maintain/no-maintain line), shedding-weight (the inverse move — deleting owned software rather than acquiring it), product-ownership (owning an outcome includes owning its ops)
Entities: thorsten-ball (the predictions this bounds)

Contradictions / Uncertainty

vs. explosion-of-internal-software / thorsten-ball: Thorsten predicts teams remix mid-size software ("Riverside but audio-only") and the Excel layer becomes real tools; this source's pendulum case is that pattern failing in the wild. Partial reconciliation: the club app passes this source's own checklist (tiny, no SLA, no external users) — the disagreement is only about where the threshold sits, not whether one exists. Recorded on both pages.
Does the objection survive agents doing the maintenance? The author assumes ops load lands on humans. The corpus's outer-loop material (agentic-loops, async-by-default) implies agents could absorb some of it — but no source demonstrates agent-carried ops for an internal service, and async-by-default's own caveat (proof produced by the thing being checked is not verification) cuts against trusting it blind. Open.
The pendulum case is one anecdote, second-hand. The author's own company is currently building a Datadog replacement — if it ships and survives, he becomes his own counterexample. Status: tentative.

Next Questions

Where exactly is the graduation threshold — the point at which a personal/internal tool must be owned like a product (on-call, schema, backups)? explosion-of-internal-software asks the same question; this source supplies the checklist but not the line.
For the webinar's HR audience: which of their candidate tools (candidate knowledge base, transcribe→summarize) fall on the safe side of the checklist, and which quietly cross into "second business"?

4.9 KiB Raw Blame History