Formation is work.
Dan Cohen's history of Zotero is a useful counterweight to instant software. Cohen writes that the rough first prototype took five years to form. The delay was not five years of typing. Historians tested partial ideas, combined a local research tool with browser capture, found the right platform, secured funding, and worked out what scholarly research needed from the product.[1]
The lesson is not to make coding slower. It is to stop treating code generation as product formation. A model can shorten implementation after a team can state the job. It cannot replace the years of observation that reveal which job deserves a durable contract.
Shipping faster changes the cost of the first build. It does not remove the cost of the tenth year.
Durability needs a named object.
Teams often call software durable when the repository still builds. That is one condition. Users may care more about whether old documents open, exports remain complete, keyboard paths still work, or another maintainer can recover the service without the original author.
SQLite makes one promise unusually concrete. Every SQLite 3 release can read and write database files created by the first SQLite 3 release from June 2004. The project promises to keep that file format backward compatible. It also states that forward compatibility is common but incomplete.[2] The promise names the object, the direction, and the limit.
Write the exception list.
Go's compatibility document promises that programs written to the Go 1 specification should keep compiling and running across future Go 1 releases. The same page records exceptions for security fixes, unspecified behavior, specification errors, buggy behavior, unsafe code, operating system interfaces, and tool behavior.[3]
That exception list does not weaken the promise. It makes the promise usable. A maintenance plan should use the same shape. Name the stable interface, then name the conditions that can break it.
Maintenance is product design.
The Hacker News discussion around Cohen's essay praised software that "just works," then pointed at the hidden effort behind that feeling. Other comments raised real friction around onboarding, old dependencies, self-hosting, sync, and long-lived professional tools. These are user reports, not controlled evidence. They show why durability cannot be reduced to uptime or repository age.[4]
- Choose the user artifact that must survive. It may be a file, URL, command, schema, or export.
- State the compatibility direction. Reading old data and supporting old clients are different promises.
- Assign an owner for migrations, dependency updates, security fixes, and documentation.
- Run recovery on a clean machine before the person with all the memory leaves.
The mileage dyno below combines a service horizon selector, four independent contract gates, a visible readout, and a copyable review card. It creates a maintenance brief. It does not prove that the software will survive the selected period.