What happens after custom software is built? Why ongoing support matters

We see the same pattern again and again in small and medium businesses. A company commissions a bespoke system, a developer or agency builds it, and there is a launch, an invoice and a handover. Then the supplier moves on to the next project.

On day one the software usually fits well. It was designed around how the business worked when the brief was written. The trouble is that the business does not stay still. The software does.

Within a few months the gap starts to open. Nobody decided to let the system fall behind. It simply had no one whose job was to keep it up to date.

The changes are rarely dramatic. A new member of staff needs a different view of the data. A new client wants reports in their own format. A process that used to take three steps now takes five because a regulator or a supplier changed something.

If the software cannot adapt, people adapt around it. A spreadsheet appears next to the system to track the thing it does not handle. A shared inbox becomes the real record of who said what. Someone starts re-keying the same details into two places every morning.

Each workaround makes sense on its own. Together they mean the system holds less of the truth every month, so the team trusts it less and uses it less. Eventually the expensive custom software is the thing everyone avoids, and the business is back on spreadsheets with an extra bill attached.

Our view is simple. The launch is where the most useful work starts, not where it ends.

Before a system goes live, everyone is guessing to some degree. Good discovery gets you a long way, but you only find out which tasks still eat people's time once real staff are using real data every day. That is when you notice the report someone still builds by hand on a Friday, or the call notes nobody has time to write up.

Those are the improvements that pay back most, because they come from how the business actually runs rather than how anyone assumed it would.

We split every engagement into four stages, and each one exists for a reason.

In practice the retainer covers three kinds of work. The first is fixing problems quickly, so a bug does not turn into a workaround. The second is adding features as processes change. The third, and the one we care about most, is finding the next manual task to automate.

How we fix bugs matters as much as how fast. Client bugs are handled by AI coding agents working on a copy of the system filled with fake data, so nobody's real records are touched while the fix is made. The fix is recorded on video, and nothing goes live until Nathan has reviewed and approved it.

That gives us speed without asking anyone to trust a change they cannot see.

PreAction, a B2B debt mediation business, is a good example of why we work this way. We moved them off an outdated CRM onto a new database and custom software built around how they work. That was the start, not the finish.

We work inside PreAction day to day, alongside their employees, staff and shareholders, to understand how the business really runs. That is how we find the next thing to make faster and the next process to simplify. As their case study puts it, this is not something we built and walked away from, and we are nowhere near finished.

Because the work has not stopped, we expect those figures to keep climbing as we keep building.

Any supplier can give a good demo. Ask these before you sign, and listen for specific answers rather than reassurance.

If the answers are vague, that tells you what month seven will look like. Judge a supplier on how they work after launch, not on how the software looks on the day they show it to you.