How to choose a software development company

Ask to see a real piece of work.

Look for a product you can open, a demonstration you can follow or a case study that explains the developer's role. An image of an interface does not, by itself, tell you who built it or whether it works.

Ask the company to explain the workflow, the constraints and the decisions behind the work. If a project is confidential, discuss whether there is another permitted example. Do not treat an impressive list of logos as evidence of a specific delivery role.

• Which parts of this project did your team build?
• Can we see the workflow, including a failure or exception?
• Which outcomes are measured and which are expectations?

Notice the questions they ask you.

A useful conversation should explore who uses the software, the current process, the awkward cases and the systems that need to remain. Choosing a technology before understanding the task can conceal important assumptions.

You should also be able to discuss alternatives. A small integration, configuration change or focused first release may address the problem without commissioning a larger platform. Ask why the proposed approach fits your situation.

Compare the same scope.

Two prices are not comparable if one includes migration, testing and handover while the other covers only a prototype. Ask for included work, exclusions, dependencies and recurring charges to be separated.

A fixed fee still needs a defined scope and a change process. A time-based arrangement still needs visibility over priorities and spend. Neither commercial model removes the need to understand what is being agreed.

• The users, workflows and integrations included
• Data cleanup and migration responsibilities
• Review, testing and acceptance arrangements
• Hosting, subscriptions and support charges
• What happens if the scope or a dependency changes

Agree how you will see and review progress.

Discuss who will demonstrate the work, who in your organisation can make decisions and how review feedback will be recorded. Choose examples that show the essential workflow, including permissions and failure cases.

Ask how access, backups, updates and deployment are handled for your project. A general claim that software is 'secure' is less useful than an explanation of the controls, responsibilities and testing relevant to the information involved.

Discuss the point when you might change supplier.

Before signing, establish what source code, account access, documentation and data exports you receive. Discuss ownership, third-party licences and any restrictions with the appropriate adviser where needed.

Support is a separate conversation: what is covered, when it is available, how requests are prioritised and what additional work costs. A friendly development relationship is valuable, but the important arrangements should remain understandable in writing.

A supplier comparison you can actually use.

Complete the same notes for each shortlisted company. Record the evidence or document supporting an answer, and leave unresolved points visible. A missing answer is a follow-up question, not automatically a reason to reject a supplier.

SUPPLIER COMPARISON

Company:
People responsible for delivery:

Work we have inspected:
Their role in that work:
Questions they asked about our process:
Recommended first release and why:

Included scope and exclusions:
Estimate, assumptions and change process:
Dependencies we need to resolve:
Review and acceptance arrangements:

Source, accounts and data access:
Testing and handover included:
Hosting and recurring charges:
Support scope and availability:

Evidence / documents received:
Open questions before committing:

Apply the same questions to Cosilan.

Insight Pipeline is the product currently available to explore through our website. Its public site explains the drainage report workflow and includes example data. Review it, ask about the work and discuss how your requirements differ.

Our approach page sets out topics to agree around scope, cost, reviews and handover. A short enquiry is enough to start that conversation; you do not need to provide confidential records or a complete technical specification.