Begin with relevant experience, not the number of logos on the website. Ask to see two or three engagements that sit close to your technology stack, and software development staff augmentation then find out which engineers actually built it. A solid partner will introduce you to the tech lead. Answers that name nobody at this stage usually mean the delivery team is not the team you were shown.

The paperwork warrants more attention than the sales deck. Three sections matter more than the rest: intellectual property assignment, confidentiality, and exit terms and handover. All the work product should transfer to you as it is paid for, together with source code, designs and infrastructure as code. Look closely at language that keeps so-called reusable libraries with the vendor, since this is frequently exactly the piece that locks you in.

Ask how they estimate. A credible estimate comes with the assumptions behind it, a task-level breakdown and a best case and a worst case. A fixed-bid deal is only reasonable when the specification is complete; in any other case the supplier prices the risk in and you pay for uncertainty either way. Time and materials puts the risk on your side, so it requires visible weekly reporting and enterprise application development in java a spending cap.

The delivery process beats headcount. Ask how a new requirement enters the plan, who defines done and how quality assurance works. A mature team can walk you through a working build every one or two weeks. Clear, written acceptance criteria are the only reliable protection against an argument at delivery time.

Finally, consider the day you no longer need this vendor at the start rather than at the end. Require that the 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 vendor with nothing to hide accepts it without argument; resistance at this point reveals most of what you need to know.