Custom web application development services

Questions to ask a development partner

Signs of a healthy project

Involve the people who will use it

Applications built from managers' descriptions alone often miss how work really happens. Involving the people who will use the system daily, in discovery, design reviews and testing, produces software that fits their work and gets adopted. Their early feedback on a working version is worth more than lengthy specifications.

Ask any partner how they will involve your users.

Warning signs

• Fixed price for a large vague scope

  Risk shifted into cut corners or disputes.

• No working software for months

  Problems discovered late.

• Code hosted only by the developer

  You cannot move or audit your system.

• No mention of maintenance

  Software ages quickly without care.

A typical engagement

1. 01

   Discovery

   Process, users and options explored.

   Output: Scope and estimate

2. 02

   Iterations

   Features built and demonstrated regularly.

   Output: Working increments

3. 03

   Release

   First version launched with users trained.

   Output: Application in use

4. 04

   Support and evolve

   Maintenance and improvements by agreement.

   Output: Healthy system

Agreements that protect you

Agreements should cover ownership of code and data, confidentiality, how scope changes are handled, warranties for defects, support terms and what happens if either side ends the relationship. Keeping code in a repository your organisation controls, with documentation, means you can change partners without starting again.

Technology choices

Ask why the partner recommends particular frameworks, databases and hosting. Mainstream, well-supported technologies make it easier to find other developers later and to keep the application secure. Unusual or proprietary choices may suit specific needs but increase dependence on one supplier. A partner who explains choices in terms of your long-term interests, not just their preferences, is worth favouring.

Also ask how the application will be deployed and monitored.

Security practices

Ask how the partner manages access to code and servers, stores secrets, keeps dependencies updated and handles security issues if they arise. For applications holding personal data, ask how retention and access logging will be implemented. The ICO states that personal data must not be kept longer than needed.

Talk to past clients

Speak to organisations that have used the partner's applications for a year or more. Ask about reliability, how changes were handled and what support is like. Long-term relationships reveal more than launch-day impressions.

How estimates are given

Ask how the partner estimates work and what assumptions sit behind the figures. Good partners give ranges with explained assumptions, break work into features you can prioritise and update estimates as they learn more. Be cautious of precise figures given without discovery, which often hide either padding or optimism.

Handover readiness

Even if you plan a long relationship, ask what a handover to another developer would involve. A partner with good documentation and standard practices will answer confidently.

Start with discovery

A paid discovery phase is a good way to start a relationship with a new partner. It produces useful outputs, such as a process map, priorities and a technical plan, and shows how the partner communicates, challenges assumptions and estimates. If the fit is poor, you can take the discovery output to another partner rather than being committed to a full build. Make sure the outputs are yours to use either way.