How we work
Every engagement follows the same four phases, whether we are building software or taking over the operation of your platform. The structure is deliberate: it is how we can commit to SLAs and keep them.
Discovery & audit
We examine your systems as they actually are before we commit to anything.
We start with a structured audit of your architecture, codebase, infrastructure and operational practices. Senior engineers do this work directly — reading code, reviewing deployment pipelines, tracing how incidents are currently handled. We document what is stable, what is fragile and what we do not yet understand. If we conclude we are not the right partner for the problem, we say so at this stage.
What you get
- Written audit report covering architecture, code and operations
- Risk register with severity and likelihood per finding
- Current-state architecture map
- Prioritised list of remediation items, independent of any contract with us
Proposal & SLA design
We turn the audit into a scoped proposal with contractual commitments, not estimates.
Based on the audit, we define scope, responsibilities and commercial terms. For managed operations, this is where the SLA is designed: four severity levels (P1–P4), response and resolution targets per level, escalation paths and reporting cadence. We negotiate these numbers with you openly, because we will be contractually bound by them. Nothing in the proposal depends on information we have not verified ourselves.
What you get
- Fixed-scope proposal with commercial terms
- SLA matrix: P1–P4 severity definitions with response and resolution targets
- Responsibility matrix defining what we own and what stays with your team
- Transition plan with milestones and acceptance criteria
Build / Transition
We build the system, or take over the existing one, in controlled and reversible steps.
For development work, this phase is engineering: iterative delivery, code review on every change, CI/CD from the first week. For managed operations, it is a staged take-over: monitoring and alerting first, then on-call responsibility, then release management. Each step has an acceptance gate you sign off on. At no point during transition is your platform without a clearly named owner.
What you get
- Working software or a fully transitioned operational setup
- CI/CD pipelines and monitoring configured and documented
- Runbooks for deployment, incident response and rollback
- Handover documentation reviewed with your team
Run & improve
We operate the platform under the SLA and reduce its risk over time.
This is the phase most engagements live in for years. We monitor 24/7, answer incidents within the contractual targets, apply security updates and ship fixes and improvements on a steady cadence. Every month you receive a report showing SLA performance against the contract — including the months where we missed a target. Quarterly, we review the improvement roadmap with you and reprioritise based on what production has taught us.
What you get
- Monthly SLA report with incident log and performance against targets
- Post-incident reviews for every P1 and P2
- Quarterly improvement roadmap with effort estimates
- Continuously updated documentation and runbooks
What we expect from you
A managed IT services SLA is a two-sided contract. We can only meet our commitments if the collaboration meets a few conditions, and we prefer to state them before signing rather than discover them after.
A decision-maker in the loop
Someone on your side with the authority to approve scope, budgets and trade-offs, available for a scheduled call at least twice a month. Decisions parked for weeks become incidents later.
Access to systems and context
Repository access, infrastructure credentials under proper access control, and the people who know the system’s history. We cannot take responsibility for what we cannot see.
Honest constraints and budgets
Tell us the real budget, the real deadline and the real internal politics. We would rather design a smaller scope that holds than a large one that quietly fails.
Responsiveness on blocking questions
When we flag a question as blocking, we need an answer within an agreed timeframe — typically two business days. Our SLA clocks assume your side of the contract is also running.
Tools and reporting
You should never have to ask us what is happening on your platform; the tooling is set up so you can see it.
Monthly reporting pack
A written monthly report: SLA performance per severity level, incident summaries, work delivered, and risks we see coming. Designed to be forwarded to your management unedited.
Shared channels and tickets
A shared Slack or Teams channel for daily contact and a ticket system (yours or ours) as the single record of requests and incidents. Nothing important lives only in a conversation.
Documentation as a deliverable
Architecture notes, runbooks and decision records are maintained in your repositories, not ours. If the engagement ended tomorrow, your next team could pick up where we left off.
Let’s talk about your technical operations
A 30-minute introductory call with a senior engineer — no sales script, no obligation. We listen, we ask questions, and we tell you honestly whether we can help.