How to Choose a Bespoke Software Development Partner

01

The polished proposal that left one question unanswered

The proposal looked polished. The timeline was confident, the technology sounded modern and the price sat neatly inside the expected budget.

Nobody had asked who would own the source code repository. Nobody had explained how decisions would be recorded, what happened when the scope changed or how another developer could take over after launch. Those details felt less exciting than the proposed screens, so they were left for later.

That is how a business can choose a capable software company and still buy itself a difficult relationship. Bespoke software is not a finished product waiting on a shelf. The business is choosing the people, working method and technical foundations that will turn an operational problem into a live service.

The right partner should make the project clearer before making it bigger.

02

Start with the business outcome, not a list of screens

Imagine an established service business replacing a shared inbox and several spreadsheets with an internal portal. Customer requests need to arrive with the right documents, move through review and approval, reach the right team and appear in management reporting.

It would be easy to write a requirements list containing a login page, dashboard, document upload, status field, approval button and reports. Several suppliers could estimate that list. They may also build six different products because the list does not explain the operating problem.

Before speaking to potential partners, describe the result the business needs. Staff should be able to see who owns every request, incomplete submissions should be identified before review, managers should see delays without assembling a spreadsheet and the business should be able to show who made an important decision and when.

The GOV.UK Technology Code of Practice starts with defining user needs and asks buyers to consider security, privacy, integration, data, purchasing strategy and the full technology lifecycle. A private business does not need to copy a government process, but the principle is sound: understand the service and its users before deciding what technology to buy.

03

Look for useful questions before confident answers

A good first conversation should contain some polite friction.

The supplier should want to know who performs the work, where information comes from, which exceptions cause trouble, what must remain manual and how success will be measured. They should ask what happens before and after the proposed software, not only what the new screens should display.

Be cautious when every idea receives an immediate yes. Bespoke software can support an enormous range of requirements, but that does not mean every requirement is valuable, affordable or safe. A partner earns trust by explaining trade-offs and challenging assumptions without turning the conversation into a technical lecture.

For the portal, a useful question might be why managers need a new report. If the real problem is that requests have no dependable status, fixing ownership and workflow may remove the need for a separate reporting feature. You are not looking for somebody who agrees quickly. You are looking for somebody who can help the business make better decisions.

04

Ask what discovery will produce

Most software companies talk about discovery. The word can mean anything from a short sales call to several weeks of research, workshops, prototypes and technical investigation.

Ask what you will have at the end. Useful outputs may include a map of the current and proposed workflow, agreed user groups and permissions, a prioritised first release, prototypes for risky interactions, identified integrations and migration work, technical assumptions and a delivery plan with decision points.

The documents themselves are not the goal. Their value is that important decisions become visible before they are buried inside code.

A paid discovery can also be a sensible first commitment. It gives both sides a chance to work together on a real problem before the business awards a larger build. A very small project may not need a formal discovery phase, but it still needs enough shared understanding to explain the outcome, boundaries and first release.

05

Compare approaches, not technology buzzwords

You do not need to choose a programming framework before choosing a partner. You do need confidence that the proposed technology suits the service, team and expected lifetime.

Ask how the recommendation supports the expected users and workload, connects to existing systems, can be maintained by commonly available skills and depends on third-party services or licences. Ask how updates, security fixes and backups will work, and what would make the proposed choice unsuitable.

A familiar stack can be valuable because other developers can understand it and common operational problems have established answers. A newer technology may be appropriate when it solves a specific constraint. Neither is proof of quality by itself.

The warning sign is a technology choice presented as identity rather than reasoning. If every problem is forced into the supplier's favourite tool, the business may inherit complexity that serves the developer better than the operation.

06

Make scope, assumptions and exclusions visible

Two proposals can use the same project title while pricing completely different work.

One may include user research, prototypes, data migration, automated tests, deployment, staff training and a supported launch. Another may cover only application development against requirements supplied by the client. The lower price may be perfectly reasonable, but it is not the same offer.

A useful proposal explains what is included in the first release, what is excluded, what the business must supply, which estimates depend on untested assumptions, how acceptance will be agreed and who is responsible for hosting, migration, training and launch.

Do not expect every unknown to disappear before development. Bespoke projects contain uncertainty. The point is to make uncertainty discussable. Change control should give both sides a clear way to assess a request, understand the impact and choose whether to add it now, exchange it for something else or leave it for later.

07

Meet the people who will do the work

The person presenting the proposal may not be the person mapping the process, designing the interface or making technical decisions.

Ask who will work on the project, how much time senior people will spend on it and who has authority to resolve a difficult decision. If subcontractors or an offshore team are involved, that is not automatically a problem. It simply needs to be visible, along with how communication, review and accountability will work.

For a smaller project, one experienced developer or compact consultancy can provide speed, continuity and direct access. A larger agency can offer broader specialist cover and more capacity. An internal hire can be right when the software will need continuous product ownership inside the business.

Size is not the measure. Match the delivery model to the risk, duration and breadth of the work. Then make sure the people in the proposal are the people the business can actually reach.

08

Ask how users will shape the software

A portal can be technically correct and still make the team slower.

Ask how the partner will observe the current work, test unfamiliar journeys and gather feedback during development. A clickable prototype may answer some questions before code is written. A small working release with real users may reveal where the process and interface disagree.

The supplier should also explain accessibility. Internal software still has users with different needs, devices and working environments. A service used on a phone at a site visit needs different decisions from one used on a large office screen. Accessibility is easier to include in the design and component system than to add after launch.

User involvement does not mean accepting every request. It means testing whether people can complete the important outcome and understanding why they struggle. The product owner then decides which findings deserve a change.

09

Treat quality, security and privacy as delivery work

Do not leave quality assurance as a vague promise that the system will be tested. Ask what will be checked automatically, what will be tested by a person and how defects will be recorded and prioritised. Important workflows should cover incomplete documents, failed integrations, duplicate submissions, permission changes and interrupted approvals as well as the expected route.

Security questions should match the risk of the service. The National Cyber Security Centre recommends tailoring supplier assurance to the supplier's criticality and asking for evidence, not relying on a box-ticking exercise. Useful questions cover responsibility for security, protecting data, incident recovery, access control and the security of bespoke applications.

Privacy belongs in the design too. The Information Commissioner's Office says data protection should be considered from the design stage and throughout the product lifecycle. If the portal holds personal information, ask what data is genuinely needed, who can see it, how long it is retained and how it can be corrected or removed.

A certificate can support assurance, but it does not replace a conversation about your system, your data and your risks.

10

Protect ownership and access from the first day

Ownership is one of the least glamorous parts of a proposal and one of the most important parts of the relationship.

The contract should make clear who owns the custom source code, designs, documentation and project outputs. It should also explain how pre-existing supplier components, open source packages and paid third-party services are licensed.

Operational access matters just as much as legal wording. The business should know where the source code, cloud hosting, domain names, databases, backups, analytics, email services, administrator credentials and recovery methods are held and who controls them.

This does not mean every employee needs unrestricted access. It means the business must not discover after a disagreement that its application, domain and data can only be reached through one supplier account. An exit route is not a prediction that the relationship will fail. It is ordinary continuity planning.

11

Understand support before the launch date arrives

Launching software creates a live operational service. Somebody must watch it, respond when it fails, apply updates and help users when the expected route does not work.

Ask what the warranty period covers, what happens after it ends and how support is charged. Clarify response times, service hours, monitoring, backups, restore testing, security updates and the route for small improvements. If the system is business critical, ask what happens when the supplier is unavailable or ceases trading.

The 2026 UK Government Sourcing Playbook emphasises due diligence, risk allocation, contract management, successful supplier relationships and planning for the rare occasions when things go wrong. A smaller business can apply that thinking proportionately. The support agreement should reflect how damaging an interruption would be and how quickly the business needs a response.

Do not wait until launch week to discover that the build price excluded production hosting, monitoring, data migration or user support.

12

Use references to investigate decisions, not collect praise

Case studies can show that a supplier has delivered work in a similar setting, but the industry label is only a starting point.

Ask what was difficult, what changed after discovery and how the team handled disagreement or delay. Find out whether the client kept access to the code and hosting, whether users adopted the product and what the relationship looked like after launch.

A responsible supplier may not be able to reveal confidential details. They should still be able to explain their role, delivery approach and the kind of outcome they supported. Look for evidence that connects the work to a business problem rather than a gallery of attractive screens.

When speaking to a reference, ask whether they would choose the same partner again and what they would do differently. That answer is usually more useful than a rehearsed testimonial.

13

Compare price with risk and lifetime cost

The cheapest proposal can be the right choice when the scope is small, the risk is low and the business can manage more of the work itself. The most expensive proposal can still be poor value.

Compare the offers on the same basis. Include discovery, design, development, testing, migration, launch, hosting, licences, support and likely change. Consider the internal time needed from managers, subject experts and users. Check the payment schedule against visible outputs and decision points.

Day rates are easy to compare and difficult to use as a complete buying decision. A more experienced team may cost more per day and need fewer days. A low estimate may depend on the business supplying detailed requirements, clean data and rapid decisions. Ask what must be true for the price to hold.

Price the life of the service, not only the route to its first launch.

14

Watch for red flags that reduce control

No single awkward answer proves that a supplier is wrong for the project. A pattern of avoidable vagueness should slow the decision down.

Warning signs include a large build commitment before investigation, estimates with no assumptions, reluctance to discuss ownership, one technology proposed for every project, no route for user testing, security described only through the hosting provider, support left until the end and no practical handover plan.

Also pay attention to how questions are answered. A good partner can say, "We do not know yet, but here is how we will find out." False certainty is more dangerous than an honest unknown.

15

Score the evidence, then choose the working relationship

A short scorecard can stop the final decision being dominated by the best presentation or lowest total.

Choose criteria that reflect the project. For the internal portal, they might include understanding of the workflow, quality of discovery, delivery approach, user involvement, technical reasoning, data migration, security, ownership, support, price confidence and the people assigned.

Weight the important criteria before proposals arrive. A business-critical system handling personal data should give more weight to security, continuity and operational ownership than a disposable prototype. Record the evidence behind each score and any condition that must be resolved before award.

The score will not choose the partner on its own. It gives the decision-makers a shared view of why one offer is stronger and where judgement is still required.

16

Make the smallest responsible commitment

Choosing a bespoke software partner is not about finding a company that promises certainty. It is about finding people who expose uncertainty early, make decisions visible and help the business keep control of the service it is funding.

Start with one clear outcome. Ask what discovery will prove. Compare scope on the same basis. Meet the delivery team. Check users, quality, security, ownership, support and exit before signing the main build.

If the relationship is still untested, begin with a focused paid discovery, prototype or technical assessment. It should produce something the business can use even if it does not award the later development work to the same supplier.

If you are planning bespoke software and need an independent view before committing to a partner or proposal, I can help define the outcome, review the options and turn the project into a clear first decision.