Keeping systems patched, monitored and understood after launch — with a named route to a person who knows how yours is built.
Software does not stop needing attention when it goes live. Dependencies acquire known vulnerabilities, certificates expire, data volumes grow past the point the original queries were designed for, and the person who understood the deployment moves on. Support is the work that keeps a system from quietly degrading into something nobody wants to touch. Response times, availability targets and escalation routes are agreed for each engagement and written into the support agreement, because they depend on what the system does and what it costs you when it stops — we do not publish numbers here that would be meaningless applied to yours.
Each service page sets out the problem it addresses, how we approach it, the process, and what you receive at the end.
Scheduled work that stops small problems becoming outages
Ongoing patching, dependency updates, certificate and backup verification, and performance monitoring, carried out on an agreed cadence with a record of what changed.
Finding the actual cause, not the nearest plausible one
Diagnostic work on systems that are failing, slow or behaving inconsistently — including systems we did not build and problems that have already defeated one attempt at a fix.
A standing arrangement with people who know your system
An ongoing agreement covering monitoring, incident response, user support and a share of continuous improvement, with named engineers and an escalation route agreed in advance.
The sectors these services are most often bought in. Knowing the vocabulary saves a week at the start; it does not tell us how your organisation works, and it is not an accreditation.
Public-facing sites, storefronts and browser-based applications built to be fast, findable and maintainable by people other than us.
Applications, platforms and integrations built for organisations whose process no longer fits anything they can buy off the shelf.
Native and cross-platform applications for phones and tablets, built for the conditions that only appear away from a desk — poor signal, a four-year-old device, and an app store sitting between you and your users.
Research, flows, screens and component libraries produced against real content and real constraints, so that what is designed is what can actually be built.
Cloud environments, deployment pipelines, hosting and monitoring set up so that a release is boring, a restore has been tested, and somebody knows when it breaks.
Advisory work that ends in a decision you can act on — a costed plan, an architecture you can build against, or a prioritised list of what to fix first.
The project brief takes about five minutes and gives us enough to have a useful first conversation rather than a generic one. If you would rather just ask a question, the short form is there for that.
We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.