Challenge
Platform and DevOps engineers are hard to hire: a search can take months, and a new hire still needs time to learn your platform. Meanwhile, keeping the platform running comes first, so the backlog of platform work slips from sprint to sprint until an end-of-support date, an audit, or an outage forces it to the top. AI-assisted security research has also increased the rate at which CVEs are being disclosed, so patches that could once wait for the next maintenance window now need to go out much sooner.
Cloud and infrastructure
Landing zones, VPCs, IAM, and private networking on AWS, Azure, Google Cloud, or your own data centre, defined as code in tools such as Terraform or Pulumi.
Kubernetes and containers
Cluster builds and upgrades on EKS, AKS, or GKE, Helm charts, GitOps with Argo CD or Flux, and autoscaling with tools such as Karpenter.
Pipelines and observability
CI / CD in GitHub Actions, GitLab CI, or Jenkins, self-service portals such as Backstage, and monitoring with Prometheus, Grafana, and OpenTelemetry.
Security and patching
Patching new CVEs in container images, nodes, and dependencies, policy as code, secrets management, and the fixes from your last penetration test.
Approach
Our engineers join your team and work through the platform and ops tickets you give them, from your own backlog. They use your ticketing system, repositories, and change process, and join your stand-ups, so their work goes through the same reviews as anything your team ships. You set the priorities and can change them each sprint.
We have built and run production cloud and Kubernetes platforms since 2015, on public cloud and on premises. Each engineer has the rest of our team behind them, so they can draw on what we have seen on other platforms.
You can bring in one engineer, or a team for a defined project:
01
One engineer in your team
One of our senior engineers joins your team and takes day-to-day direction from your engineering manager, like anyone else on the team.
Best for: a backlog that has outgrown your team, or a skill your team does not have yet
Timeline: about two weeks, mostly spent waiting for access
02
A project team
Two to five of our engineers, led by one of our project managers, deliver a scoped piece of work such as a new platform or a migration, working alongside your team.
Best for: work with a clear deliverable and end date
Timeline: four to six weeks to put the team together
- 11+ Years
- running production container platforms
- 2 weeks
- to start on your tickets
- 1 hour
- Intro call
What are embedded platform engineers?
Embedded platform engineers are engineers from an outside firm who work as part of your own team, on your priorities, while the firm takes care of hiring and employing them. Here is how that compares with the alternatives:
| Our engineers | A permanent hire | A contractor | Managed services | |
|---|---|---|---|---|
| Time to start | About two weeks | Months of searching, then onboarding | As long as it takes to find one | Once the supplier has taken on your platform |
| Who sets the priorities | You | You | You | The supplier, against a service level agreement |
| Who finds and manages them | We do | You do | You do | The supplier |
| On-call cover | No | If you need it | If agreed | Usually included |
| Commitment | Billed monthly | A permanent salary | The length of the contract | A service contract |
When is augmentation a better fit than hiring?
Augmentation fits best in situations like these:
A defined platform push
Epics that were agreed long ago but never started, such as moving the last services onto your standard pipeline template, migrating secrets into a secrets manager, or decommissioning an old cluster.
Well-defined, repetitive work
Rebuilding images to pick up CVE fixes, bumping Helm charts across every cluster, importing hand-built resources into Terraform, or tagging cloud resources by team. Your team knows how, but it stays in the backlog until something makes it urgent.
Technical debt
The workaround someone put in to hit a deadline and promised to fix later: a hard-coded value, a manual step in every release, a version pinned because upgrading broke something, or a script that only runs on one engineer's laptop. Each is small, but together they slow every change your team makes.
Covering a hire
The headcount is approved and the search has started, but the platform work cannot wait. Our engineers do it in the meantime, write runbooks for anything they set up, and pair with your new engineer as they learn the platform.
A skill you need now and then
Most teams need someone who has done a Kubernetes version upgrade, a VPC redesign, or a FinOps review only a few times a year. Paying for those skills full time rarely makes sense.
Uncertain demand or one-off budget
If you are not sure the platform work will justify a permanent salary for years, augmentation lets you find out before you commit. Money left in this year's budget cannot fund a salary either, but an engineer can start within about two weeks, so the work begins, and is invoiced, before your financial year closes.
When to hire instead
Augmentation is a poor fit when the need is permanent and well understood, when the role has to own your platform’s architecture or sit on your on-call rota, or when your compliance rules limit production access to your full-time employees. In those cases, make the hire, and treat augmentation as a way to cover the gap until they start.
Engineers in Your Team FAQ
Sam Patel, Platform Engineering Manager
Is this a managed support service?
LiveWyer
No, our engineers work on your backlog
We do not run an on-call rota or commit to response times. Our engineers work on the tickets you prioritise, as part of your team.
Laura Bennett, Head of Infrastructure
What do you need from us to start?
LiveWyer
Access and a first set of tickets
We agree the first tickets with you after the intro call. Our engineers get least-privilege access to what those tickets need, through your usual joiner process, which usually takes about two weeks. Every change they make goes through your own reviews. If you would rather they learn the platform first, we can start with a review of it.
Emma Hughes, Director of Engineering
How do we buy it?
LiveWyer
Through a statement of work or G-Cloud
We bill monthly, agreed through a statement of work. Public bodies can also buy through G-Cloud 15 and Digital Outcomes and Specialists 7.
Owen Davies, Head of Platform
LiveWyer is already one of our suppliers. Does that make it quicker?
LiveWyer
Yes, there is no new supplier to set up
If we work on your platform now, adding engineers extends your current contract, and they start with what our team already knows about your setup. If we are on your preferred supplier list, or still on your books from an earlier engagement, the work only needs a new statement of work.
Grace Walker, VP of Engineering
What happens when the engagement ends?
LiveWyer
Nothing needs handing back
Our engineers work in your repositories and through your reviews, so everything they build is already yours and your team has seen every change.
Book an intro call
Book an intro call of up to an hour with one of our senior engineers to talk through your backlog or project, and we will tell you whether we can help.
Book an intro call