Managed Platform Operations or internal DevOps: when each model fits

A growing agency often reaches an uncomfortable point: development absorbs more operational work, but hiring a complete platform team still feels premature.

The decision is not simply hire or outsource DevOps. The agency needs to decide which capability it needs, with what continuity and which ownership it must retain.

When an internal hire fits

An internal profile usually makes sense when:

• stable operational work occupies most of their capacity;
• the platform is a central competitive advantage;
• the team can provide backup, review and professional development;
• there is budget for more than one person in the medium term;
• knowledge needs to sit inside the product every day.

Hiring one person without backup may only move the problem. Operations stop depending on a founder or developer and begin depending on the new DevOps engineer.

When an external capability fits

Managed Platform Operations may be appropriate when:

• workload exists but changes across projects and months;
• the agency needs experience across several layers without several hires;
• standardisation and stabilisation come before team building;
• the agency wants to offer maintenance to clients;
• an internal technical owner can retain context and decisions.

The model should not be an opaque bucket of hours. It needs systems in scope, responsibilities, backlog, reviews and clear contractual boundaries.

What the service should cover

A recurring scope may include:

• infrastructure as code maintenance;
• pipeline evolution;
• access and secret management;
• project onboarding;
• observability and agreed alert response;
• backups and recovery testing;
• cost reviews;
• documentation and runbooks;
• a quarterly roadmap.

It does not automatically include feature development, unlimited support or responsibility for application logic.

Comparing the models

Continuity

A properly sized internal team offers strong continuity. One internal profile does not. An operating partner should provide backup and procedures so the same dependency is not recreated.

Context

Internal teams accumulate context quickly. External operations need explicit routines: a shared backlog, recorded decisions, owners and reviews.

Time to start

An external capability can begin with an assessment and bounded scope. Hiring requires sourcing, selection and onboarding, but may be the better investment when the need is permanent and strategic.

Cost

Do not compare salary with a service fee alone. Include recruitment, vacancy time, management, tools, on-call backup and unused capacity.

Control

Control does not depend on the team being internal. It depends on repositories, accounts, documentation, access and decisions remaining with the client company.

Decision matrix: five questions that change the answer

There is no universal employee or revenue threshold. The decision improves when the current situation is scored using evidence:

Criterion	Signal for external capability	Signal for an internal team
Workload	Variable backlog or less than stable full-time demand	Stable work for several people
Context	Repeatable processes and clear boundaries	Platform is central to product differentiation
Urgency	Production must be stabilised in weeks	There is time to recruit and develop people
Specialities	Work alternates across CI/CD, cloud, Kubernetes, security and cost	One platform dominates and internal mentoring exists
Continuity	The provider documents backup and substitution	The company can build its own rotation and on-call model

The table does not make the decision. It makes assumptions visible. If an answer depends on “the person who knows”, there is not yet an operating capability; there is a dependency.

The contract should describe ownership, not activity

“Forty hours of DevOps” does not explain which system is covered, how an incident is prioritised or who accepts a change. An operating scope should be expressible in a form like this:

service:
  systems: [saas-production, pipelines, observability]
  provider_owns:
    - maintain infrastructure as code
    - review and execute approved changes
    - verify included backups and alerts
  client_owns:
    - application code and logic
    - product priorities
    - approval of high-risk changes
  coverage:
    window: "business days, agreed hours"
    on_call_24x7: false
  evidence:
    - backlog and change status
    - architecture decisions
    - operating-check results

The YAML is illustrative, not a legal template. The important test is whether a third party can distinguish obligation, collaboration and exclusion.

Compare cost without fooling yourself

A useful comparison separates four layers:

1. Direct capacity: salary or fee and hours actually available.
2. Backup capacity: review, substitution, holidays and non-routine response.
3. Coordination cost: product, development and leadership time spent prioritising and reviewing.
4. Residual risk: ownerless work, concentrated knowledge and uncovered windows.

An expensive external service is inefficient if it merely resells hours. A seemingly economical hire can be inefficient too if that person works alone, receives every interruption and never has time to automate. The useful unit is not price per hour; it is the cost of sustaining an operating responsibility at the required continuity level.

Minimum onboarding before production changes

Before execution begins, review:

• ownership of every account, repository and domain;
• inventory of environments and critical dependencies;
• current access and revocation process;
• actual backup and recovery status;
• channels, severities and authorised people;
• initial backlog and prioritisation criteria;
• exclusions, hours and escalation;
• documentation and evidence format.

If onboarding cannot be completed, the first service outcome should be to close those gaps. Jumping directly into a migration or “improving Kubernetes” often hides earlier risks.

Exit test: the criterion that protects the client

Before contracting, ask how the relationship can end. A healthy exit lets the client:

• revoke access without stopping production;
• retain repositories, automation and history;
• identify pending changes and accepted risks;
• transfer operations to an internal engineer or another provider;
• execute critical procedures without private conversations.

This test prevents Managed Platform Operations becoming a black box. It also requires the internal team to retain enough context to govern the service.

For delivery-performance research and measures, Google Cloud’s DORA programme provides a useful primary reference. Those measures still need to be interpreted inside the actual system; they do not replace ownership analysis or support universal promises.

A combined path

Both models can be stages in one plan:

1. diagnose and stabilise;
2. create a common delivery foundation;
3. operate externally during growth;
4. hire internally when workload justifies it;
5. transfer ownership or retain a hybrid model.

The useful question is not “should we outsource DevOps?” It is: which operational capability do we need over the next twelve months, and how do we prevent it depending on one person?

Answering it requires comparing actual workload, criticality, change frequency and coordination cost. The right model reduces risk without creating a new dependency.