8 Questions to Ask a Bespoke Software Partner Before You Sign

01

A good sales call is not the real test

Most software companies can run a convincing sales meeting. They can show attractive work, describe an experienced team and produce a proposal with a tidy timeline. None of that tells you what the relationship will feel like when an important assumption turns out to be wrong.

That matters because bespoke software contains uncertainty. A new customer portal, operational system or reporting platform has to fit real people, awkward exceptions, existing data and services that were not designed with the new project in mind. Some details only become clear when the team starts investigating them.

The purpose of supplier questions is not to catch somebody out. It is to see whether they can make uncertainty visible, explain trade-offs and leave the business with enough evidence to make a responsible decision.

The eight questions below complement a broader software partner comparison. They are designed for the shortlist meeting, when several suppliers look capable and you need to understand how each one will behave once the easy answers run out.

02

1. What do you need to learn before you estimate this?

A useful supplier should be able to describe the unknowns before promising a price. For an internal portal, those unknowns might include the current workflow, user permissions, the quality of spreadsheet data, third-party integrations, reporting rules and what happens when a request does not follow the expected route.

Listen for the work they would use to answer those questions. That may include interviews, process mapping, data inspection, technical investigation or a prototype for the riskiest interaction. The word discovery is not evidence by itself. Ask what it will produce and which decisions it will allow the business to make.

A rough range may be reasonable before that work. A precise figure built on untested assumptions is not automatically safer. It can simply move the uncertainty into later change requests.

The strongest answer separates what is known, what is assumed and what needs to be proved before the main build begins.

03

2. Tell us about an assumption that failed

Case studies usually describe the finished result. Ask about a point when the original plan stopped fitting the evidence.

The supplier does not need to reveal a client secret. They should still be able to explain the kind of assumption that failed, how they found out, how they presented the problem and what changed in the plan. A team that claims nothing meaningful has ever gone wrong is giving you very little to judge.

You are listening for calm behaviour rather than a heroic rescue story. Did the team raise the issue early? Did it explain the effect on cost, timing and scope? Did it offer realistic options? Was the decision recorded so everybody understood what had changed?

Bad news is part of software delivery. The useful test is whether a partner makes it easier to act on, or waits until the problem is too large to hide.

04

3. Who will actually work on the project?

The people in the pitch may not be the people doing the discovery, design, development or support. Ask to meet the proposed delivery lead and somebody who will make technical decisions day to day.

Find out which roles are named, how much senior involvement is included and what happens if a key person becomes unavailable. If subcontractors or overseas teams are involved, ask how review, communication and accountability will work. The delivery model can be perfectly sound, but it should not be a surprise after the contract is signed.

A smaller consultancy may offer direct access and continuity. A larger agency may offer wider specialist cover and more capacity. Neither is better without context. Match the team to the project risk, expected lifetime and amount of support your own organisation can provide.

The important point is simple: evaluate the team you will work with, not only the people who sold the project.

05

4. How will you show that each release works?

A promise to test the software is too broad. Ask what evidence will exist before a release reaches users.

The answer may combine automated checks, code review, security review, manual testing and acceptance by the people who understand the business process. For a customer portal, that means checking missing information, failed integrations, duplicate submissions and permission changes as well as the happy path.

Ask how defects are recorded, how urgent issues are separated from minor improvements and how users will see working software during delivery. Regular demonstrations are useful, but they should lead to decisions rather than becoming theatre at the end of a sprint.

A good answer connects testing to the consequence of failure. A disposable prototype and a business-critical system holding personal data should not receive the same level of assurance.

06

5. What happens when scope or cost changes?

Change is not proof that a project has failed. The business may learn something from users, an integration may behave differently from its documentation or a commercial priority may move. The question is how both sides will decide what to do next.

Ask how a proposed change is described, estimated and approved. Can the business exchange it for lower-priority work, add it to a later phase or fund it now with a clear effect on timing? Who is allowed to approve extra cost?

Fixed pricing can suit work with stable boundaries. Time and materials can suit work where learning is expected. Both models need visible assumptions, decision points and a shared view of progress. Neither removes the need for trust and control.

A useful partner does not use change control to punish learning. It uses it to stop learning from quietly turning into an unlimited commitment.

07

6. What will we own and control from day one?

Legal ownership matters, but practical access matters too. Ask who owns the custom code, designs, documentation and data. Then ask where the source repository, cloud account, domain, database backups and administrator recovery details will live.

The contract should distinguish custom work from the supplier's existing components, open source packages and paid third-party services. If a reusable component is licensed rather than assigned, the terms and future cost should be clear.

Your business does not need unrestricted access for every employee. It does need a controlled route to the assets required to operate, recover or hand over the service. Repository access promised only at the end of the project leaves an avoidable gap.

An exit route is not a sign that the relationship lacks trust. It is continuity planning for software your business may rely on for years.

08

7. How will you protect our data and service?

Security questions should follow the risk. The National Cyber Security Centre advises organisations to tailor supplier assurance to the supplier's criticality and to ask for evidence that controls work in practice.

Ask who is responsible for security, how privileged access is controlled, how vulnerabilities are handled, how incidents are reported and how data is recovered. If the supplier uses cloud services or subcontractors, ask how those dependencies are assessed and recorded.

When personal data is involved, establish whether the supplier is acting as a processor and what the contract must cover. The Information Commissioner's Office guidance includes documented instructions, confidentiality, security, subprocessors, assistance with rights, audits and what happens to data when the contract ends.

A certification can support an answer. It should not replace an explanation of how your particular application, accounts and information will be protected.

09

8. What happens after launch, or if we part company?

Launch is the start of operating the service. Ask who monitors it, applies updates, responds to incidents, tests backups and helps users when the expected route breaks.

Clarify the warranty period, ongoing support model, service hours, response targets and the route for small improvements. A business-critical system may need more formal cover than a low-risk internal tool. The agreement should reflect the actual cost of interruption rather than a standard support package copied into every proposal.

Then ask the awkward exit question. What documentation will be maintained? How will source code, data, infrastructure details and credentials be transferred? What help will another supplier receive, and how will your data be returned or deleted?

The partner you choose may support the system for many years. A clear handover plan helps that relationship because neither side has to rely on hidden access or undocumented knowledge to keep it together.

10

Use the answer, not the confidence

These questions are useful only when the answers produce evidence. A polished response can still be vague, while an honest unknown can be a strength when the supplier explains how it will be investigated.

A short comparison table can stop the final decision being dominated by presentation style. Record what each supplier showed, what remains unproven and which condition must be resolved before award.

11

Make the first commitment small enough to learn

You are not looking for a supplier who can predict every detail. You are looking for people who ask useful questions, explain uncertainty and help the business keep control while the answer becomes clearer.

If the main build still feels like a large leap, start with a focused paid discovery, prototype or technical assessment. It should test the working relationship and leave the business with useful outputs even if a different team delivers the later software.

The right bespoke software partner should be able to talk about awkward moments before you create one together.

If you are preparing to appoint a software partner, I can help define the outcome, review proposals and turn the technical detail into a clearer business decision before the main commitment is made.