0.4
System operations
What we do
We operate the systems the business runs on after delivery: availability, support, performance and evolution, with explicit accountability for the service and not only for the code.
We take on both our own platforms and ones inherited from third parties, and the team that answers an incident is the team that knows the architecture. There is no handover to a second line that starts from zero.
How we approach it
We operate on what the system says about itself: instrumentation, alerts with agreed thresholds and a live inventory of critical dependencies. An incident closes when the root cause is fixed, not when the service comes back.
Change always takes the same path: version control, an equivalent environment, a reversible deployment and a window agreed with the business. Continuity is not protected with exceptions; it is protected by a process that repeats identically every time.
Value we create
Measurable operational continuity, with committed response and recovery times and an incident history that gets shorter instead of repeating.
Beyond that, the cost of sustaining the system stops growing with its age: optimisation and debt reduction are part of ordinary operation, not of an extraordinary project that keeps getting postponed.
Post-delivery operation and critical support
- What it is
- Ongoing accountability for systems in production: monitoring, incident response, service restoration and correction of the cause behind it.
- How we understand it
- Delivery is where risk begins, not where it ends. When a critical system fails it needs someone who knows its architecture, with the authority to decide and the access to change the code.
- What it solves
- Support that only restarts and escalates, recurring incidents with no cause fixed, knowledge concentrated in one person, and recovery times nobody has committed to.
- Value it creates
- Service with agreed and measured levels, a falling rate of repeat incidents, and continuity that does not depend on one person being available.
Continuous platform optimization
- What it is
- Systematic review of performance, cost and reliability across platforms in production, with work prioritised by its impact on the operation and on spend.
- How we understand it
- A stable system still degrades: data grows, usage patterns change, and the infrastructure was sized for a different scenario. Without periodic review, cost rises and headroom falls.
- What it solves
- Cloud spend growing without explanation, response times deteriorating slowly, and capacity oversized in some places and at its limit in others.
- Value it creates
- Cost aligned with real usage, performance sustained under growth, and capacity decisions made on data rather than out of caution.
Evolution of systems in production
- What it is
- Adding new capabilities, regulatory changes and integrations to systems that are already running, without stopping the service or rebuilding the platform.
- How we understand it
- Evolving in production is an exercise in sequencing and reversibility: small, verifiable, reversible changes, with old and new coexisting for a while when the risk calls for it.
- What it solves
- Changes bundled into large, risky releases, technical debt that makes every modification more expensive, and the recurring temptation to rewrite from scratch.
- Value it creates
- Continuous, predictable capacity for change, with risk contained per release and no downtime windows the operation cannot absorb.