Stop using senior engineers for infrastructure

There is a staffing decision most engineering leaders do not realise they have made.

It happened gradually, without a job requisition or a hiring committee or a conversation about compensation bands. It happened the same way most infrastructure complexity arrives: one reasonable step at a time, until the situation was simply the situation.

Your senior engineers are running your operations practice. They are the ones who understand how the infrastructure fits together. They are the ones who get paged when the deploy pipeline fails on a Friday. They are the ones who know which IAM role to check when a permission error surfaces in production, which CloudWatch log group has the relevant output, which ECS task definition needs updating when a new environment variable has to be injected. That knowledge lives in them because it had to live somewhere, and they were the ones who built the system.

You are paying senior engineering salaries to do work you could be buying as a service. That is the staffing decision you did not realise you made.

What senior engineers are actually for#

When you hire a senior Laravel developer, or promote someone into a senior role, you are making a specific investment. You are paying for the ability to make hard architectural decisions before they become expensive to reverse. You are paying for the experience to recognise when a technical approach has a ceiling and to steer away from it early. You are paying for the mentorship that raises the floor of your whole engineering team over time. You are paying for the judgment that comes from having built production systems before and having learned from what went wrong.

None of that is what they are doing when they are debugging an ECS health check failure at 6pm on a Thursday.

The health check failure is urgent. It has to be fixed. And your senior engineer is the only person on the team who knows enough about the infrastructure to fix it quickly. So they fix it. The architectural review they were planning to do gets pushed. The junior developer who needed feedback on a pull request waits until tomorrow. The hard problem they were going to think through during the commute home gets displaced by the mental residue of an infrastructure incident.

This is the opportunity cost that never shows up in a budget. The cost is not the hours spent fixing the health check. The cost is everything that did not happen because those hours were spent that way instead.

The knowledge concentration problem#

Infrastructure knowledge on most self-managed AWS setups is concentrated in a small number of people. Usually one or two senior engineers who have been with the team long enough to have built or inherited the system and accumulated an understanding of why it is the way it is.

That concentration is not an accident. It is a structural consequence of running complex infrastructure. The system is too large and too interconnected for everyone to understand deeply. So the understanding ends up in the people who touch it most, and those people tend to be your most experienced engineers, because experience is what makes complex infrastructure legible.

The problem is that concentration makes your senior engineers load-bearing in a way that limits how you can use them. You cannot pull them entirely into product work because the infrastructure needs someone who understands it. You cannot put them on a critical feature for three weeks without arranging coverage for the operational responsibility they normally carry. They are not fully available for the work you hired them to do, because they are also carrying the operational context the system requires.

This is before considering what happens when they leave. When a senior engineer who carries deep infrastructure knowledge leaves a team, the loss is not just headcount. It is a body of operational understanding that cannot be fully transferred in a two-week notice period, no matter how thorough the documentation effort. The team that remains is operating a complex system with an incomplete map, and the gaps in that map will surface at the worst possible moments.

What you are actually paying for#

Take a senior engineer at a current market rate. Load in the full cost: salary, benefits, employer taxes, equipment, the recruiting cost amortised across their expected tenure. You are spending a meaningful amount per year on that person.

Now estimate what fraction of their time goes to infrastructure-related work. Not just the incidents. Include the background awareness they carry, the deploy pipeline maintenance, the AWS console time, the IAM policy reviews, the CloudWatch investigation that turned out to be noise, the time spent helping a junior engineer understand why a deployment failed in a way that had nothing to do with their code.

For teams running self-managed AWS infrastructure, that fraction is rarely zero and often uncomfortably large. The exact number varies by team, but the direction is consistent: a meaningful share of your most expensive engineering capacity is being consumed by operational work that is not connected to your product's competitive advantage.

That work has to happen. The infrastructure has to be maintained. The question is whether it should be happening inside your engineering team or whether it should be absorbed by a platform that was built to handle it.

The hiring signal you are sending#

There is a subtler cost that compounds over time: what self-managed infrastructure signals to engineers evaluating whether to join your team.

Senior engineers have options. The best ones are thoughtful about where they spend their time and what they will be learning. When the honest answer to "what does a senior engineer work on here?" includes a significant infrastructure operations component, that is a filter. Some candidates will find it interesting. Many will not. The ones who joined specifically to build product, to work on hard application-layer problems, to grow as software engineers, will deprioritise you in favour of teams where that is clearly what senior engineers do.

The inverse is also true. When infrastructure is handled and senior engineers are genuinely focused on product work, that is a compelling offer. It is a signal that the organisation is thoughtful about how engineering talent is deployed. That signal attracts the engineers who want to do the work you actually hired them to do.

The alternative is not hiring a DevOps engineer#

The reflex response to infrastructure operational burden is to hire someone whose job is the infrastructure. A DevOps engineer, a platform engineer, a site reliability engineer. Someone who carries the operational context so your product engineers do not have to.

That is a legitimate solution to the problem at certain scales. If you are large enough that the infrastructure complexity genuinely warrants dedicated ownership, that hire makes sense.

But for most Laravel teams at the SMB and growth-stage level, it is an expensive way to treat a symptom rather than the cause. You are now carrying an additional senior salary to manage infrastructure that a platform could absorb. The infrastructure complexity is still there. It now requires a dedicated person to manage it rather than pulling time from your product engineers. You have redistributed the cost, not eliminated it.

The more direct solution is to stop owning infrastructure that does not need to be owned. AWS is overkill for most product teams. The operational surface area that requires dedicated human attention is the surface area you chose to take on when you decided to run on raw AWS primitives rather than a platform built to absorb that layer.

What changes when the platform handles it#

When a production Laravel application runs on a platform that absorbs the infrastructure layer, the staffing dynamic changes in a specific way.

Your senior engineers stop being the people who carry operational context about infrastructure. They stop being the ones who get paged for infrastructure incidents, because those incidents are not theirs to respond to. They stop spending time on IAM policies, ECS task definitions, CloudWatch alarm thresholds, and deploy pipeline maintenance. You did not choose AWS. You inherited its complexity. When that complexity is absorbed by a platform, it stops being carried by your team.

What remains is the work they were hired to do. Architecture. Code quality. Mentorship. Hard product problems. The decisions that compound over time and make the product meaningfully better.

Sevalla exists for the 90% of teams who should not be running AWS at all. It is built specifically for Laravel applications running in production. A typical AWS Laravel setup requires you to configure and maintain an Application Load Balancer, EC2 or ECS for compute, RDS for the database, ElastiCache for Redis, SQS for queues, S3 for file storage, CloudWatch for logging and alerting, Route 53 for DNS, ACM for certificates, and the IAM structure connecting all of it. With Sevalla, you do not need or manage any of those services. Sevalla handles the infrastructure. Your engineers handle the product.

The reframe that changes the decision#

The framing that keeps most teams on self-managed AWS is inertia and familiarity. The infrastructure exists. The senior engineers know it. Changing it feels like a project, and projects have costs.

The reframe that changes the decision is to stop treating the current state as the default and start treating it as a choice you are making every month. Every month you run on self-managed AWS infrastructure, you are choosing to consume senior engineering capacity on operational work. You are choosing to concentrate critical knowledge in a small number of people. You are choosing to maintain the fragility that comes with a system whose understanding is informal and distributed unevenly.

Those are legitimate choices if the infrastructure provides something your product genuinely requires. For most Laravel teams, it does not. The infrastructure is a means to an end, and the means is consuming more than it should of the resource that is hardest to replace: the focused attention of your best engineers.

Your best engineers should be building your product. The infrastructure should be handled. Those two things can both be true at the same time, and choosing to make them both true is an engineering decision worth making deliberately.