After launch

Launch day is the start of a piece of software's working life, not the end of the project. Once real customers and real data are involved, it needs looking after. Here is what that involves, who can do it, and what to agree with your developer before you commit.

Why software needs looking after

Bespoke software is built from your own code plus a lot of other people's: frameworks, libraries, hosting services and payment or email providers. All of those change over time, and some of the changes are security fixes. Meanwhile your business changes too, so the software has to keep up with how you work.

Software that nobody maintains does not stay still. It drifts out of date, gets harder to change, and becomes riskier to touch the longer it is left.

What looking after it involves

1. Security updates

The libraries and services your platform relies on need updating when problems are found in them. This is routine, regular work, and it is much easier to do a little at a time than to catch up on a large backlog.

2. Careful upgrades

Sooner or later a framework or hosting platform moves to a new version and the old one stops being supported. Upgrades should be planned and tested rather than rushed, so that nothing your team depends on stops working.

3. Performance work

More customers, more data and more features all put weight on a system. Occasional tuning keeps pages and reports fast as the business grows.

4. Monitoring and incident response

You want to hear about a fault before your customers do, and you want someone to respond when it happens. Agree in advance who is told, how, and who acts.

5. New features

Once people use the software, they will find things they want it to do. A good arrangement makes it simple to add those features in small steps, rather than treating each one as a new project from scratch.

6. Support for your team

Questions will come up: how do I do this, why did that happen. Somebody who knows the system and can answer quickly saves your team time.

Who can do it?

• The team that built it. They know the code and the reasons behind its decisions, which is usually the quickest route to a fix. The risk is relying on one individual, so ask how the work is shared and documented.
• An in-house developer. Sensible if software is central to your business and you have enough work to keep someone busy. For a small business it can mean a single point of failure.
• A different supplier. Possible, but they will need time to learn the system first, and it helps enormously if the code is tidy and documented.

What to agree before you start

The time to talk about support is before the build, not after launch. Ask your developer:

• Who owns the code, the hosting accounts and the data?
• What does ongoing support include, and what is charged separately?
• How will you tell me what has been done and what is planned?
• What happens if something breaks, and who is responsible for fixing it?
• Is the technology widely used and well supported, so that another developer could pick it up if needed?
• Will there be documentation, and is it yours to keep?

That last pair matters more than it looks. Software built on well-established technology, with decent documentation, is easier to look after and far less tied to one supplier.

A hypothetical example

Imagine a business that had a custom ordering system built. It works well at first, and nobody thinks about it again. Then a payment provider changes how it connects, a library the system uses is flagged as insecure, and the team asks for a new report. With no one responsible, each of these becomes an emergency or gets ignored.

With a support arrangement in place, the same three things are ordinary jobs: the update is applied and tested, the change to the payment connection is made before it affects customers, and the report is added as a small feature. Nothing dramatic happens, which is exactly the point.

Keeping the cost sensible

Support does not have to mean a large, open-ended commitment. Start with what protects the business: updates, monitoring and a named person to contact. Add feature work when you have a clear reason to. Reviewing the arrangement now and then, with your developer, keeps it matched to what you actually use.

If the software matters to how you take orders, serve customers or get paid, looking after it is not an optional extra. It is part of the cost of owning it.