# How to evaluate a software development partner

> Use the same workflow, evidence requests, and delivery questions to compare software teams beyond their portfolios.

- Published: Sep 25, 2026
- Topic: Project planning
- Author: RDR Digital
- Original: https://rdr.digital/blog/choosing-a-software-development-partner

A portfolio can show that a team has built attractive software. Your decision also needs to establish how that team will understand your operation, expose uncertainty, and leave you able to run the result.

Give potential partners the same small, realistic brief. The comparison becomes much more useful when each team responds to the same workflow and constraints.

## Bring a problem with an exception

Describe the people involved, the current task, and the desired outcome. Include systems the work must connect to and a difficult case that matters.

An illustrative brief for an ordering portal might say: a customer chooses products at agreed prices; a manager reviews an exception; an approved order reaches the warehouse. Then ask what happens if the warehouse connection is unavailable.

Look for questions that uncover missing decisions. Who owns the price? Can the customer change an approved order? Which status should support staff see? Treat an explicit unknown as something to resolve, rather than demanding confidence before the team has enough information.

## Ask for evidence of the delivery process

Request examples the supplier can legitimately share. A redacted sample is enough; there is no reason to expose another client's private work.

| Ask to see                               | What you are trying to understand                  |
| ---------------------------------------- | -------------------------------------------------- |
| A short discovery output                 | How findings become scope and open questions       |
| A delivery plan with assumptions         | How dependencies affect the proposed sequence      |
| A demonstration and its acceptance notes | How the team establishes that work is usable       |
| A sample change request                  | How scope, cost, and timing decisions are recorded |
| A support or handover outline            | What happens after the initial build               |

Discuss who will actually do the work and how you will reach the person responsible for decisions. A named contact is useful only when their authority and availability are clear.

## Make security a practical conversation

NIST's [Secure Software Development Framework](https://csrc.nist.gov/projects/ssdf) provides a common vocabulary for secure development practices and for conversations between software producers and buyers. It is a useful starting point for questions; mentioning the framework is not evidence that a particular supplier follows it.

Ask how the team controls production access, reviews changes, tracks dependencies, handles reported vulnerabilities, and separates real customer data from development work. Request evidence proportionate to the system you are buying.

For a project handling sensitive information, include an appropriately qualified reviewer in the evaluation. A general questionnaire cannot establish that a specific implementation is secure.

## Compare proposals on the same basis

Check what each price includes: design, integration investigation, data preparation, testing, launch support, documentation, and continuing maintenance. Identify items that depend on another supplier or on your staff.

Agree who can accept a change and what happens when an assumption proves wrong. A fixed price with unclear exclusions is difficult to compare with a proposal that makes its uncertainty visible.

Use our [software cost guide](https://rdr.digital/blog/what-drives-software-project-cost) to build a consistent comparison, and ask the team to turn one requirement into [acceptance criteria](https://rdr.digital/blog/writing-acceptance-criteria).

## Discuss the end before the start

Request explicit arrangements for source access, service accounts, documentation, third-party licenses, and continuing support. Confirm ownership and usage rights in the actual agreement; paying for development does not answer every rights question.

Finally, walk through a hypothetical handover to another maintainer. What would they receive, and could they run the system with it? Our [handover checklist](https://rdr.digital/blog/software-project-handover) makes that discussion concrete.

## Sources

- [NIST: Secure Software Development Framework](https://csrc.nist.gov/projects/ssdf)