What to check before you sign

The proposal has been negotiated and the price argued over. The clauses that will matter in year three are elsewhere in the document, and none of them is on the pricing page. There are six, and each can be checked in a single conversation before anything is signed.

Put the source code in the client's hands

The repository is either accessible from day one, or the code is not owned in any sense that matters. "The client owns the source code" appears in many contracts; the version that holds up is operational, not declarative — a repository the client's people can open today, with the history, not an archive promised on request at exit. The difference shows up exactly once, at the moment it cannot be fixed: when the relationship is ending and the bargaining position has already changed sides.

The gotcha to watch for is escrow theater: code deposited with a third party, releasable under conditions that require a dispute to trigger. Escrow has legitimate uses. As a substitute for repository access, it converts ownership into litigation.

Name where the data lives — and how it leaves

A contract that names the hosting region but not the deletion path has answered the easy half of the question. Where the data sits — an EU region, Hetzner, the client's own infrastructure — is the residency half, and for an EU industrial company it should be boring: EU by default, movement elsewhere only by agreement. The half that gets skipped is the way out: in what format the catalog, the quotes, and the history can be exported, who performs the export, and what gets provably deleted afterward.

European law has started pushing in this direction. The EU Data Act applies since September 2025 and requires easier switching between data-processing services, with switching charges removed from January 2027. Worth knowing, and worth not over-reading: the legal right to switch does not perform the migration. Extraction, validation, re-integration, and the process change on the buyer's side remain the buyer's work whatever the law says about the fees. The contract clause is what turns the right into a procedure.

Split the retainer into its layers

A single "maintenance and support" line is the least informative sentence money can buy. The running cost of a system splits into three layers — infrastructure, availability, development — and only the first two are obligatory. A contract that itemizes them separately tells the buyer what can be dialed down without breaking anything: the response-time commitment is negotiable, the storage is arithmetic, and the development budget is a choice renewed each quarter, not a standing obligation. A contract that bundles them prices a choice as if it were an obligation, and the buyer pays for the ambiguity.

The one figure that belongs in this clause explicitly is the response-time commitment — how fast, on which days, for what class of incident. It is the availability layer's price variable, and it is the buyer's to set.

Name the operator on both sides

Two names belong in the contract: who answers on the vendor side, and who owns the system on the client side. The vendor half is familiar — the support commitment, the escalation path, the person who picks up when quoting stops on a Friday. The client half is the one contracts leave silent, and its absence is how working systems get orphaned: the internal owner is promoted, nobody inherits the role, and the system drifts while every vendor obligation is being met to the letter. Writing the client-side owner into the engagement — with a named deputy — costs one line. It is the cheapest durability feature either party can buy.

Write the handover while the vendor is still here

The handover documentation is written during the build, or it is not written. A runbook that lets a new person operate the system, a decision log that explains why the architecture is what it is, a permissions map that shows who can touch what — these exist reliably only when they are deliverables inside the phases, demonstrated as they land, not a documentation phase scheduled for the final week and compressed when the timeline slips.

The verification is the two-person test: two people who are not the vendor run one full price-list cycle — load, review, approve — using only the runbook and their own permissions. Pass, and the handover is real. Fail, and the documentation is a folder.

Test the exit with one question

Ask the vendor: if we decided to remove this system, how long until it is gone with no business impact — and what would still work the next morning? The answer exposes the architecture more honestly than any diagram. A system designed to be deletable — removable in about a week, data exported, quoting falling back to a documented manual path — is a system with clean seams, and clean seams are what make every earlier clause in this article enforceable. A vendor who treats the question as hostile has answered it too.

We hold the unfashionable version of this position: switching cost is a defect, not a feature — a vendor who says "you should stay because leaving would be hard" is selling the problem they created. We do not sell retainers whose value is switching cost; a client who wants to leave, leaves. And the position has a delivery-structure consequence, not just a philosophical one: we arrange the phases of a build so that every phase ends with something finished and working. If the engagement stops after any phase — budget, priorities, a better vendor — the client holds software that runs, not a fraction of a promise. Quality standards have named the property for years — ISO/IEC 25010 files it under maintainability, flexibility, portability — but a dealer does not need the standard. The one question does the work.

This position comes from experience on the wrong side of the table. When we paused our first-iteration platform in 2023, we were the vendor who left: roughly one hundred production deployments had to wind down or migrate as the product ended. Watching customers exit a system we built — some cleanly, some not — is where the deletability requirement comes from. It is not generosity. It is what we would demand, having been on both ends.

The six clauses on one page

Clause	The question to ask	A good answer	A warning sign
Source code	Can our people open the repository today?	Access from day one, history included	"Available on request at contract end"
Data	Where does it live, and how does it leave?	Named EU region + export format + deletion path	Region named, exit unmentioned
Retainer	Which layers are we paying for?	Infrastructure, availability, development itemized; development optional	One "maintenance & support" line
Operators	Who answers on your side; who owns it on ours?	Two names and a response-time commitment	A support inbox and silence
Handover	Can two of our people run a price cycle from the runbook?	Tested during the build, per phase	"Documentation phase" in the final week
Exit	How long to remove this with no business impact?	A number, a fallback, an export	The question treated as bad faith

Every phase of the negotiation before this table was about what the system will do. The table is about whose it will be — and that is the half of the contract that compounds. Both decisions that set the five-year cost — who maintains the data, and who operates the system — are made at the signature, not at the go-live. The six clauses above are where they get made in writing.