Pick the commercial model that matches the risk

Assistance work is packaged as dedicated people, hourly packages, evidence-led audits, fixed-scope implementation projects, retained engineering capacity, managed operations, or emergency response.

The right model depends on urgency, uncertainty, delivery ownership, and how much ongoing operating responsibility you want Assistance to carry.

Compare service catalog View pricing plans

Service playbook

From problem to operating evidence

Main content is structured like a case study: context first, scoped work next, then the operating changes and evidence a team can use after handoff.

Service briefModel at a glanceBuying signalsDiscovery and onboarding across modelsAudits and assessments

Assistance services are designed around how infrastructure work is actually bought. Some buyers need dedicated people who build continuity with their systems. Some need a package of hours for a defined backlog before committing to a retainer. Others need a fixed implementation with acceptance criteria or a short evidence review before budget approval. Production teams often need retained senior capacity or a managed operation that keeps improving month after month. When production is actively failing, emergency response is the right entry point.

This page helps buyers choose the smallest commercial model that can responsibly carry the risk. The goal is not to upsell every situation into a large retainer. If an audit, short project, or emergency stabilization is the right first step, we say so.

Case-study lens

Scoped

Problem, responsibility, and handoff boundaries before implementation.

Evidence

Dashboards, runbooks, reviews, and operating records over borrowed logos.

Outcomes

Conservative summaries focused on observable operational improvement.

EvidenceSection 01

Model at a glance

Runbooks, dashboards, reviews, and handoff material make the work auditable.

Engagement model	Use when	Typical duration	Commercial shape	Best first pages
Audit or assessment	The problem is unclear or leadership needs evidence before committing spend	Days to weeks	Fixed scope	Infrastructure Audit, Security Audit, CI/CD Audit
Architecture review	A major build, buy, migrate, or simplify decision needs technical trade-offs	Days to weeks	Fixed scope or advisory package	Technology Consulting, Infrastructure Audit
Hourly package	A defined backlog needs senior engineering time without a full monthly operating commitment	Days to weeks	Scoped block of hours	Pricing, DevOps as a Service, Technology Consulting
Implementation project	The outcome is known and acceptance criteria can be defined	Weeks to months	Fixed scope, per-project, or milestone-based	Cloud Infrastructure, Managed Kubernetes, GitOps
Modernization project	Existing systems need a planned migration, platform change, cost improvement, or resilience upgrade	Weeks to months	Scoped project with migration plan	Cloud Migration, Kubernetes Migration, AWS Graviton Migration, Cost Optimization
Retained engineering	Your team needs dedicated people and continuous senior capacity without another hiring cycle	Monthly	XS, S, M, or custom plan	DevOps as a Service, SRE as a Service, DevSecOps as a Service
Managed operation	Assistance should operate a platform component or cloud surface with review cadence	Monthly or custom	Managed service or retained plan	Managed Kubernetes, Cloud Account Management, Managed Runners
Emergency response	Production is down, degraded, or at high immediate risk	Hours to days plus follow-up	Emergency terms and remediation scope	Emergency Response

Operating modelSection 02

Buying signals

Responsibilities, response paths, and technical changes are made explicit before work starts.

Signal	Usually start with	Why
"We know something is wrong, but cannot prove what matters first"	Audit or assessment	Evidence reduces guesswork and creates a defensible roadmap
"We have a board, customer, or compliance deadline"	Audit, architecture review, or remediation project	The deliverable needs to be decision-ready and evidence-backed
"We have a backlog but not a monthly support need yet"	Hourly package	The work can be prioritized into a bounded package of senior time
"We know exactly what needs to be built"	Per-project implementation	Acceptance criteria and dependencies can be defined up front
"This problem repeats every month"	Dedicated people, retained engineering, or managed operation	Recurring work needs cadence, backlog, continuity, and operating ownership
"Our team wants the platform but not the operations burden"	Managed operation	Assistance carries an agreed operating surface with escalation and review
"Production is actively degraded"	Emergency response	Stabilization comes before roadmap or commercial optimization

OutcomeSection 03

Discovery and onboarding across models

Expected changes are framed as practical operating improvements, not unsupported guarantees.

Every model starts by making scope explicit. The depth changes by engagement type, but the core questions are consistent:

Buyer goal — what decision, risk reduction, delivery outcome, or operating responsibility must this engagement support?
Technical surface — which repositories, cloud accounts, clusters, runners, pipelines, services, vendors, and environments are in scope?
Access and authority — who can grant access, approve changes, accept risk, merge work, and authorize production action?
Constraints — deadlines, change freezes, compliance obligations, customer commitments, budget limits, and maintenance windows.
Evidence needed — executive summary, technical report, pull requests, diagrams, runbooks, dashboards, incident notes, or audit-ready artifacts.
Handoff path — who owns the result after the engagement and what follow-up model is appropriate if work continues?

EvidenceSection 04

Audits and assessments

Reliability signals are treated as decision evidence, not dashboards for their own sake.

Use an audit when the buyer question is, "What should we fix first?" Audits are evidence-led, time-boxed, and designed to create a shared roadmap for leadership and engineering.

Assessment step

Good fit

infrastructure has grown faster than documentation or ownership
cloud spend, reliability, delivery, or security risk is visible but not prioritized
a board, customer, or leadership team needs credible next steps
the team is choosing between DevOps, SRE, cloud, Kubernetes, or security work
implementation budget depends on findings and sequencing

Assessment step

Operating model

Audits are mostly read-only. We collect evidence, interview stakeholders, inspect configuration, and produce findings. We flag urgent risks as they appear, but implementation is not assumed unless the scope includes a remediation sprint.

Assessment step

Deliverables

scope statement and access plan
current-state notes, diagrams, inventories, or system maps
findings with evidence, risk, impact, effort, and owner recommendations
executive summary for leadership
technical roadmap for engineering
recommended next service path

Assessment step

Boundaries

Audits do not guarantee remediation, cost reduction, compliance certification, or uptime improvements by themselves. They create the evidence and sequence for the next decision.

Operating modelSection 05

Architecture review and decision support

Responsibilities, response paths, and technical changes are made explicit before work starts.

Architecture reviews are for decisions with consequences: SaaS tenancy, internal platform design, commerce reliability, cloud foundations, Kubernetes adoption, managed service selection, compliance-readiness, or cost governance.

Assessment step

Good fit

build vs. buy decisions are blocking implementation
multiple teams disagree about the target platform
a migration or modernization path needs sequencing before funding
leadership needs trade-offs instead of a generic best-practice list
the wrong decision would create long-term operational cost

Assessment step

Operating model

Architecture reviews combine technical inspection with decision facilitation. The output is not just a diagram; it explains options, constraints, trade-offs, risks, and a recommended path that can become implementation scope.

Assessment step

Deliverables

decision brief with options, trade-offs, constraints, and recommendation
risk register and dependency map
operating model and ownership notes
implementation sequence with milestones
follow-up scope for audit, project, or retainer work

OutcomeSection 06

Hourly packages

Expected changes are framed as practical operating improvements, not unsupported guarantees.

Use an hourly package when the backlog is defined but the operating need is not yet recurring enough for a monthly retainer. A package should have priorities, target systems, expected outputs, and a reporting cadence before work begins.

What changes

Good fit

a short remediation backlog from an audit
senior review and implementation help for a bounded topic
advisory sessions with written follow-up actions
transition work before deciding whether XS, S, M, or custom support is needed

What changes

Boundaries

Hourly packages are not unlimited availability or incident ownership. If the same work repeats every month, or if you need named people to carry operational context, move to retained engineering, managed operations, or custom dedicated capacity.

EvidenceSection 07

Implementation projects

Runbooks, dashboards, reviews, and handoff material make the work auditable.

Use per-project work when the desired outcome is specific enough to define acceptance criteria. Projects are scoped around a target state, not open-ended advisory time.

Implementation focus

Good fit

build a cloud landing zone
migrate workloads to Kubernetes or another cloud
introduce GitOps or infrastructure as code
implement CI/CD, runners, observability, or security controls
package SaaS deployment or marketplace provisioning automation

Operating step

Operating model

Projects run through a delivery plan: milestones, dependencies, access, acceptance criteria, validation, rollout, and handoff. Work is usually delivered through pull requests, infrastructure changes, configuration updates, diagrams, and runbooks.

Implementation focus

Deliverables

delivery plan with milestones, dependencies, and acceptance criteria
pull requests, configuration changes, infrastructure code, or deployment automation
rollout, cutover, rollback, and validation notes where relevant
diagrams, runbooks, and operating handoff
final review with remaining backlog and managed-operation recommendation if needed

Implementation focus

Boundaries

A project is not unlimited engineering capacity. If the target changes materially, the scope is re-estimated. If the result needs recurring operations after launch, a retained service or managed operation is a better fit.

Operating modelSection 08

Modernization projects

Responsibilities, response paths, and technical changes are made explicit before work starts.

Modernization is a project path for teams replacing an operating bottleneck: outdated hosting, unmanaged cloud accounts, manual deployments, fragile Kubernetes, high-cost compute, weak disaster recovery, or unsupported delivery platforms.

Modernization goal	Typical path
Move workloads between environments	Cloud Migration or VMware Migration
Make Kubernetes usable	Kubernetes Migration, Managed Kubernetes, and GitOps
Reduce compute or cloud waste	Cost Optimization, FinOps, or AWS Graviton Migration
Improve release safety	CI/CD Audit followed by DevOps as a Service
Improve recovery readiness	Disaster Recovery Planning and SRE as a Service

Assessment step

Discovery focus

Modernization needs more discovery than a small implementation project because sequencing matters. We review dependencies, data movement, downtime tolerance, rollback, ownership, cost model, security controls, and what must remain unchanged during transition.

OutcomeSection 09

Retained services

Expected changes are framed as practical operating improvements, not unsupported guarantees.

Use a retainer when your team needs dedicated people, ongoing senior capacity, and continuity. Retainers work best when the backlog changes over time but the operating surface is stable enough to review monthly.

What changes

Good fit

you need platform help but cannot justify a full-time platform team yet
reliability, delivery, security, AI, or data work needs regular ownership
the team wants predictable access to senior engineers
you need a monthly review cadence and visible backlog, not one-off tickets
context continuity matters more than a one-time project deliverable

Operating step

Operating model

A retainer has a defined scope, communication channel, backlog, review cadence, and escalation path. Assistance can advise, implement, review, or triage depending on the plan boundary. Your team still owns business priorities, product decisions, and acceptance of production risk unless those responsibilities are explicitly scoped.

What changes

Ongoing cadence

Cadence	Activity
Onboarding	scope, access, backlog seed, communication path, and reporting format
Weekly or biweekly	active work review, blocked decisions, pull requests, upcoming changes
Monthly	plan review, completed work, risks, backlog changes, cost or reliability notes
Incident-driven	triage and handoff inside the scoped service boundary
Quarterly where useful	plan sizing, strategic roadmap, and whether a project or managed operation is now better

What changes

Deliverables

onboarding checklist and operating scope
monthly backlog and priority review
delivery work through pull requests, configuration changes, or documentation
incident, reliability, security, cost, or delivery review notes depending on plan
handoff material and evidence suitable for engineering leadership

EvidenceSection 10

Managed operations

Runbooks, dashboards, reviews, and handoff material make the work auditable.

Managed operations are for surfaces where Assistance carries an agreed operating responsibility. The exact boundary depends on the service: Kubernetes clusters, cloud accounts, delivery platforms, runners, managed infrastructure components, or AI/data platform operations.

Engagement option

Good fit

the platform is business-critical but not a core differentiator for your team
operations need predictable reviews, upgrades, access controls, and incident playbooks
your engineers need a service they can consume instead of a platform they must own alone
recurring maintenance, patching, monitoring, and escalation are more important than advisory time

Operating step

Operating model

Managed operations require a responsibility matrix. We define what Assistance monitors, changes, patches, reviews, and escalates; what your team approves; and what remains outside the managed boundary.

Engagement option

Deliverables

responsibility matrix and escalation path
access, change, backup, upgrade, and monitoring rules
runbooks and operating evidence
monthly service review where appropriate
improvement backlog and risk register

Operating example

Example managed surfaces

Managed Kubernetes for cluster operations, upgrades, platform hygiene, and GitOps alignment
Cloud Account Management for billing, IAM, account governance, security hygiene, and monthly optimization
Managed Self-Hosted Runners for runner provisioning, hardening, scaling, monitoring, and support

Operating modelSection 11

Emergency response

The section clarifies how production responsibilities change once the service is in place.

Emergency response is for active production risk. It is not a substitute for steady operations, but it can stabilize the system and create a remediation path.

Operating step

Good fit

customer-facing production is down or severely degraded
rollback, failover, capacity, or infrastructure behavior is unclear
the team needs external senior help during a live incident
a security, delivery, cloud, Kubernetes, or reliability issue is creating immediate business risk

Operating step

Operating model

Emergency work starts with triage, stabilization, and communication structure. The scope is intentionally narrow at first: reduce customer impact, understand the safest next action, and avoid making the incident worse. Follow-up remediation is scoped separately after the system is stable.

Operating step

Deliverables

immediate triage and stabilization support
communication structure and action log
root-cause analysis or incident report when feasible
remediation plan and follow-up service recommendation

Operating step

Boundaries

Emergency response cannot replace missing backups, unsupported architecture, absent observability, or unclear ownership in the moment. We help stabilize and create the next responsible plan, but broad modernization or managed operations require follow-up scope.

OutcomeSection 12

Prerequisites by model

Expected changes are framed as practical operating improvements, not unsupported guarantees.

Model	Buyer prerequisites
Audit or assessment	Access to evidence, stakeholder availability, decision owner, and target questions
Architecture review	Known decision deadline, constraints, options under consideration, and technical sponsor
Implementation project	Acceptance criteria, access, approvers, dependencies, and validation environment
Modernization project	Migration constraints, downtime tolerance, rollback expectations, dependency map, and business owner
Retained engineering	Monthly budget, backlog owner, communication cadence, and scope boundary
Managed operation	Responsibility matrix, escalation path, access model, monitoring expectations, and change authority
Emergency response	Incident contact, authority to inspect or act, communication channel, and immediate risk context

EvidenceSection 13

Escalation and handoff

Runbooks, dashboards, reviews, and handoff material make the work auditable.

Every model needs a handoff path. For audits, handoff is a roadmap and next-scope recommendation. For projects, it is validation evidence, runbooks, diagrams, and remaining backlog. For retainers and managed operations, it is the recurring review and escalation path. For emergency response, it is an action log, immediate remediation notes, and a follow-up recommendation.

Escalations are handled according to the model boundary. If retained DevOps uncovers a reliability incident, we may route to SRE as a Service or Emergency Response. If a managed runner engagement reveals broad pipeline design problems, we may recommend a CI/CD Audit or DevOps as a Service. If an audit uncovers active exposure, we flag it immediately and agree on containment.

Operating modelSection 14

Choosing between models

Responsibilities, response paths, and technical changes are made explicit before work starts.

If this is true	Choose
You cannot yet describe the target fix	Audit or architecture review
You have a bounded backlog but not a monthly operating need	Hourly package
You know the target and can define acceptance criteria	Per-project implementation or modernization project
The need will repeat every month	Dedicated people, retained service, or managed operation
You need Assistance to own an operating surface	Managed operation
Customers are currently impacted	Emergency response first, then remediation
The scope is half advisory and half delivery	Start with an assessment or short project, then convert to retainer if the pattern repeats
The work needs a formal SLA	Custom managed operation or retained plan with explicit responsibility boundaries

Next stepSection 15

Decision points and common questions are made explicit so follow-up work is scoped cleanly.

Start with Service Catalog if you want the full service list.
Use Pricing to compare dedicated people, hourly packages, per-project work, XS, S, M, and custom plans.
Use DevOps as a Service for ongoing delivery and platform capacity.
Use CI/CD Audit when pipeline performance, reliability, or security needs evidence first.
Use Managed Self-Hosted Runners when runner performance, cost, and operations are the main surface.
Use SRE as a Service when production reliability, incidents, observability, or SLO practice are the main surface.
Use DevSecOps as a Service when security findings need ongoing implementation.
Use Cloud Account Management when cloud governance, billing, IAM, and hygiene need recurring ownership.

Not sure which model fits? Start with a service assessment. We will recommend the smallest engagement that creates useful evidence or progress.

Book a service assessment →

Talk to a senior engineer

Need a clearer path for Engagement Models?

We'll help you understand fit, scope, pricing, and the fastest practical next step for your team.

Book a quote review

No obligation • Senior engineer review • Recommendations grounded in your current stack

Pick the commercial model that matches the risk

From problem to operating evidence

Model at a glance

Buying signals

Discovery and onboarding across models

Audits and assessments

Good fit

Operating model

Deliverables

Boundaries

Architecture review and decision support

Good fit

Operating model

Deliverables

Hourly packages

Good fit

Boundaries

Implementation projects

Good fit

Operating model

Deliverables

Boundaries

Modernization projects

Discovery focus

Retained services

Good fit

Operating model

Ongoing cadence

Deliverables

Managed operations

Good fit

Operating model

Deliverables

Example managed surfaces

Emergency response

Good fit

Operating model

Deliverables

Boundaries

Prerequisites by model

Escalation and handoff

Choosing between models

Related buyer paths

Need a clearer path for Engagement Models?