Ask how hard it is to leave

Every custom software deal has two contracts in it. The first covers the build: scope, price, dates, acceptance, the things everyone spends weeks on. The second covers the next five years, and it is usually three pages at the back called something like Support and Maintenance. It gets drafted late, reviewed by whoever has capacity, and agreed in the same week as the signature, because by then both sides want this done.

That sequencing is the whole problem. The build is a project with an end. The support agreement is the thing you will actually live inside, and it is negotiated at the exact moment when neither party wants to raise anything difficult.

The three questions a support agreement has to answer¶

Most of them answer none of these clearly, and the ambiguity is not usually malicious. It is what happens when a document is written from a template by people who are thinking about the launch.

Who decides whether something is a defect?¶

Of every clause in a support agreement, who decides whether something is a defect is the one that produces the arguments. Your operations lead says the export is broken; the vendor says the export does exactly what the specification described and what you want is a change request, billable. Both can be sincere. The specification was written before anyone had used the thing.

A usable agreement says what the test is, in advance. There is more than one workable answer: behavior against the written specification, behavior against the documentation as it is maintained, behavior a trained user would reasonably expect. Which one you choose matters less than that it exists on paper before anybody needs it. What you are avoiding is the version where the test gets invented during the argument by whichever party has more leverage that quarter. So ask a vendor which test they work to. A firm that has thought about it has an answer, and will tell you where that answer does not favor them.

What response are you actually buying?¶

Response time and resolution time are different promises and the gap between them is where support agreements hide. An hour to respond means somebody replies within an hour. It says nothing about when the thing works again. A serious agreement distinguishes severity levels, states what triggers each, and says what happens when a severity-one issue is still open after a day: who it escalates to, and what you get if it does not.

Ask what the coverage window is in your timezone rather than theirs, and ask what happens on the days that matter to you. If your business is a distribution operation, the last week of the month is not the same as the second week, and an agreement that treats them identically has not been read against your calendar.

What do you pay in a month when nothing goes wrong?¶

A retainer buys availability, and availability has a real cost whether or not you draw on it. That is defensible and we charge for it. What is not defensible is a retainer that is never drawn down and never discussed: if you have gone four quarters without an incident, the right conversation is whether the tier is wrong, not a renewal notice.

Ask what unused hours do at the end of a period. Rolling, expiring and not-a-thing are all honest answers. Discovering which one it was in month seven is not.

A warranty is not a support agreement¶

Warranties and support agreements get conflated constantly, including by vendors who should know better, and they are different products with different logic.

A warranty is a statement about the work: for some period after acceptance, defects against the agreed specification get fixed at no charge, because you already paid for them to be absent. It is finite, it is narrow, and it should not be sold as support.

Support is a statement about the future: somebody keeps the system working while everything around it moves. Dependencies get security patches, a payment provider deprecates an API version, an operating system drops a TLS cipher, the tax table changes. None of that is a defect and none of it is optional. A custom system with nobody doing this work does not fail on a particular day; it degrades, and then one morning something with a certificate in it expires.

The exit is the part to read first¶

Here is the asymmetry worth knowing. A clean exit costs the vendor almost nothing to promise and is trivial for you to check, which makes it the single most informative clause in the document. A firm that intends to keep you by being good at the work will agree to all of it in about four minutes. A firm whose retention strategy is friction will find reasons.

Four things make an exit clean, and none of them is exotic:

• Credentials and accounts in your name from day one, not transferred at the end. Cloud accounts, domain registrar, certificate authority, app store listings, the repository, the error tracker. If it bills to your card it is yours already, and if it bills to theirs, ask why.
• A build somebody else can run. Not the source code, which you almost certainly already own, but the instructions and the configuration that turn source code into the thing your users log into. Source without a reproducible build is a filing cabinet.
• A runbook maintained as the work happens, not assembled during a notice period. Anything written by people who are leaving, under deadline, from memory, is thinnest in exactly the places you will need it.
• A notice period stated in the agreement, with no exit fee, and a defined obligation to help during it. Assistance at the end is worth more than every other clause here and is the one most often left out.

Notice that three of the four are things a competent vendor is doing anyway, for their own benefit. That is the point. The exit terms are cheap to honor precisely when the work has been done properly, which is why refusing them is so informative.

What to ask, including us¶

Five questions, all of which can be asked before you have a proposal, and all of which we would rather answer on a first call than in month nine:

1. 1.Who decides whether something is a defect, and what is the written test?
2. 2.What is the difference between your response time and your resolution time, and what happens when the second one is missed?
3. 3.What do I pay in a quarter with no incidents, and what happens to what I did not use?
4. 4.If I want my own team to run this in eighteen months, what does that involve and what does it cost?
5. 5.What are you keeping that I would need in order to leave?

The last one is the one that gets the most interesting answers. It is also the question we would want asked of us, because we build systems for organizations that will outlive the engagement and the honest goal is a client who stays because leaving would be a bad idea, not because it would be a hard one.

For what it is worth, three of the four are already on our own process page, in the phase that covers maintenance and support: your engineers in the codebase from day one, documentation written as the work happens rather than at the end, and transfer of every credential, account and domain whenever you ask. The engagement runs month to month with no minimum term after the first release. We publish them because they are the terms we would want to read, and because a promise made on a page is easier to hold somebody to than one made on a call.