Software buyer preparation
How to Choose a Custom Software Development Partner
Choose a development partner by the quality of their decisions and the evidence that they can deliver your actual workflow. Give shortlisted teams the same brief, examine the difficult dependencies and agree how the software will be accepted and operated.
Start with your hardest delivery problem
A development partner is not only a team that writes code. The appointment places responsibility for understanding the work, managing changes and handing over an operable system. Identify what makes your project difficult before judging a portfolio: uncertain rules, legacy data, external access, hardware, adoption or ongoing availability.
This guide covers choosing a team across custom software projects. For customer-account separation and other portal-specific questions, use the client portal developer selection guide. Do not treat a technology badge as evidence that the team has solved your operating problem.
Write a common brief using the project scoping guide. Include one complete user outcome, the systems that must remain and the decisions you have not yet made. A useful proposal should respond to that context rather than substitute a standard feature package.
Ask for evidence, not confidential client material
Ask each team to explain one relevant delivery decision, the alternatives considered and how the result was checked. An anonymised example or a demonstration with synthetic data can be enough to assess reasoning. Do not demand someone else's private records or production credentials.
- Ask who would actually do the work and who reviews it.
- Request an example of acceptance evidence, a support runbook or a handover checklist.
- Ask what went wrong on a comparable project and how recovery was handled.
- Distinguish what the team built from services delivered by another supplier.
- Where references are available and authorised, ask about communication and support as well as launch.
A relevant explanation is more useful than an impressive result with no context. Do not treat a claimed percentage improvement as comparable without its baseline and measurement method.
Compare equivalent commitments
Create a decision record with the criterion, evidence supplied, unresolved question and your assessment. Mark an unanswered point as unknown, not as a pass. Use judgement rather than adding scores that can hide a critical weakness.
Hypothetical comparison: one proposal includes data cleanup and release support; another assumes clean data and ends at code delivery. Their totals are not directly comparable. Ask both teams to price and describe the same boundary before deciding.
Check inclusions, exclusions, dependency owners, review milestones and what would change the estimate. Agree cost and timing with the actual delivery team. A fixed commitment should explain its assumptions; an iterative arrangement should explain how you retain visibility and control. LCR describes these boundaries across its three ways to work together.
Make quality and AI-assisted work reviewable
Ask how the team tests business rules, permissions, integrations, accessibility and recovery. For web applications, OWASP ASVS provides a basis for specifying security verification requirements. Agree relevant requirements and evidence with qualified reviewers rather than accepting an unsupported “secure by design” claim.
Ask where AI tools may be used, what information may be shared with them and who reviews generated output. Faster code generation does not establish correct business behaviour. The team should still explain the implementation, test failure cases and maintain the result.
Confirm whether specialist reviews are needed for the proposed use. A broad software capability statement does not confirm suitability for every regulated or high-impact workflow.
Discuss life after launch before appointment
Document intended control of source repositories, hosting, data exports, deployment processes and third-party subscriptions. Clarify retained supplier components, licences and any dependency on proprietary tools. Have the relevant advisers review the agreement; this checklist is not a statement of legal ownership.
Name who monitors failures, approves changes, maintains dependencies and assists if another team takes over. Ask what support includes and excludes, and how incidents are prioritised. Do not infer an availability guarantee from the word “support”.
Evaluate LCR against the same criteria. Review the available project summaries, understand who is responsible for delivery and discuss the actual scope, not assumed services. Start with the discovery workshop guide if the problem is not yet sufficiently understood to appoint a build team.
Sources and review date
Primary guidance reviewed on 9 September 2026 is linked beside the claims it supports. Checklists and examples are planning aids, not measured research or client results. Examples are hypothetical. Confirm delivery scope, estimates and any specialist-review needs with the responsible team.
Questions
Frequently asked questions
Should we choose the lowest quote?
Compare equivalent scope, assumptions, acceptance and operating responsibilities first. A lower total may omit work that you still need.
Does using AI make a team the better choice?
Not by itself. Ask how the team protects information, reviews generated work and proves the required business outcomes.
Prepare a useful conversation
Bring the task and the unanswered questions.
Discuss the current workflow, source systems and first useful outcome with LCR Technologies.