Look first at relevant experience, not the number of logos on the website. Ask to see two or three engagements that sit close to your stack, and then find out whether those engineers are still with the kubernetes development company. An honest provider will introduce you to the tech lead. Answers that name nobody at this stage almost always mean the demo work came from somewhere else.
The agreement needs more scrutiny than the proposal. Three sections matter more than the rest: ownership of the code, confidentiality, and exit terms and handover. All the work product has to transfer to you as it is paid for, together with source code, designs and infrastructure as code. Look closely at any clause that keeps so-called reusable libraries with the vendor, as this is frequently the part you cannot replace later.
Ask where their numbers come from. A serious estimate is accompanied by the assumptions behind it, a breakdown by feature or module and a range rather than a single number. A fixed price is only reasonable when the specification is complete; in any other case the vendor pads the number and you pay for it anyway. Hourly billing puts the risk on your side, so it requires visible weekly reporting and a spending cap.
Process matters as much as team size. Establish how change requests are handled, who writes the acceptance criteria and how testing is organised. A mature team will be able to walk you through running software development process rather than status reports. Written acceptance criteria remain the only reliable protection against endless rounds of rework.
Before signing, think about the end of the engagement before it becomes urgent. Insist that the code repository lives under your account from day one, and that the documentation is refreshed in every sprint. A provider confident in its own work accepts it without argument; a long negotiation over it reveals quite a lot.
