Look first at domain experience, not the size of the portfolio. Ask to see a couple of projects that sit close to your technology stack, and then ask who actually wrote that code. An honest provider will introduce you to the tech lead. Vague answers at this stage generally mean the demo work came from somewhere else.
The paperwork warrants more scrutiny than the proposal. A few clauses carry most of the weight: assignment of intellectual property, non-disclosure, and notice periods and handover. All the work product should transfer to you as it is paid software development for fintech, including designs, scripts and infrastructure configuration. Be careful with wording that keeps framework code outside the transfer, because it is usually the part you cannot replace later.
Find out how the estimate was built. An honest estimate arrives with a list of assumptions, difference between rest and graphql a breakdown per feature and a range rather than a single number. A fixed-bid deal is only reasonable when the requirements are stable and documented; when the scope is still moving the supplier adds a risk premium and you fund the buffer regardless. Hourly billing shifts that risk to you, so it demands a cap, regular demos and transparent reporting.
The delivery process matters more than headcount. Ask what happens when the scope changes, who defines done and what the QA setup looks like. A well-run team will be able to demonstrate a live build at the end of each sprint. Written acceptance criteria remain the only reliable protection against endless rounds of rework.
Last, think about the end of the engagement at the start rather than at the end. Ask that the repository lives under your account from day one, and that the documentation is refreshed in every sprint. A vendor with nothing to hide will agree quickly; hesitation here tells you a great deal.