Custom software development

The delivery lifecycle

1. 01

   Requirements

   Users, tasks, data and rules captured in plain language.

   Output: Prioritised backlog

2. 02

   Architecture

   Components, data storage, integrations and hosting chosen.

   Output: Technical design

3. 03

   Build and test

   Features developed in small increments with automated tests.

   Output: Tested increments

4. 04

   Release

   Changes deployed to live in a controlled, reversible way.

   Output: Working software

5. 05

   Handover and support

   Documentation, training and an agreed support model.

   Output: Maintainable system

Environments and why they matter

Testing as part of every change

Automated tests check that existing features still work each time something changes. Without them, every new feature risks breaking an old one, and fear of change slows development. Unit tests cover individual pieces of logic, integration tests check that components work together and end-to-end tests walk through real user tasks. Manual testing by people who understand the work still matters, particularly for usability.

Code review, where a second developer checks each change, catches mistakes and spreads knowledge across the team.

Safe releases

Architecture choices in plain terms

• Mainstream technologies

  Easier to hire for, better supported, safer long term.

• Simple structure first

  One well-organised application is usually easier than many small services.

• Clear data model

  How records relate drives reports, integrations and future changes.

• Managed hosting

  Reduces the work of keeping servers patched and backed up.

Documentation that stays useful

Useful documentation explains how the system is structured, how to set it up and deploy it, what each integration does and where configuration lives. It is updated as the system changes rather than written once at the end. Combined with readable code and source held in a repository your organisation controls, it means another competent developer could take over without starting again.

Security throughout

Security is built in through practices rather than added at the end: least-privilege access, secrets kept out of code, dependencies updated regularly, input validated on the server and personal data retained only as long as needed. The ICO states that you must not keep personal data for longer than you need it, so retention should be designed into the system.

Writing requirements people can check

Requirements work best as short descriptions of what a particular user needs to do and why, with examples of the rules involved. 'A dispatcher can see all jobs due tomorrow, grouped by area, so routes can be planned' is easier to build and test than a vague statement about job management. Each requirement should have a way to tell when it is done, such as a worked example the finished feature must handle.

Prioritising requirements lets the most valuable ones be delivered first.

Monitoring live software

Once software is live, monitoring shows whether it is working: errors logged and alerted, performance tracked and background jobs checked. Problems are then noticed by the team rather than reported by users hours later. Simple dashboards for key processes, such as imports completed or emails sent, give non-technical staff confidence too.

Bringing existing data in

Much custom software replaces spreadsheets or older systems. Migrating their data needs planning: mapping old fields to new ones, cleaning duplicates and checking results with the people who know the data. Running a trial migration before go-live reveals problems while there is still time to fix them.

Agreeing a support model

Decide before launch how issues are reported, how urgent problems are handled and how improvements are prioritised. A clear support model keeps the software healthy and prevents small issues building up.