Choosing a software consultancy is not about finding the best pitch deck, the lowest day rate or the most recognisable logos. It is about identifying which partner can carry delivery risk, and prove it before you sign.
The wrong consultancy rarely looks wrong during the sales process. Problems appear later and can take the form of shallow discovery, a weaker delivery team than expected, unclear ownership and a project that quietly drifts.
Use these questions as a delivery readiness audit, not a procurement checklist. The goal is simple – separate consultancies that sell effort from those that own outcomes.
The 10 questions to ask before you sign
| Question | Good answer | Red flag |
|---|---|---|
| What outcome are you committing to? | Clear link between delivery and business result | “We’ll provide a team and work through the backlog” |
| Who will actually deliver the work? | Named lead, technical authority and team shape | “Team assigned after signature” |
| Have you delivered similar work before? | Relevant, recent examples with measurable outcomes | Generic logos and vague case studies |
| How do you discover risk before build starts? | Structured discovery that tests assumptions early | Certainty before investigation |
| How do you build, test, release and support software? | Clear QA, release, rollback and support practices | “We work agile” with no artefacts |
| What does your pricing model assume? | Clear inclusions, exclusions and change rules | Low price with vague assumptions |
| How will change control work? | Changes assessed against business value, cost, time and risk before approval | “We’ll be flexible” |
| How do you protect our data and systems? | Practical security controls explained for your project | Badges instead of operational detail |
| What will we own at the end? | Source, documentation, access and runbooks are clear | Working system, weak handover |
| How do we exit or transition if needed? | Handover and transition are planned upfront | Exit treated as a later problem |
1. What outcome are you actually committing to?
A good consultancy connects its work to a business outcome that delivers measurable value, whether through revenue generation, customer satisfaction, operational resilience, reduced technical debt, migration risk reduction or faster delivery.
One supplier sells capacity. The other understands the outcome.
If the answer focuses only on effort, i.e. “we’ll provide a team”, you are carrying the risk.
For legacy-heavy projects, a good consultancy should help you calculate the financial cost of technical debt, not just describe the engineering problem.
2. Who will actually deliver the work?
The people in the sales process are not always the people who deliver.
Ask:
- Who is the delivery lead?
- Who is the technical authority?
- How much time will they spend?
- Are they employees, contractors or offshore?
You are not buying a brand. You are buying judgement under pressure.
“Team assigned after signature” is a red flag.
3. Have you delivered similar work before? (External validation)
Relevance matters more than logos.
Look for alignment across:
- Technical complexity
- Integration constraints
- Data sensitivity
- Legacy environment
Ask what went wrong and how they handled it. If everything sounds smooth, you are not getting the real story.
How to validate references and case studies
Case studies are easy to polish. References are where the truth shows up.
When speaking to past clients, ask:
- What went wrong during delivery?
- How did the consultancy respond under pressure?
- Did the team you met during sales actually deliver?
- Were timelines and costs realistic?
- Would you hire them again?
Red flags:
- You are only offered senior stakeholder references (not delivery-level)
- Answers sound rehearsed or overly positive
- No access to someone who lived through the work
The National Audit Office guidance on technology suppliers reinforces why supplier selection, contract design and delivery capability need to be tested before major digital work starts.
4. How do you discover risk before build starts?
Discovery should expose unknowns, not confirm assumptions.
Look for:
- Technical risk identification
- Dependency mapping
- Data quality issues
- Integration constraints
Understanding blockers shapes the scope and determines whether value can actually be delivered. Strong consultancies work to identify and remove blockers early, while recognising that not every constraint can be resolved within the programme.
5. How do you build, test, release and support software in practice?
Labels are cheap. Delivery discipline is not.
Ask how work moves from idea to production:
- Backlog ownership
- Acceptance criteria
- Code review
- Automated testing
- CI/CD pipelines
- Release and rollback
- Support handover
Ask for artefacts. No artefacts = no real process.
Also clarify post-launch responsibility. Who supports production issues, what response times apply and how is knowledge is transferred to your internal team?
You should also understand how quickly the consultancy expects to deliver a first live release. Strong teams aim to deploy working software early, often within the first month, to validate delivery pipelines, expose operational risks and prove momentum.
Also clarify post-launch responsibility. Who supports production issues, what response times apply and how is knowledge transferred to your internal team?
A consultancy that treats delivery as ‘complete at release’ is leaving you with operational risk. This is also where weaker consultancies rely on language rather than evidence.
How to validate what you’re told (Internal validation)
This is about validating what the consultancy tells you directly, not what their clients say about them.
Good answers are not enough. You need evidence.
To pressure-test claims:
- Ask for real artefacts (delivery plans, risk logs, release checklists)
- Request walkthroughs of recent projects
- Speak to delivery team members, not just sales
- Check consistency across answers (process, pricing, timelines)
If everything sounds polished but nothing is tangible, assume it is sales positioning.
6. What does your pricing model assume?
Fixed price is not automatically safer. Time-and-materials is not automatically uncontrolled.
The real issue is risk allocation.
- Fixed price with unclear scope = risk pushed into change requests
- Time-and-materials without control = risk pushed into spend
Ask:
- What assumptions underpin the estimate?
- What is included and excluded?
- What triggers a change request?
Day rate tells you the cost of a person. It does not tell you the cost of achieving the outcome.
Understanding commercial risk in pricing
Every pricing model hides risk somewhere.
Ask directly:
- What happens if your assumptions are wrong?
- Who absorbs the cost of rework?
- How is scope ambiguity handled?
If risk is not explicitly allocated, it defaults to you.
7. How will change control work?
Change is inevitable. Poor control is optional.
A good consultancy will explain:
- How changes are identified
- How they are assessed (value, cost, time, risk)
- How they are approved
- How they are documented
‘We’ll be flexible’ is not an answer. It is how projects drift.
How will delivery be governed and reported?
This is where many projects fail.
Ask:
- What metrics are tracked (velocity, quality, risk)?
- How often is progress reported?
- How are risks escalated?
- Who makes decisions when trade-offs appear?
If governance is vague, issues will surface late. That’s the time when they are expensive to fix.
8. How do you protect our data and systems?
Certificates are not enough.
Ask about:
- Access controls
- Environments
- Logging and monitoring
- Incident response
- Subcontractors
- Data handling and deletion
If the answer relies on badges rather than practice, it is not sufficient.
9. What will we own at the end?
A working system is not enough if you cannot operate it.
Clarify ownership of:
- Code repositories
- Infrastructure
- Documentation
- Test assets
- Deployment pipelines
- Access credentials
This is where long-term control is won or lost.
10. How do we exit or transition if needed?
An exit plan is a sign of maturity, not failure.
Ask:
- How handover works
- What documentation is provided
- Who owns production environments
- What transition support is included
The best consultancies do not create dependency. They remove it.
Spotting outcome ownership v effort selling
Use this as a quick diagnostic:
Outcome-led consultancies:
- Define success in business terms
- Challenge your assumptions
- Expose risks early
- Link delivery decisions to impact
Effort-led consultancies:
- Focus on team size and velocity
- Avoid committing to outcomes
- Promise flexibility without structure
- Treat risk as the client’s problem
What changes in regulated or high-stakes environments?
In regulated or business-critical contexts, the criteria change.
You are not just buying speed or cost efficiency. You are buying controlled delivery under constraint.
Look for:
- Documentation quality
- Auditability
- Security discipline
- Escalation behaviour
- Experience with compliance stakeholders
How to assess cultural fit in practice
Cultural fit is not about personality. It is about behaviour under pressure.
Assess:
- Whether the consultancy challenges you early?
- Do they admit uncertainty?
- Do they document clearly?
- Do they escalate risk before being asked?
If the sales process feels frictionless, there will often be problems during delivery.
When to walk away from a consultancy
Not every risk can be managed. Some are structural.
Walk away if:
- The delivery team is not named before contract
- They cannot show real delivery artefacts
- Pricing assumptions are vague or avoided
- Answers rely on credentials rather than practice
- You cannot access meaningful references
If these issues are present before signing, they will be harder to fix after.
How to compare consultancies side-by-side
Most decisions are not about one supplier. They are about choosing between several.
To compare effectively:
- Score each consultancy against the 10 questions
- Weight outcome ownership and risk handling higher than price
- Compare assumptions, not just proposals
- Check consistency between sales answers, delivery detail and references
The strongest proposal on paper is rarely the safest choice in practice. The safest choice is the one that makes risk visible early.
Your role in successful delivery
Even the best consultancy cannot compensate for weak client-side ownership.
Before starting, ensure:
- Clear internal ownership and decision-making
- Availability of key stakeholders
- Access to systems, data and environments
- Alignment on priorities and outcomes
Delivery risk is shared. If your organisation is not set up to support the work, progress will stall regardless of supplier quality.
What happens if you get this wrong?
Choosing the wrong consultancy rarely fails fast.
It fails when:
- Timelines slip
- Costs creep
- Technical debt builds
- Internal confidence drops
- You become dependent on the supplier
By the time it is obvious, switching is expensive.
If the project is already slipping, the next decision is whether to rescue a failing software delivery project, reset the scope, or stop further spend.
Before you sign. The final checklist
Before committing, you should have:
- A named delivery team
- Clear scope assumptions
- Defined pricing model and risk allocation
- Evidence of delivery process
- Validated references
- Defined ownership of outputs
- Governance and reporting model
- Exit and transition plan
If you cannot confidently answer these points, it is worth pressure-testing your shortlist before committing. This is typically where external input adds value – validating suppliers before contracts are signed.
Why Catapult CX is a safer choice for complex software delivery
Most consultancies can describe these principles. Few can evidence them consistently.
The safest partner is not the largest or cheapest. It is the one that can show how it will reduce risk and deliver outcomes.
At Catapult CX, we align directly to the criteria above, with:
- Outcome ownershipWe define success in operational and business terms and link delivery decisions back to those outcomes throughout the project.
- Risk discoveryWe run structured discovery before committing to delivery scope, exposing technical constraints, dependencies and assumptions early.
- Delivery disciplineWe provide clear delivery artefacts from the outset, including plans, risk logs, release processes and governance reporting.
- Commercial clarityWe document assumptions upfront and manage change through defined, transparent control processes.
- Exit readinessWe design systems, documentation and access so that transition is possible at any point, without dependency on our team.
Our work typically starts where delivery risk is already visible with legacy systems blocking change, complex migrations, constrained environments or performance limitations.
We are brought in when delivery is complex and the cost of getting it wrong is high.
Choosing a software consultancy for a complex or high-stakes project?
Speak to Catapult CX before you commit. We’ll help you pressure-test your shortlist and identify where delivery risk actually sits.
FAQs. Evaluating a Software Consultancy
How do you evaluate a software consultancy?
Evaluate a software consultancy by testing evidence, not claims. Ask about outcome ownership, named delivery team, relevant case studies, discovery process, engineering practices, pricing assumptions, change control, security, IP ownership and exit planning. A good consultancy expects difficult questions.
What questions should I ask a software development consultancy before signing?
Ask who will deliver the work, what outcome they are committing to, how they manage discovery, how they test and release software, what the price assumes, how change control works, what security controls apply and what you will own at the end.
Is fixed-price or time-and-materials better for software development?
Neither model is automatically better. Fixed price can work when scope is clear and risk is understood. Time-and-materials can work when priorities need flexibility. The important issue is whether assumptions, acceptance criteria, change control and reporting are clearly defined, regardless of the commercial model.
What are the red flags when choosing a software consultancy?
Vague team allocation, no named technical lead, weak or irrelevant case studies, unclear pricing assumptions, no evidence of delivery process, poor security answers, no support model and no exit plan. If a supplier cannot answer your questions, they are asking you to carry too much uncertainty.
How important are case studies when choosing a software consultancy?
Case studies are useful but only if they are recent, relevant and measurable. A good case study shows similar complexity, sector constraints, technical environment or delivery risk. Generic logos and vague claims are not sufficient. Always ask to speak to a reference who lived through the project.
What should CTOs look for in a consultancy for regulated environments?
Strong documentation discipline, clear security controls, auditability, experience with compliance and risk stakeholders, escalation rigour, production support capability and demonstrable experience operating in constrained or high-risk environments.
