Quite often IT service providers are seen as the necessary evil delivering some software that contains bugs, misses features, or does not ship in time. However, following Conway's law most problems are just a reflection of the company ordering the software. In my opinion this problem can be solved simply by cooperation. Let's look at an example case that is unfortunately far too common.
It is a typical scenario. Company A wants to deliver some additional value to it's customers and thinks about creating an application. Unfortunately, company A either lacks the resources or the expertise to do that. Maybe there is some internal IT service department, however, that is too expensive. Therefore company A chooses to look for some external IT service provider. Company B makes the best impression. What now?
Sometimes the story continues as follows. Company B claims to deliver quality by following agile development methods. Company A wants to be able to plan and be cost efficient. They come up with a fixed price contract. Company B tries to deliver the quality, however, the scope was underestimated or not communicated correctly. Also some of the requirements are in contradiction. First, company B tries to fight this with over allocation and their best developers, but after some time they need to reduce the rate to limit the losses. When the product is finally released it is full of bugs and the expectation is not matched at all. The release is a huge disappointment!
This can all be fixed, right? Wrong. Company B has lost the trust of company A. Also the remaining developers want to leave as soon as possible. The handover to a new company C proofs that most of the code is bound together by band aids and that a complete rewrite or major refactoring is imminent.
No one should be in the described position. This is a total loss for all involved parties. Company A lost the credibility of their customers. Company B lost their reputation. Even the newly involved company C did not win much. Taking over such a (broken) product results in a lot of work that is shadowed by high expectations and a lot of confusion. Bringing back trust can be very rewarding, but the risk is maximized, too. So what steps are necessary to avoid that scenario?
Let's start with the obvious fact: No fixed price contract. Always go for time and material! Exception: One manages the expectation right and sets fixed price steps. But I never heard of such contracts so even if they exist they are rare...
The next thing you should always make sure is that the code is in your hands (at least periodically pushed to your mirror) and that you have one internal or hired external expert who can judge the code quality. That should not be a complete code review, but rather inspecting some key metrics, e.g., are unit tests available (coverage?), is a proper build system or CI pipeline available, or are style guides obeyed. The latter should always come from the product owner.
If the quality is not on the expected level then flags should be raised quite early. An immediate handover should happen if the quality is not reaching the expected level in a predefined time. This should happen much before any anticipated go-live appointment - early enough to be able to react appropriately. Even though this may now seem like an ultimate failure it is a much better reaction (and thus much better than the worst outcome) than the usual ones: ship the app anyway potentially leading to a huge reputation loss, or stop the launch right before its launch date. In both cases much more money is lost.
So the bottom line is: Fully commit to the agile game. Try less, fail fast. Most IT service providers are doing a good job and will be very cooperative. Remember: Your success is their business.