Begin with relevant experience, not the length of the client list. Ask for three or four projects that match your technology stack, and then ask whether those engineers are still with the aws development company. An honest provider will put you on a call with the people who would work on your project. Vague answers at this stage almost always mean the delivery team is not the team you were shown.

The agreement deserves a slower read than the pitch. Three clauses do most of the work: assignment of intellectual property, confidentiality, outsourcing and development insights termination and handover. Everything produced has to transfer to you as it is paid for, together with source code, designs and infrastructure as code. Look closely at language that leaves so-called reusable libraries outside the transfer, because it is usually the part you cannot replace later.

Ask how they estimate. An honest estimate comes with the assumptions behind it, a breakdown per feature and an explicit range. A fixed-price contract is only reasonable when the specification is complete; when the scope is still moving the provider adds a risk premium and you fund the buffer regardless. A time and materials vs fixed price-and-materials model shifts that risk to you, so it needs a cap, regular demos and transparent reporting.

Process beats team size. Establish how change requests are handled, who writes the acceptance criteria and what the QA setup looks like. A team can walk you through a working build every one or two weeks. Clear, written acceptance criteria are the practical protection against the it-was-never-in-scope conversation.

Finally, consider the handover while the relationship is still good. Require that the repository lives under your account from the first commit, and that the documentation is refreshed in every sprint. A vendor with nothing to hide accepts it without argument; hesitation here says quite a lot.