Every outsourcing agreement is specific about some things and silent about others. You agree on scope, on rates, on delivery dates. There is a clause about availability, and one about how quickly someone responds when something breaks. All of it sensible, all of it written down.
Then look for the clause about the state of the software you will eventually be handed back. In most agreements there is not one.
In this blog Jan Willem Klerkx, CEO of Boncode, explains why quality is the one thing almost nobody puts in a contract, and what changes when you do.
We agree on everything except the product itself
I have found this strange for twenty years. You can specify a response time down to the minute. In most contracts you cannot say anything at all about whether the code you receive can be understood and maintained by someone else.
So the vendor gets measured on delivery and availability, because those are the things that were agreed. Those are what appear in the monthly meeting. Maintainability does not, because nobody ever defined what it would mean.
And what is not agreed does not get prioritised. That is not bad faith. Every team in the world delivers the thing it is measured on.
This is not about controlling how they work
Here is where people tend to misread me. Putting quality in an agreement does not mean telling a development team how to write code. It means agreeing in advance what the result has to look like, and how both of you will know.
That is a very different conversation from checking up on someone afterwards. It is a shared agreement on what finished looks like, set at the start, when nobody is defending anything yet.
The strongest teams ask for it
In my experience the best vendors are the ones who welcome this. They know their work holds up. What they lack is a way to prove it, and a way to make the case for the time it takes to keep it that way.
When quality is part of the agreement, that case makes itself. It stops being the team asking for a favour. Both parties look at the same picture and decide together what deserves attention.
What you actually need to write down
You do not need a thick annex. You need three things. What gets measured. How often. And what happens when it moves in the wrong direction.
Set the level at the start of the contract so you have a baseline to compare against. Review it on the same rhythm as everything else you review. That is it. It fits on a page.
The alternative is what most organisations have today. An agreement that is precise about response times, and silent about the thing those response times exist to protect.