Service
Launch is the beginning of the system's useful life.
Kerah can support the maintenance, release and continued improvement of live systems through an operating model defined for the engagement.
Who this is for
- Organizations whose system is live and whose roadmap has stopped
- Teams that inherited a system built by someone who is no longer available
- Organizations needing security maintenance they cannot staff internally
- Leaders who want improvement capacity, not only incident cover
The problems this addresses
- The delivery team has moved on and nobody owns the system's future
- Dependency and security updates have been queuing since launch
- Improvement requests accumulate with no route to a decision
- Nobody is confident a release can be reversed if it goes wrong
- Documentation has drifted far enough that changes feel risky
What changes
- Issues have a route, an owner and a recorded resolution
- Releases are predictable and reversible
- Security and dependency updates happen on a cadence rather than after an incident
- A prioritised backlog exists, and part of each month goes to advancing it
- Documentation is maintained alongside the system rather than after it
What Kerah can deliver
Capability, not a claim of past work. Final scope is established through discovery.
- Support and incident workflow
- Monitoring and operational visibility
- Dependency and security maintenance
- Release management
- Backlog ownership and prioritization
- Improvement capacity alongside support
- Roadmap reviews
- System-takeover assessment
- Documentation recovery
What you receive
Artefacts, not activities. Each one is something you can hold, read or run after the engagement.
- A defined support and escalation workflow
- Release calendar and rollback procedure
- Monitoring and alerting configuration
- Maintained dependency and vulnerability position
- Prioritised backlog reviewed with you
- Operational reporting on availability, incidents and changes
- Maintained system documentation
How the engagement runs
- Improvement is part of the arrangement
- A defined share of each month goes to advancing the system, not only to absorbing incidents. Support that only reacts lets a system decay on schedule.
- Assessment before takeover
- Kerah assesses a system it did not build before agreeing to support it. Sometimes the assessment concludes Kerah is not the right choice, and that is the answer you get.
- Documentation as you go
- Where documentation has drifted, recovering it is treated as work with a deliverable, not as something to be done eventually.
Commercial shape. A monthly arrangement with agreed support and improvement capacity, defined for the specific system.
Raised from the start, not before launch
Architecture, security and data decisions that are cheap to make early and expensive to retrofit.
How Kerah approaches security- What the organization can operate itself, and what genuinely needs external support
- Which failures matter enough to alert on, and who responds
- How access is granted, reviewed and revoked over a long engagement
- Where knowledge concentrates, and how that risk is reduced
- How the arrangement ends cleanly if it needs to
Where this stops
- Kerah does not publish support hours, severity definitions, response times, coverage windows, uptime targets or service-level commitments on this website. Those are agreed per engagement against real operating capacity.
- Kerah does not present itself as an around-the-clock managed service operation.
- The environment stays under the organization's own accounts and contracts. Kerah maintains and improves the software; it does not take over the hosting.
- Support for a system Kerah did not build begins with a paid assessment, and may conclude that another arrangement is more appropriate.
Other services
Discovery and Architecture
A documented blueprint with a target architecture, a permission and data-role map, a phased roadmap and a scope you can approve, price or decline on evidence.
Enterprise Systems
One operational system where work is assigned, decisions are recorded, permissions are explicit and reporting comes from the same data people work in.
Digital Product Engineering
A designed, accessible product with a secure back end, built around the tasks people actually perform and measured after release.
Cloud, Data and Integrations
Defined interfaces, a documented data model and monitored flows, so information moves once and reporting can be trusted.
AI and Intelligent Automation
A bounded use case with defined success criteria, evaluation against representative cases, human review where it matters, and a fallback when the model is unavailable.
Security and Privacy Engineering
A system whose access model, data inventory, encryption, logging and deletion behaviour were designed together — and the documentation an assessor asks for, produced as delivery output rather than reconstructed afterwards.
Quality, Testing and Accessibility
A system tested in both languages by people who read both, measured against WCAG 2.2 AA, and exercised under realistic load and failure conditions before launch rather than after it.
Discuss ongoing support.
Tell us what is not working today, who it affects and what a better outcome would change.