Clarify the decision and constraints first
Describe the problem before naming a preferred technology. Who will use the software, what is slow or error-prone today, and how will improvement be recognized? Include existing systems, data, regulatory and security constraints, deadlines and a person able to make decisions. A detailed feature list need not be complete. Separating fixed conditions from open questions matters more. A capable partner needs room to propose solutions, but should not have to guess what success means. A short brief with real priorities makes proposals easier to compare than a long specification with no decision criteria.
Decide what you are buying. You may need a team for discovery and a pilot, for evolving an existing product, or for taking responsibility for operations. These roles demand different skills. Name a product owner on your side, the availability of process experts and the extent of their authority. Without them, the supplier cannot test assumptions quickly. Express the budget as a range and distinguish initial discovery from continuing cost. Avoid demanding a fixed price for unknown risks; a broad early estimate can be an honest answer. Ask candidates to state what information would make the estimate narrower.
Build trust from evidence of work
References help when they resemble your problem and the supplier's actual contribution can be understood. Ask about the starting position, the supplier's role, key decisions, results and what the team changed after a mistake. A public portfolio may be limited by confidentiality; anonymized work examples can still demonstrate a method. Reject unsupported promises about guaranteed savings, certifications or regulated-industry experience. In the interview, notice whether the people answering are the people who will deliver the work. A polished sales team that disappears when delivery begins creates a real coordination risk.
Ask for one difficult decision from a previous project. Which assumption proved wrong, how did the plan change and who told the client? A useful answer shows early visibility of a problem rather than perfection. Check how estimates are formed and how scope changes are handled. If every concern receives the answer that it will be no problem, risk has no place in the conversation. Trust grows when a candidate clearly identifies dependencies on your own staff and openly names work it does not cover. Request a concrete example of a disagreement resolved with a client.
Examine design, quality and security
Ask the team to explain data flow, system boundaries, failure cases and a first verifiable delivery for one of your scenarios. You are not seeking a complete architecture for free; you are learning how they reason. How will they decide what to build or integrate? How will they assess load and data sensitivity? Which tests would prevent the most expensive error? The NIST Secure Software Development Framework gives software buyers a common language for secure development practices. Ask about dependency management, access, secrets and the response to a discovered vulnerability, rather than only asking for the name of a certificate.
Quality becomes visible in release and repair practices. Establish who reviews a change, what is tested automatically or manually, how a failed deployment is reversed and whether an incident can be explained. For software involving money or personal data, ask how correctness is checked and access restricted, not just how quickly a screen can be built. Tools can differ; the key is proportionate evidence that the critical path was verified. A process that cannot show its result is weaker than a simple procedure with a clear check. Include restoration from backup when data loss would be material.
Inspect how an ordinary working week will run
Ask what the first month looks like: who raises questions, who decides, when you will see useful output and how a change in scope is captured. GOV.UK guidance for work with external teams highlights a shared way of working and knowledge transfer. In practice, this means access to decisions, regular demonstrations and direct conversation between people who understand the process and the code. Meetings alone are not delivery. After each cycle, you should know what works, what remains uncertain and which decision is needed. Choose a reporting cadence that serves decisions rather than a ritual.
Clarify team composition and continuity. One senior architect cannot be the sole holder of knowledge and do every development task. Request a plan for holidays, departure of a key person or a changed priority. Documentation should explain important decisions and operations, not simply fill templates. Ask for access to the repository and continuous handover so value does not exist only inside the supplier's environment. Agree how product questions reach the people who can answer them. An unavailable client decision-maker can delay a strong team as effectively as an unavailable developer.
Use the agreement to preserve the ability to continue
Before signing, clarify ownership of delivered code, licences, domains, accounts and data. State who pays third parties, who controls credentials and how documentation is handed over. Define acceptance through concrete functional criteria, a security and operating minimum, and time to verify delivery. Fixed-price work needs a process for scope changes; continuing work needs a budget ceiling and regular continuation decisions. No agreement repairs an unclear relationship, but a sound agreement reduces disputes about what was meant to be delivered. Make the first milestone small enough to review in practice.
Plan for the end of the engagement as well. How will you receive source code, configuration, decision history, runbooks and account access? In what condition must unfinished tasks be handed over? Dependence on one supplier can be a deliberate choice, but its cost and exit path should be understood. If a proprietary platform is proposed, ask for the export route and cost of change. Let a lawyer review liability and warranty terms for the actual contract; a technical guide cannot replace legal advice. Ensure your organization controls the services it must operate after handover.
Use a pilot to compare abilities with promises
A short paid discovery phase can remove the largest uncertainty before a long contract. Its output might be a dependency map, a proposal for the first workflow, a data contract, a prototype of a critical case or an audit of the current solution. The deliverable should remain useful if the relationship ends. Agree on scope, date, evaluation and ownership before starting. A pilot is not a request for a complete platform design without payment; it is a shared test against a concrete problem. Evaluate the quality of the team's questions as well as its answers.
If several candidates are involved, give them the same scenario and a comparable frame. Notice who marks unproven assumptions, proposes measurement and refuses unsupported certainty. DORA uses measures connected to the speed and stability of software delivery. Use such measures as discussion topics, not a universal ranking table: the numbers depend on the product and its stage. More useful is whether the team can show that it learns from failure and that releases protect operations. Record findings immediately after each pilot so impressions do not replace evidence.
Recognize warning signs early
Be cautious with a proposal that states an exact price and date without understanding integrations, data or the decision process. Claims of a specific business result without baseline figures deserve the same scrutiny. Ask who will work on the project and who supervises subcontractors. Unclear code ownership, refusal of repository access, no test plan and reliance on one person can create expensive lock-in. A low price alone is not a fault if scope and limitations are explained; the danger is a price that omits the work needed to operate the result. Compare exclusions as carefully as included features.
Warning signs can also arise on the buyer's side. If the internal owner cannot make time to decide, key users are unavailable or data restrictions are hidden, even a capable partner cannot solve the project. A good proposal should name these conditions. Avoid choosing solely on the impression of a visual presentation. Compare specific answers to the same risks and record the reason for the decision. If you cannot agree on communication and authority before starting, the disagreement will likely grow under production pressure. Address these issues while a small change of plan remains possible.
A checklist for the first meeting and decision
Bring five things: a description of the target process, today's costs or problems, a list of systems and data owners, the main constraints and a person authorized to decide. Ask each candidate to identify the three largest uncertainties, propose a first verifiable stage, explain its security approach and describe handover. Write down unanswered questions and a date for answers. Compare candidates on confidence in their method, ability to collaborate and clarity of deliverables rather than the count of technologies listed. Ask what they would deliberately leave out of the first release and why.
Document the final decision on one page: why the team was selected, what the first stage must demonstrate, the stopping criteria and who approves continuation. Leave room for revision when new facts appear. EXCOIN offers custom software development, but this guide should not predetermine the choice. An internal team, an established product or postponing the project may be better in some circumstances. A suitable partner can recommend those options openly. The selection succeeds when it gives you the ability to make safe decisions after signing, not simply a contract and a kickoff date.