Start with relevant experience, custom development insights not the number of logos on the website. Request a couple of engagements that match your technology stack, and then ask whether those engineers are still with the mvp development company. A serious vendor is happy to connect you with the tech lead. Answers that name nobody at this stage usually mean the delivery team is not the team you were shown.

The agreement deserves more scrutiny than the proposal. A few clauses carry most of the weight: intellectual property assignment, non-disclosure, application support services and notice periods and handover. Everything produced must transfer to you as it is paid for, together with source code, designs and infrastructure as code. Look closely at language that keeps framework code outside the transfer, as this is frequently the dependency that makes switching painful.

Ask how they estimate. A serious estimate is accompanied by a list of assumptions, a breakdown per feature and an explicit range. A fixed price is only reasonable when the scope is genuinely frozen; when the scope is still moving the vendor prices the risk in and you pay for it anyway. Time and materials shifts that risk to you, so it demands a sprint cadence, demos and a budget cap.

The delivery process matters more than headcount. Find out how change requests are handled, who defines done and what the QA setup looks like. A well-run team should be able to show you a working build every one or two weeks. Clear, written acceptance criteria are your only real protection against an argument at delivery time.

Finally, think about the day you no longer need this vendor at the start rather than at the end. Require that the code repository stays on infrastructure you own from the first commit, and that a readme and architecture notes are kept current as the code changes. A partner who is comfortable with this accepts it without argument; hesitation here says quite a lot.