Who this is for
Software does not stay finished. Libraries publish security fixes, operating systems and browsers change, app stores raise their requirements and certificates expire. This service is for organisations that want those changes handled steadily rather than in a rush when something breaks. It suits:
- Businesses whose website, web application or mobile app was built by a supplier who is no longer involved.
- Teams with a working system but no one with the time or skills to keep it patched and monitored.
- Organisations that have just launched something and want ongoing care from the start.
- Owners of older systems that still work but are running on unsupported versions and getting harder to change.
What maintenance covers
A maintenance plan is a written agreement about what we look after and how. Typically it covers:
- Security patches. We track security advisories for the components your system uses and apply fixes based on severity and exposure. Outdated and unsupported components are a well-known source of risk; the OWASP Top 10:2025 lists Software Supply Chain Failures as A03, a category that includes software that is vulnerable, unsupported or out of date.
- Dependency updates. Beyond urgent security fixes, we keep libraries and frameworks reasonably current in small, tested steps. Small regular updates are far less disruptive than one large upgrade after years of neglect.
- Monitoring. Uptime, errors, performance and resource usage are watched, with alerts going to the right people. Logs are kept long enough to investigate problems.
- Backups. Data is backed up on a schedule, stored separately from the live system, and restores are tested. A backup that has never been restored is an assumption, not a safeguard.
- Small enhancements. Minor changes, content updates and small improvements are handled within the plan, so the system keeps up with how your organisation works.
- Health reporting. We report periodically on what was done, what risks remain and what we recommend next, so you can plan budgets for larger work.
How we take over an existing system
Handing over a system you did not build yourself can feel risky. We make it structured:
- Gather access and information. Code repositories, hosting accounts, domains, third-party services, any existing documentation and contact with the previous supplier if possible.
- Assess the current state. We review the code, dependencies, hosting configuration, backups, security settings and known issues. You receive a written summary of findings, ranked by risk.
- Secure the basics. Before anything else, we confirm backups work, rotate shared or former-supplier credentials, and set up monitoring.
- Reproduce the build. We make sure the system can be built and deployed from source in a repeatable way. If it cannot, that becomes a priority.
- Agree the plan. Based on the assessment, we agree what ongoing maintenance covers and which one-off fixes are needed first.
- Document as we go. Each thing we learn about the system is written into a runbook that stays with you.
Decisions we help you make
- Upgrade or replace. When a system is far behind on versions, we help you compare the cost and risk of upgrading in place against rebuilding parts of it.
- What level of coverage you need. Not every system needs the same attention. We help you match monitoring and response arrangements to how critical each system is.
- When to retire something. Old features, unused integrations and forgotten admin pages still need patching and still widen the attack surface. We help you identify what can be switched off safely, archive its data where needed and remove it, which often makes the rest of the system cheaper and simpler to maintain.
- Hosting and cost. Maintenance often reveals unused resources or hosting that no longer fits. We point these out with the trade-offs.
- What to log and keep. Logs help investigate incidents but can contain personal data. We help you balance the two and be aware of legal requirements. For example, the CERT-In directions of 28 April 2022 require covered entities in India to keep logs of their ICT systems for a rolling period of 180 days within Indian jurisdiction, to report specified incidents within six hours of noticing them, and to synchronise system clocks with the NTP servers of NIC or NPL, or with servers traceable to them.
Security and quality built in
- Changes are tested before release. Updates go to a test or staging environment first where one exists, and we recommend setting one up where it does not.
- Every change is recorded. Version control, a change log and the ability to roll back are standard practice in how we work.
- Least privilege. Access is limited to what each person or service needs, and reviewed when people or suppliers change.
- Secrets are handled properly. Passwords and keys live in a secrets store or the platform’s secure configuration, not in code or shared documents.
- Incidents are learnt from. After a significant problem we write up what happened, the cause and what has been changed to prevent a repeat.
What we need from you to start
- A list of the systems you want covered and what each is used for.
- Access to code repositories, hosting, domains and connected services, or a plan for obtaining it.
- Any existing documentation, however incomplete, and contact details for the previous supplier if available.
- Known problems, upcoming deadlines and any changes you already know you will need.
- Your expectations for coverage hours and how critical each system is to your operations.
- A named contact on your side who can approve changes and be reached when something urgent comes up.
With that in hand, we begin with the onboarding assessment and share what we find before agreeing the ongoing plan.