Software support and maintenance
Software is not finished when it goes live. It needs fixes, changes as the business changes, and somebody who answers when it breaks. We support what we build, and we take on systems built by developers who are no longer available — which is a more common situation than anybody admits.
Is this you?
- The developer who built your system has stopped replying.
- Nobody knows how to change anything, so nothing changes.
- There is no documentation and no handover was ever done.
- Something breaks and there is no defined way to get it fixed.
- You are still running a system that has not been updated in four years.
What we build
- Annual maintenance contracts with defined response times
- Bug fixes, enhancements and change requests within an agreed envelope
- Taking over systems built by others, starting with a technical audit
- Security patching, dependency updates and version upgrades
- Server monitoring, backups and tested restore procedures
- Performance work when a system has slowed under real data volumes
- Documentation written for the system you already have
- A named contact, rather than a ticket queue nobody owns
Businesses with software they depend on and nobody to look after it — whether we built it or not.
- A written scope you approve before any code is written
- A price agreed against that scope, not discovered later
- Source code, database, documentation and IP yours on final payment
- Training for your team, and close support through the first month
Questions people ask about this
Can you take over software somebody else built?
Often, yes, and it is a more common request than anybody admits. We start with a technical audit: what it is built on, what state the code is in, what is missing, and what it would cost to keep it running versus rebuild it. You own the findings whether or not you continue with us.
Sometimes the honest conclusion is that the system should be replaced. We will say that plainly, and we will also say when it should not be.
Who owns the source code?
You do, on final payment. Source code, database, documentation and intellectual property in the work are assigned to you in the contract. There is no licence that expires and no situation in year three where you discover the software is not yours.
We also hand over in a usable state: documented, commented, and written so another developer can pick it up.
How do you stop our staff from going back to Excel?
By building it around what they already do, and by talking to them during the scope stage rather than only to the person signing the cheque. Most systems are rejected because they add work for the people entering the data while the benefit lands somewhere else.
Practically: fewer screens, fewer mandatory fields, capture what can be captured automatically, and make the daily task faster than the spreadsheet it replaces. Then train in small groups and stay close for the first month, which is when the real questions arrive.
Tell us what isn’t working
A first conversation costs nothing and commits you to nothing. Bring the problem — the mess of spreadsheets, the report nobody can produce, the process that breaks every month-end. We will tell you honestly whether custom software is the answer, and roughly what it would take. Sometimes the answer is that you do not need us. We will say so.