Solutional
Selecting a software development partner for a business-critical system is not the same as buying interchangeable capacity. The supplier will influence architecture, operational risk, delivery speed and how easily your organisation can change direction later.
A polished presentation and a low rate card reveal little about those outcomes. A useful evaluation focuses on how the prospective partner thinks, communicates, delivers and responds when reality differs from the plan.
Start with the Problem, Not the Technology List
A credible partner should first try to understand the business process, users, constraints, risks and desired outcome. Be cautious when a supplier recommends a platform, cloud architecture or team structure before asking enough questions.
Ask the candidate to explain:
- the problem in their own words;
- the assumptions they are making;
- the most important unknowns;
- what should be validated first;
- which parts are likely to create delivery risk;
- what a useful first production milestone could be.
The quality of these questions is often more informative than the initial solution proposal.
Evaluate the People Who Will Actually Do the Work
Sales conversations are frequently led by people who disappear after the contract is signed. For complex software, meet the engineers and delivery leads who are expected to work on the system.
Find out:
- who makes technical decisions;
- how senior engineers remain involved;
- whether communication passes through several management layers;
- how responsibilities are divided between the client and supplier;
- what happens when a key team member becomes unavailable;
- whether the proposed people have solved comparable kinds of problems.
Relevant experience does not necessarily mean the same industry or technology. It may mean experience with similar complexity: regulated workflows, risky migrations, high availability, multiple integrations or long-lived systems.
Ask for Evidence, Not Generic Claims
Statements such as "we value quality" or "we work in an agile way" are impossible to evaluate without examples.
Request a case study that shows:
- the original business problem;
- constraints and difficult decisions;
- the supplier's specific role;
- what changed during delivery;
- how risks were managed;
- what reached production;
- how the outcome was measured;
- what the client would say about the collaboration.
The most useful case studies include trade-offs and lessons learned, not only success language.
Examine How Quality Is Built into Delivery
Quality should not be a final testing phase. Ask how the team prevents weak decisions and detects problems early.
Useful topics include:
- automated testing strategy;
- code and design review;
- continuous integration and deployment;
- observability and incident response;
- security practices;
- dependency and upgrade management;
- definition of done;
- technical debt decisions;
- documentation and knowledge sharing.
The partner should be able to explain how these practices change according to risk. A payment system and an internal prototype do not require identical controls.
Understand the Commercial Model
The cheapest hourly rate can produce the highest total cost if the project requires excessive coordination, rework or supervision.
Compare proposals using questions such as:
- What is included in the rate?
- Who handles analysis, testing, deployment and project coordination?
- How is unplanned work discussed?
- How quickly can priorities change?
- What information will we receive about progress and cost?
- What happens if the initial scope proves wrong?
- Can we stop after a small first phase?
A good partner makes commercial uncertainty visible rather than hiding it behind optimistic assumptions.
Test the Working Relationship with a Real Problem
A limited paid discovery or pilot is often more useful than a long procurement questionnaire. Give the team a representative problem and observe how they work.
Look for whether they:
- ask uncomfortable but relevant questions;
- involve your domain experts;
- make assumptions explicit;
- propose a small path to evidence;
- communicate bad news early;
- leave behind useful artefacts;
- improve your understanding even before implementation begins.
The pilot should produce a decision, not simply a prototype. You should know more clearly what to build, why, how and with which risks.
Check Ownership and Exit Conditions
A healthy partnership should not depend on lock-in. Clarify before signing:
- who owns the source code and intellectual property;
- where repositories and infrastructure accounts are held;
- how credentials are managed;
- what documentation is maintained;
- how another team could take over;
- how data can be exported;
- which third-party licences create restrictions;
- what assistance is provided at the end of the engagement.
A supplier confident in its value should not need technical captivity to retain a client.
Pay Attention to Warning Signs
Common warning signs include:
- a solution proposed before the problem is understood;
- only salespeople participating in evaluation;
- a team composed mainly of people who will learn on your project;
- promises of fixed scope, fixed budget and fixed deadline despite major unknowns;
- quality described only as manual testing at the end;
- reluctance to discuss failures or difficult projects;
- opaque subcontracting;
- dependence on one named expert;
- no clear route from a pilot to production;
- no credible handover plan.
One warning sign does not always disqualify a supplier, but several together indicate structural risk.
Choose for the Relationship You Need
Some buyers need temporary capacity. Others need a partner able to challenge requirements, own technical outcomes and stay with a system for years. Define which relationship you actually need before comparing companies.
For business-critical software, the strongest partner is usually not the one that agrees most quickly. It is the one that helps you make better decisions, exposes risk early, builds shared understanding and can explain how today's choices affect tomorrow's cost.
