Application development and maintenance, including what happens after launch

Yes, and it is a large part of what we do. It starts with reading the codebase rather than quoting from a description, because the honest scope only becomes clear once you can see what is actually there.

Most inherited code is, to some degree. That is a starting point rather than a barrier: stabilise first, then reduce risk in the areas that change most often. Rewriting because the code is untidy is rarely justified on its own.

Usually a retained arrangement covering agreed response times and a volume of change, sized to the application. What matters is agreeing beforehand what counts as support and what counts as new development, because that boundary causes most disputes.

Yes, unfortunately. Dependencies acquire security vulnerabilities, platforms deprecate versions, and browsers change. An application left untouched for three years is not stable; it is accumulating an upgrade you will have to do all at once.

You should be able to. Code in your repositories, deployment in your accounts, documentation written for someone who has not met us. A supplier relying on lock-in rather than being worth keeping is a supplier you should be able to leave.

Yes. Adding capacity, covering a specialism, or taking a self-contained part of the estate are all common arrangements.