Handover as a design constraint

We build assuming we will not be here in two years. It changes what we are willing to ship.

Every system we build is designed to be inherited. Not documented after the fact: designed for it, which is a different constraint and one that shows up in the architecture.

It rules things out. Clever pipelines that only one person understands. Undocumented prompt chains that work through accumulated trial and error. Anything running on infrastructure we control rather than the client. Each of those is faster to build and leaves the client dependent, which is a business model we have chosen not to have.

It also changes what good looks like. A system a client can modify slightly is worth more than a marginally better one they cannot touch. So configuration lives in a file someone in operations can read. Thresholds are values, not code. The runbook covers what to do when the model starts behaving oddly, including how to turn it off.

At handover we transfer credentials, repositories and documentation, and we train whoever inherits it. Most clients then take a support retainer, which is fine, but it is a decision made after the transfer rather than a condition of it. The difference matters: one is a choice, the other is a lock-in.