Use a real problem to assess judgment
Give prospective partners a short description of your workflow, constraints and uncertainties. Ask what they would investigate before estimating. A useful answer names assumptions, explains tradeoffs and distinguishes information they have from information they still need.
Ask for a walkthrough of relevant work. Separate the visible product from claims about business results or the underlying technology. Request evidence and permission to speak with a client where appropriate, rather than relying on a logo wall.
Examine the delivery system
Find out who will make technical decisions, review code, test releases and communicate changes. Ask to see the format of a normal progress review and a typical decision record. The process should make unfinished work and risks visible.
Discuss a scenario where a requirement changes after development starts. The team should explain how it assesses the effect on budget, delivery dates and already completed work. An honest change process is more useful than a promise that nothing will change.
Make ownership explicit
Agree repository access, intellectual property terms, third-party licensing, credentials and deployment ownership before work begins. Include documentation and knowledge transfer in the definition of done.
Clarify what happens after launch: maintenance, response coverage, dependency upgrades and exit support. Start with a focused engagement if uncertainty is high, and use its deliverables to decide whether a larger commitment is justified.