A proposal can be detailed and still conceal the decision that matters. We once saw a build described down to screens and integrations while nobody had stated who would own the source code, production accounts or deployment keys. The ambiguity survived until procurement asked, because every earlier conversation had focused on features.
A technology partner should reduce uncertainty before signature, including uncertainty that makes the sale harder. The useful questions are the ones that force boundaries into the open.
Ask what is being assumed
Every quote rests on assumptions about data quality, decision speed, content readiness, integration access, traffic, compliance and browser or device support. Ask for those assumptions as a written list. Then ask which one would change the price or schedule most if it proved false.
A worrying answer is that everything is included. Complex work always has edges. Another warning is a fixed promise built on systems the partner has not inspected. Confidence without a dependency list usually means contingency has been hidden in price or deferred to change requests.
A strong answer distinguishes known scope, discovery questions and exclusions. It also says what evidence will close each unknown.
Ask who owns every operational asset
The client should know who owns repositories, cloud accounts, domains, analytics, model accounts, app-store records, design source files and vendor contracts. Production credentials should live in client-controlled infrastructure or have a documented transfer path. Access for the studio should be removable without rebuilding the product.
Ask what happens on the day the relationship ends. Can another team deploy, rotate secrets, restore data and understand open incidents? What documentation and handover are included? If continuity depends on goodwill or one employee's laptop, the risk already exists.
Ownership is not the same as maintainability. Source code can be legally transferred and still be practically unusable without environments, runbooks and decision history.
Ask how failure will be recognised
A partner should name success measures and stop conditions before implementation. For an AI feature, that means eval cases, unacceptable failure modes and a plan for weak results. For commerce, it means operational scenarios beyond checkout. For a performance project, it means field metrics and test conditions.
Be cautious when the answer is that feedback will tell us. Feedback is useful, but it does not replace a threshold for go, no-go or redesign. Also ask how defects, scope changes and incidents differ contractually. If every unexpected outcome is called new scope, delivery risk has been moved entirely to the buyer.
Listen carefully to what receives a no
At Clodron, no is part of the work. We say no to native apps when a web product satisfies the requirement. We say no to AI automation without an owner for exceptions. We say no to production agents with broad credentials, and to model changes without evals. We do not propose Web3 where an ordinary database solves the trust model. We do not build a design system merely to make a small surface look mature.
These are not universal prohibitions. They are examples of a partner protecting the project from an impressive but unnecessary build. A studio that never says no may be optimising for initial scope rather than the operating product. Ask for a recent recommendation that reduced the partner's own invoice.
Put the answers into the agreement this week
Before signing, create a short decision sheet covering assumptions, exclusions, acceptance, ownership, environments, security responsibilities, third-party fees, change control, support and exit. Link each material promise to the contract or statement of work.
Ask the delivery lead, not only sales, to review it. Resolve answers such as normally, later or depends into a named owner and decision point. Record what the partner needs from the client and by when.
The goal is not a contract that predicts every event. It is a working relationship in which bad news has somewhere to go. What a partner says before signature is useful. What they are willing to write down is the stronger signal.