Start with relevant experience, not the length of the client list. Ask for a couple of projects that sit close to your domain and your stack, and then find out who actually wrote that legacy code maintenance services. A serious vendor will put you on a call with the engineers. Vague answers at this stage usually mean the delivery team is not the team you were shown.
The paperwork warrants more scrutiny than the proposal. Three sections matter more than the rest: assignment of intellectual property, the NDA, and notice periods and handover. Every artifact must transfer to you once invoices are settled, together with documentation, pipelines and deployment scripts. Watch for wording that leaves so-called reusable libraries outside the transfer, since it is usually exactly the piece that locks you in.
Ask how they estimate. A serious estimate comes with the assumptions behind it, a breakdown by feature or module and an explicit range. A fixed-bid deal works only when the requirements are stable and documented; otherwise the vendor prices the risk in and you pay for uncertainty either way. Time and materials moves the risk back to the client, so it needs visible weekly reporting and a spending cap.
How the work is run beats team size. Ask what happens when the scope changes, who defines done and what the QA setup looks like. A mature team should be able to demonstrate running software development hourly rate rather than status reports. Clear, written acceptance criteria stay the only reliable protection against an argument at delivery time.
Last, consider the handover at the start rather than at the end. Require that the repository sits under your account from the beginning, and that documentation is updated as part of the work. A vendor with nothing to hide says yes immediately; resistance at this point says quite a lot.
