How to Evaluate a Custom Software Development Partner
What evidence should you request from a development partner? Review scope accuracy, boundaries, delivery methods, acceptance and maintainability.
Ask for comparable responsibility
When you shortlist a development partner, ask them to walk you through a comparable piece of work. A portfolio image can help you judge presentation; it cannot tell you who planned, built or tested what you see. Ask which parts the supplier delivered: discovery, architecture, interface implementation, migration, testing or ongoing operation.
For a technical corporate website, presenting an engineering firm’s services is different from developing its operational systems. Ask what the client supplied and where another team’s work began. A useful answer makes those boundaries clear. Confidentiality may limit names or screenshots, but the supplier can still explain their responsibilities without exposing a client’s private information.
Review an example of a difficult boundary
Choose one awkward part of your own project: access control, an unreliable integration or a migration with incomplete records. Ask what the team would need to inspect before recommending an approach. You are looking for questions that affect the work, rather than an immediate architecture based on a few sentences.
For example, suppose a staff member submits a record to an external system and the request times out. Ask the candidate to talk through what the staff member sees, how they would find out whether the record arrived, and what would happen before anyone tries again. This is a hypothetical evaluation exercise, not a description of delivered client work. It gives you a concrete way to discuss source ownership, error handling and recovery beyond a successful demo request.
You do not need to judge every technical detail yourself. Listen for whether the team identifies the missing evidence and can explain how it would affect the proposed work.
Examine acceptance and handover
Read the proposal alongside someone who will use the finished system. For each deliverable, can you identify the inputs you must supply, who will review it, what they will check and what the price excludes? Confirm what happens when access, content or an external dependency is unavailable.
Turn a broad deliverable into a reviewable example. For the integration above, ask whether acceptance includes only a successful submission or also the agreed behaviour when the external system cannot be reached. If that behaviour has not been agreed, you cannot yet compare proposals on equal terms.
Ask who will own the source code, environments and operating documentation. Then ask the supplier to describe the handover: where the code and instructions will live, who will receive access and how your team will know which version was released. The proposal should also explain what evidence accompanies a release and how a failed change can be reversed.
Maintenance needs an owner after the initial project ends. Confirm which support arrangements and third-party subscriptions are included, and which need a separate agreement or payment.
Compare the route to a decision
If important unknowns remain, we would start by defining the questions discovery needs to answer. For an integration, that might mean establishing what access is available and how failed submissions can be investigated. Ask what you will receive at the end and which decision that evidence will help you make: proceed, narrow the scope or investigate further.
Give each candidate the same small workflow and the same available information. Compare what they need to inspect, what they propose to deliver first and how they would demonstrate completion. When a candidate leaves a dependency unresolved, ask how that affects their estimate. This makes differences in scope easier to spot before a low hourly rate or an ambitious claim of scalability dominates the discussion.
Apply this to your project
Bring one workflow, the people who use it and the question you cannot yet answer. We can use that starting point to discuss what needs investigating before you commit to a build.
Explore technical discovery and the related anonymised project account. Discuss your implementation question.
Planning guidance from Webvelopment Editorial. Confirm platform requirements and project assumptions before committing budget.
Keep the right things connected.
Technical discovery before a costly commitment
Work through uncertain code, data and integrations with focused technical discovery before deciding what to build, improve or keep.
Repositioning a Professional Services Firm Through Digital Strategy and UX
An anonymised strategy and website project connecting audience research, service positioning, information architecture, content and conversion-oriented navigation.
Start a conversation
Tell us what you are working towards. We’ll help you find a practical next step.