DEV Community: Manish Shivanandhan

How to Diagnose Production Bugs When You Can't Reproduce Them Locally

Manish Shivanandhan — Thu, 23 Jul 2026 11:55:53 +0000

Every developer eventually encounters the same frustrating problem.

A customer reports that your application is failing in production. You try the exact same workflow on your development machine, but everything works perfectly. Your teammates can't reproduce the issue either. Automated tests pass. There are no obvious code changes that explain the failure.

Meanwhile, customers continue to experience the bug.

These issues are among the most difficult to solve because the problem often isn't the code itself. It's the environment the code is running in. Differences in configuration, infrastructure, traffic patterns, operating systems, dependencies, or production data can expose bugs that never appear during development.

Here's the uncomfortable truth: most of that difficulty is self-inflicted. Every server you manage, every log pipeline you wire together, and every configuration file you maintain by hand adds to an invisible infrastructure tax. And you pay that tax at the worst possible moment, when production is down and customers are waiting.

Fortunately, production-only bugs can be investigated systematically. In this article, you'll learn how to approach these issues using logs, metrics, distributed tracing, and environment analysis. You'll also see why applications running on a Platform as a Service (PaaS) are significantly easier to debug when things go wrong, because someone else is paying the tax for you.

Why does production behave differently?

Many developers think of production as simply a larger version of their local machine.

In reality, production environments are often very different.

A production application may run across multiple servers or containers behind a load balancer. It may connect to databases containing millions of records, communicate with third-party APIs, use distributed caches, process background jobs, and serve thousands of concurrent users.

Even seemingly small differences can introduce unexpected failures.

Imagine testing an API locally using simple English names like "John Smith." Everything works perfectly. In production, a customer submits a name containing emojis or accented characters, triggering an encoding issue that was never covered by your tests.

Or perhaps your application assumes an environment variable always exists because it's configured on every developer machine. During deployment, that variable is accidentally omitted, causing production requests to fail.

The code hasn't changed.

The environment has.

Notice what these failures have in common. None of them are business logic problems. They're environment problems, and every piece of infrastructure your team owns and configures by hand is another surface where your environment can silently drift away from what your code expects. The more infrastructure you manage yourself, the more of these surfaces exist.

Understanding that production behaves differently is the first step toward diagnosing these issues.

Start with evidence, not assumptions

When production starts failing, it's tempting to immediately start editing code.

Resist that temptation.

The fastest way to solve complex bugs is to gather evidence before making changes.

Start by answering questions such as:

When did the issue begin?

Did it appear immediately after a deployment?

Does it affect every customer or only a small group?

Is every application instance failing?

Did infrastructure metrics change around the same time?

Every answer narrows the search space.

But here's what nobody tells you: how quickly you can answer these questions depends almost entirely on your infrastructure, not your debugging skills. If deployment history lives in one system, logs in another, and metrics in a third, answering even the first question means logging into three tools and manually lining up timestamps. The investigation stalls before it starts, not because the bug is hard, but because your tooling is fragmented.

Instead of guessing what might be wrong, you're building a timeline of events that points toward the root cause.

Good debugging is an investigation, not an experiment. And an investigation is only as fast as your access to the evidence.

Logs tell you what happened

Application logs are usually the first source of information during an incident.

Unfortunately, many applications generate logs that provide almost no useful context.

A message like this offers very little value:

Error processing request.

Compare that with this example:

Timestamp: 2026-07-13T09:41:17Z
RequestId: 91df72
CustomerId: 48291
Endpoint: POST /orders
Database: OrdersDB
Duration: 3.2 seconds
Exception: TimeoutException

Now you know when the failure occurred, which customer experienced it, which endpoint was affected, how long the request took, and what exception caused it.

The goal isn't simply to record errors.

The goal is to provide enough context that someone investigating the issue can immediately begin asking the right questions.

Structured logging makes this even more powerful by allowing monitoring systems to search and filter logs using fields instead of plain text.

There's a catch, though. Great logs are worthless if you can't find them.

In self-managed setups, logs are scattered across servers, and teams end up building and babysitting their own aggregation pipelines just to make logs searchable. That's engineering time spent on plumbing, not on the product.

If your team maintains its own log shipping infrastructure, it's worth asking honestly: why are we still doing this ourselves?

Metrics reveal trends

Logs explain individual events. Metrics explain overall system behavior.

Suppose users report that your application becomes slow every afternoon.

Reading thousands of log entries may not reveal anything unusual.

A metrics dashboard, however, might immediately show that CPU usage spikes above 90%, memory consumption steadily increases throughout the day, database latency doubles after lunch, and HTTP error rates climb sharply during peak traffic.

Those observations immediately narrow your investigation.

Instead of wondering where to start, you now know exactly when the problem begins and which component is under stress.

Metrics transform isolated failures into recognisable patterns.

But that dashboard doesn't build itself. Someone has to install the agents, configure the exporters, size the time-series database, and keep the whole monitoring stack alive. In many teams, the monitoring system itself becomes another production system that fails and needs debugging. Monitoring your monitoring is the infrastructure tax at its most absurd, and it's a strong signal that your team is carrying operational weight it never needed to.

Distributed tracing connects every service

Modern applications rarely consist of a single application talking to a single database.

A customer request may travel through an API gateway, authentication service, order service, payment processor, inventory system, cache, message queue, and database before returning a response.

When something fails, which service caused the delay?

Distributed tracing answers that question.

A trace records the complete lifecycle of an individual request as it moves through your architecture.

Instead of seeing disconnected log entries from multiple services, you see one continuous timeline.

If a request spends four seconds waiting on the inventory database before timing out, the bottleneck becomes immediately obvious.

Without tracing, engineers often investigate the wrong service for hours.

With tracing, the slowest or failing component is usually visible within seconds.

The problem is that rolling out tracing yourself is a project, not a checkbox. Instrumenting every service, deploying collectors, and storing trace data all take real engineering effort, which is why so many teams that know they need tracing still don't have it. When observability is something you assemble rather than something your platform provides, it tends to remain permanently on the roadmap while incidents keep arriving on schedule.

Reproduce production as closely as possible

Sometimes logs and traces aren't enough.

Eventually you'll need to recreate the production environment.

That doesn't necessarily mean copying your production database onto your laptop.

Instead, identify the differences between environments.

Is production running Linux while developers use Windows or macOS?

Does production use Redis while development does not?

Are different runtime versions installed?

Are requests routed through a reverse proxy?

Does the production process handle significantly larger datasets?

Does production receive hundreds of concurrent requests while development receives only one?

Each difference becomes a potential explanation for the bug.

The closer your staging environment resembles production, the more likely you are to reproduce production-only failures before customers encounter them.

Notice, again, where the effort goes. Keeping staging faithful to production is a permanent maintenance job when both environments are hand-built, because hand-built environments drift the moment someone applies a patch to one and forgets the other. Teams that get environment parity for free, because every environment is generated from the same configuration, simply have fewer production-only bugs to chase in the first place.

Isolate environmental variables

One of the most effective debugging techniques is changing only one variable at a time.

Imagine your application fails only in production.

Potential differences include operating system versions, database engines, container configuration, environment variables, memory limits, network latency, or infrastructure settings.

Instead of modifying several variables simultaneously, test each one individually.

If changing only the database version reproduces the bug, you've eliminated dozens of other possibilities.

This disciplined approach often identifies the real cause much faster than random experimentation.

It's also worth pausing on that list of variables. Almost every item on it exists only because your team owns the infrastructure underneath the application. The fewer knobs you personally manage, the fewer variables you'll ever need to isolate.

A simple production-only bug

Consider this ASP.NET Core endpoint.

app.MapGet("/discount", () =>
{
    string region = Environment.GetEnvironmentVariable("REGION");

    if (region.ToLower() == "eu")
        return Results.Ok("20% discount");

    return Results.Ok("10% discount");
});

Everything works perfectly during development.

Then customers begin reporting HTTP 500 errors in production.

Eventually the logs reveal this exception:

NullReferenceException

The issue isn't difficult once you know where to look.

The production deployment forgot to define the REGION environment variable. Calling ToLower() on a null value immediately crashes the request.

The fix is straightforward.

string region = Environment.GetEnvironmentVariable("REGION") ?? "US";

if (region.Equals("EU", StringComparison.OrdinalIgnoreCase))
    return Results.Ok("20% discount");

The lesson isn't about null checking.

It's about understanding that production-only bugs are frequently caused by configuration differences rather than faulty business logic.

Without useful logs, developers might spend hours reviewing application code while completely overlooking the deployment configuration.

And step back one level further: this entire class of bug exists because a human had to remember to set a variable on a machine. Configuration drift isn't a coding failure, it's an operational failure, and it's the direct product of managing deployment configuration by hand. When you find yourself writing runbooks to remind people which variables to set on which servers, that's another "why are we still doing this ourselves?" moment worth taking seriously.

Verify the deployment itself

Not every production issue originates from your source code.

Deployment problems are surprisingly common.

A container image may not have been updated.

A configuration file might be missing.

A database migration may have failed.

An environment variable could contain an incorrect value.

A required secret may not have been deployed.

A rollback might have restored an older application version without anyone noticing.

Before assuming your code contains a bug, confirm that production is actually running the version you intended to deploy.

Many incidents have been resolved simply by discovering that the wrong build was running.

Read that list of deployment failures again. Every single one is a failure of infrastructure process, not of programming. They happen in homegrown deployment pipelines because homegrown pipelines have exactly as much verification as someone found time to build.

If your team can't answer "what version is running right now?" in one glance, your deployment system is generating bugs for you to debug later.

Why debugging is easier on a PaaS

The hardest part of diagnosing production bugs often isn't finding the root cause, it's finding the information you need to investigate.

In a traditional infrastructure setup, logs are scattered across multiple virtual machines, containers, load balancers, and background workers. When an application scales horizontally, a single customer request may touch several servers before it completes. Developers often spend more time SSHing into machines, locating log files, and correlating timestamps than actually debugging the problem.

That time is the infrastructure tax coming due. Every hour spent assembling evidence during an incident is an hour of downtime your team chose, months earlier, when it decided to own and operate all of that machinery itself.

A Platform as a Service (PaaS) changes that experience completely.

Instead of treating each server as an individual machine to manage, a PaaS treats your application as a single service. Logs from every instance are automatically aggregated into one place, metrics are collected continuously, and health checks are built into the platform. Whether your application is running on one container or fifty, you view it through a single dashboard instead of dozens of terminals.

When a production issue occurs, you can immediately answer important questions.

Did the problem begin after the latest deployment?

Is every application instance failing or only one?

Did CPU or memory usage spike before the application crashed?

Which release introduced the regression?

Instead of collecting this information manually, the platform already has it available.

Many PaaS platforms also maintain deployment history, making it easy to compare application behavior before and after each release. If error rates suddenly increase after version 2.8.1 is deployed, the relationship becomes obvious. Rolling back to a previous deployment often takes only a few minutes, dramatically reducing downtime.

Infrastructure consistency is another major advantage.

Applications deployed through a PaaS are created from the same deployment configuration every time. Developers don't have to wonder whether one server has an outdated runtime, a missing dependency, an incorrect operating system package, or a forgotten environment variable. Consistent environments eliminate an entire category of production-only bugs before they happen. Remember the REGION bug from earlier? On a platform where configuration is declared once and applied everywhere, that bug never ships.

Perhaps the biggest benefit is faster incident response.

During an outage, engineering teams shouldn't waste valuable time gathering evidence from multiple systems. Centralized logging, built-in monitoring, distributed tracing, deployment history, and health checks allow them to begin investigating immediately.

That translates directly into a lower Mean Time to Resolution (MTTR), shorter outages, and a better experience for both developers and customers.

Build applications that are easy to debug

Production bugs are inevitable.

Complex systems fail in unexpected ways, no matter how experienced the engineering team is.

The difference between mature engineering organizations and everyone else isn't whether bugs occur. It's how quickly they can understand and resolve them.

Write meaningful logs that provide context instead of generic error messages. Collect metrics continuously so performance trends are visible before users complain. Instrument your applications with distributed tracing so requests can be followed across services. Keep staging environments as close to production as possible, and treat infrastructure configuration as carefully as application code.

Just as importantly, choose a platform that makes debugging easier instead of harder.

Teams relying on manually managed servers often spend the first hour of an incident simply gathering logs and connecting to machines. Teams running on a modern PaaS begin with the evidence already in front of them. They can correlate deployments with error spikes, inspect logs from every application instance, review infrastructure metrics, and trace failing requests without leaving a single dashboard.

Be honest about which team yours is. If your engineers maintain log pipelines, monitoring stacks, staging parity, and deployment scripts on top of the product they were hired to build, you're paying the infrastructure tax in its most expensive currency: incident time. Unless operating infrastructure is your business, it's overhead, and overhead you can hand to a platform.

A PaaS won't prevent every production bug, but it removes much of the operational complexity that makes those bugs difficult to diagnose. That means less time hunting for information, faster root-cause analysis, quicker recovery during incidents, and more time focused on building software instead of managing infrastructure.

When the next production issue appears, and it inevitably will, you'll spend less time asking, "Why can't I reproduce this?" and more time asking the better question: "Why were we ever doing all of this ourselves?"

Hope you enjoyed this article. You can connect with me on LinkedIn.

Why "It Worked on My Machine" Still Happens in 2026

Manish Shivanandhan — Thu, 16 Jul 2026 14:03:51 +0000

Every engineering team has said it at least once: "It works on my machine."

The phrase has become a running joke in software, but it's rarely funny when it happens in production.

A feature passes every local test, the pull request gets approved, the deployment finishes successfully, and then users start reporting failures.

On-call engineers get paged. Incident channels fill up. A fix that took ten minutes to write takes four hours to trace back to a missing environment variable or a runtime version mismatch nobody noticed.

The strange part is that this still happens in 2026.

Modern development has better tooling than ever. Containers, automated testing, cloud infrastructure, CI/CD pipelines, infrastructure as code, and AI coding assistants have all made building software considerably faster.

And yet engineering teams running customer-facing applications continue to lose significant time chasing bugs that only appear outside a developer's laptop.

One industry survey found that developers spend roughly 40% of their time on tasks unrelated to writing features, and environment debugging is a leading culprit.

The reason isn't that engineers are careless. Most software doesn't fail because of bad code. It fails because code runs inside an environment, and those environments are rarely identical.

The gap between a developer's laptop and a production cluster is still one of the most consistent sources of engineering waste these days.

The real question is no longer why this problem exists. Every experienced engineering team understands environment drift. The better question is why so many product teams are still spending engineering time managing it.

Every Machine Tells a Slightly Different Story

A production application depends on much more than source code.

It depends on the operating system, runtime versions, environment variables, databases, third-party services, networking rules, file permissions, installed libraries, and CPU architecture.

A developer running Node.js 24 LTS may be pairing with a teammate still on 22. One laptop has a newer OpenSSL version installed as a transitive dependency update. Another has a cached build artefact from three months ago that quietly changed behaviour after a library patch.

None of these differences looks significant on their own. Together, they create a local environment that behaves differently from every other environment in the pipeline.

This is how a test suite passes green on a developer's machine and fails in CI twenty minutes later. It's how an application boots cleanly on macOS but crashes on the Debian container your cloud provider runs.

It's why a microservice that handled 500 requests per second last Tuesday starts timing out this Monday after what appeared to be an unrelated dependency bump.

The code hasn't changed. The environment has.

Dependencies Are Moving Targets

Package managers have made software development productive, but they've also dramatically increased the surface area of a running application.

A typical Node.js web application today has between 500 and 1,500 packages in its dependency tree, including indirect dependencies, even when a developer explicitly installs only a handful.

A Python service using common data processing and web frameworks can pull in 200 to 400 packages. Most engineers have no direct relationship with the vast majority of packages their application ships.

When dependency versions aren't locked correctly, two developers installing the same project on the same day can receive materially different software stacks. Lock files like package-lock.json, pnpm-lock.yaml, poetry.lock, Cargo.lock exist precisely to prevent this, and they help. But they're one layer of control in a much larger consistency problem.

Runtime versions still differ. System libraries still differ. Base OS images in containers drift across patch cycles. A Docker image built from node:22 today isn't the same image that gets built in six weeks when the upstream tag has been updated. Teams that don't pin their base images precisely are unknowingly accepting environment drift at the foundation of every deployment.

Configuration Causes More Incidents Than Code Does

Many of the most disruptive production incidents on engineering teams have nothing to do with programming logic.

They come from configuration.

An environment variable is missing in the new deployment target. A database connection string points to staging instead of production. A feature flag is set to true in the developer's .env file but defaults to false in the deployed service, silently disabling a critical code path. An API key was rotated but the secret manager reference was updated in one environment and not the other.

These mistakes are common, and genuinely difficult to prevent, because configuration lives outside the application. It's managed separately, documented inconsistently, and almost never covered by standard test suites.

Post-incident reviews regularly surface configuration drift as the root cause of outages that took hours to diagnose because the application code looked completely correct.

The problem compounds across environments. A team running development, staging, pre-production, and production has four separate configuration states to keep aligned.

When an engineer adds a new environment variable, that change has to propagate through every environment reliably. In practice, it often doesn't. One environment gets missed. An old value lingers. The application behaves differently, and the investigation starts from scratch.

The Real Cost of Managing Multiple Environments

Engineering leadership often underestimates how much time is consumed by environment management, not because it's hard to observe, but because it's distributed across dozens of small tasks that never appear as line items.

Someone updates the Node runtime in the base Docker image and spends an afternoon chasing a downstream test failure that turned out to be a transitive dependency incompatibility.

Someone provisions a new staging environment and spends a day replicating the production configuration by hand. Someone rotates credentials, misses one service, and triggers a silent failure that takes until the next deployment cycle to surface. Someone joins the team and spends the first two days getting a local environment running instead of shipping work.

Estimates from engineering productivity research suggest that infrastructure and environment-related tasks consume between 15 - 25% of total engineering capacity at companies that own their own deployment infrastructure. For a team of ten engineers, that's effectively two to three people running hard and producing no customer-facing output.

This is the cost that doesn't appear on sprint boards. It lives in Slack threads, in incident retrospectives, and in the quiet acknowledgement that the team is slower than it should be.

None of this work appears on a roadmap. Customers never ask for it. It doesn’t create differentiation. Yet product teams spend hundreds of engineering hours every year maintaining consistency between environments simply to keep software deployable. Environment drift isn't just a reliability problem. It's an engineering capacity problem.

Why Are Teams Still Managing This Themselves in 2026?

Given all of this, the reasonable question is why so many engineering teams are still owning this complexity directly.

Part of the answer is inertia. Teams that built their infrastructure several years ago, when Kubernetes was the obvious answer to every scaling question and "we control our own stack" felt like a competitive advantage, now maintain that infrastructure because changing it has a cost.

The investment is already made. The tooling is already familiar. The pain is distributed and chronic rather than acute, which makes it easier to absorb than to address.

Part of the answer is organisational habit. Hiring a platform or DevOps engineer to manage infrastructure feels like the right response to environmental problems. But that engineer becomes responsible for maintaining the consistency layer indefinitely. Patching base images, updating runtime versions, managing certificate renewals, and debugging networking issues across environments, rather than delivering product leverage.

Part of the answer is a belief that more control produces better outcomes. Running your own infrastructure gives complete visibility into every configuration decision.

But complete control also means complete responsibility. Every decision the platform team makes is a decision the platform team must maintain, document, and revisit every time something upstream changes.

Most product engineering teams aren't in the infrastructure business. They're in the business of building software for customers, and every hour spent on environment consistency is an hour not spent on that.

The honest answer is that many teams are managing this complexity themselves because they haven't yet found a clear path to stopping.

Local Success Doesn't Reflect Production Conditions

One consistent failure mode is treating a passing local test as a signal that a deployment is safe.

Production environments impose conditions that development machines never encounter. A service that starts cleanly on a laptop with no concurrent users will behave differently when handling 2,000 requests per second with three application instances competing for a shared database connection pool.

A background job that completes in milliseconds locally may time out in production when it runs simultaneously with twelve other jobs against a database under real write load.

Staging environments exist to surface these differences before they reach users. But staging only provides value when it actually resembles production, like the same infrastructure, the same runtime versions, the same configuration shape, same network topology.

Many teams treat staging as a best-effort approximation. Over time, configuration drift between staging and production means that staging stops catching the failures it was designed to catch. Teams end up discovering environment-related issues in production anyway, which is the worst place to find them.

Maintaining genuine parity across three or four environments is expensive and requires continuous attention. Infrastructure updates must be applied uniformly. Runtime versions must stay synchronised. Configuration must be propagated reliably.

Without active discipline, staging drifts away from production, and the safety net disappears.

Why Are More Engineering Teams Choosing Managed Platforms?

At some point, every engineering organisation has to ask a more fundamental question. Should we keep investing engineering time into maintaining environments, or should we move that responsibility to a platform built for it?

This is the context in which Platform as a Service has become a more serious consideration for teams that previously managed their own infrastructure.

A well-designed PaaS doesn't remove engineering responsibility. It relocates it.

Developers still write code. They still define environment variables and build processes. They still decide what their application needs. The difference is that the platform provides a consistent, maintained runtime across every environment like development, staging, and production, without the team owning the underlying infrastructure.

The same application definition runs everywhere. Environment parity becomes a property of the platform rather than a discipline the team has to enforce continuously.

This matters most to engineering teams with real deployment velocity, the teams shipping multiple times per day, running several services, and operating with the expectation that deployments are predictable.

When the platform standardises the environment, deployments stop being experiments. Engineers stop discovering production-only failures at the worst possible time.

The operational tradeoff is real. Some organisations require control over their infrastructure for compliance, regulatory, or architectural reasons that a PaaS can't accommodate. But many teams that believe they need that control have never closely examined the cost of maintaining it.

The question isn't whether owning infrastructure gives you control. It's whether that control is producing outcomes that justify the engineering capacity it consumes.

What a Basic PaaS Setup Actually Looks Like

The argument for a managed platform is easier to evaluate with a concrete picture of what adopting one involves. The details vary across providers like Render, Railway, Sevalla, etc, but the setup's shape is remarkably consistent and smaller than most teams expect.

Step 1: Connect your repository. Every mainstream PaaS starts from your Git repository. You authorise the platform against GitHub or GitLab, point it at a repo, and choose a branch to deploy from. From that moment, the platform watches for pushes. There's no CI pipeline to write for the basic case, since build-and-deploy on push is the default behaviour.

Step 2: Define the application, once, in a file. Instead of configuring servers, you describe what your application is: the runtime, the build command, the start command, and the services it needs. Most platforms let you do this through a dashboard, but the better practice is a declarative file that lives in the repo.

services:
  - type: web
    name: my-api
    runtime: node
    buildCommand: npm ci
    startCommand: npm run start
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: my-api-db
          property: connectionString
      - key: NODE_ENV
        value: production

databases:
  - name: my-api-db
    plan: basic

This file is the payoff of the whole model. It's the single source of truth for how the application runs, it's version-controlled alongside the code, and, critically, it's the same definition in every environment.

The drift described earlier in this article, where staging quietly diverges from production, has nowhere to live, because there is no second copy of the environment to fall out of sync.

Step 3: Set your environment variables in the platform, not in files. Secrets and configuration move out of scattered .env files and into the platform's environment settings, scoped per environment.

When an engineer adds a new variable, the platform surfaces it in one place rather than requiring a manual update across four deployment targets. Most platforms also support environment groups, so shared configuration is defined once and inherited.

Step 4: Attach managed services. Databases, caches, and cron jobs are provisioned by the platform rather than installed and patched by your team.

In the example above, the database is declared in the same file as the application, and its connection string is injected automatically, so there's no connection string to copy incorrectly into staging.

Step 5: Push, and let preview environments do the rest. This is where the parity argument becomes tangible. Most modern PaaS providers spin up a preview environment for every pull request: a full, disposable copy of the application, built from the same definition file, running on the same infrastructure as production.

"Works on my machine" stops being the standard of evidence, because every reviewer is looking at the code running in a production-shaped environment before it merges. When the PR closes, the environment is destroyed.

That's the whole setup. For a typical web service, going from repository to a deployed, auto-updating application with a managed database takes an afternoon, not a quarter.

For teams with existing infrastructure, the sensible starting point isn't a migration project. It's one service , ideally something low-risk and self-contained, like an internal tool or a background worker.

Run it on a platform for a month, compare the operational load against its Kubernetes-hosted siblings, and let the result inform the larger decision. Most teams that make this comparison discover the question isn't whether the platform can handle their workload. It's how much of their engineering week they'd been spending to get a worse version of the same guarantee.

Consistency is an Ownership Question, Not a Tooling Question

"It worked on my machine" gets framed as a process problem, or a testing problem, or occasionally a culture problem. The real framing is more useful: it's an ownership problem.

Every difference between environments like runtime versions, dependency trees, configuration values, and infrastructure state increases the probability that software behaves unexpectedly in production. The conventional response is to invest in better tooling: stricter lock files, more comprehensive CI, better container discipline, more thorough staging.

All of these reduce the problem. None of them eliminates the underlying dynamic, which is that the team is responsible for the consistency of every environment it owns.

The teams that have largely solved deployment reliability in 2026 aren't necessarily the ones with the most sophisticated infrastructure. Many of them are the ones that have reduced the number of environments they own and maintain.

They have moved infrastructure decisions to platforms designed to handle them, and redirected that engineering capacity toward problems that are actually differentiated: the product, the performance, the reliability of the application itself.

Environment consistency is a solvable problem. The remaining question is ownership. Every product team must decide whether maintaining infrastructure is part of its competitive advantage or simply an operational burden it has accepted over time. More engineering teams are concluding that their advantage comes from shipping product, not managing environments.

My Experience Moving from AWS to Sevalla

Manish Shivanandhan — Thu, 18 Jun 2026 11:54:22 +0000

Most product teams have accepted infrastructure ownership as a normal part of software development.

I think that's a mistake.

Not because infrastructure isn't important. It is. Not because Amazon Web Services (AWS) is a bad platform. It isn't.

The mistake is assuming that every engineering team should spend significant time operating cloud infrastructure in the first place.

Over the last decade, we've normalised the idea that product teams should manage deployments, maintain observability stacks, troubleshoot networking issues, optimise cloud costs, configure permissions, build CI/CD pipelines, and own operational tooling.

We've accepted this work as part of building software.

But most product teams aren't trying to build cloud platforms.

They're trying to build products.

That realisation fundamentally changed how I think about infrastructure, and it ultimately led me from AWS to Sevalla.

The migration itself wasn't the most important lesson.

The more important lesson was discovering how much engineering effort had been consumed by operational work that wasn't creating customer value.

Product Teams Are Quietly Becoming Platform Teams

This article isn't for companies whose business depends on building sophisticated cloud platforms.

It's not for organisations running specialised infrastructure on an enormous scale.

It's not for teams whose competitive advantage comes from custom cloud architecture.

It's for growth-stage companies, SaaS businesses, internal product teams, and engineers responsible for shipping software to production.

The kind of teams that need to move quickly.

The kind of teams that need to respond to customer feedback.

The kind of teams that win by delivering better products, not by maintaining better infrastructure.

Yet many of these organisations operate as though they're platform engineering companies.

Someone owns deployment pipelines.

Someone maintains monitoring systems.

Someone manages cloud permissions.

Someone investigates infrastructure incidents.

Someone spends hours analysing cloud costs.

Someone becomes the person who understands how everything works.

Gradually, the team responsible for building products becomes responsible for operating an internal platform nobody intended to create.

And most of the time, nobody stops to ask whether this is actually necessary.

AWS Isn't the Problem

AWS is extraordinarily capable.

That's precisely why so many teams end up with more infrastructure than they need.

AWS gives organisations access to almost unlimited flexibility. The problem is that flexibility comes with operational responsibility.

Every service introduces decisions.

Every decision introduces maintenance.

Every layer of customisation introduces another layer of ownership.

Eventually, teams find themselves supporting infrastructure designed for requirements they may never actually have.

The irony is that many product teams don't suffer from insufficient infrastructure.

They suffer from too much of it.

They have more control than they need and less time than they need.

The Real Cost Isn't Infrastructure. It's Engineering Attention.

Most discussions about cloud infrastructure focus on cost.

The monthly bill.

Resource utilization.

Storage consumption.

Compute costs.

Those expenses matter.

But they're not the most expensive part of infrastructure ownership.

Engineering attention is.

When a deployment fails, engineers stop building features.

When observability tooling breaks, engineers stop building features.

When infrastructure incidents occur, engineers stop building features.

When cloud costs spike unexpectedly, engineers stop building features.

Every operational responsibility competes with product development for the same limited pool of engineering time.

The result isn't just slower infrastructure work.
It's a slower product development.

I've seen engineers spend entire afternoons debugging deployment pipelines.

I've seen releases delayed because nobody was completely confident in the deployment process.

I've seen teams postpone product work because operational issues demanded immediate attention.

I've seen organisations accumulate layers of tooling that required ongoing maintenance despite providing little direct customer value.

None of these teams was doing anything wrong.
They were simply accepting infrastructure ownership as normal.

The question is whether it should be.

Why Are Product Teams Building Observability Platforms?

One of the clearest examples of unnecessary infrastructure ownership is observability.

Most teams don't just deploy applications.

They build monitoring systems.

They build logging systems.

They build alerting systems.

They build dashboards.

They build deployment tracking workflows.

Then they spend time maintaining all of it.

The goal is understandable. Teams need visibility into production. The problem is that many organisations end up investing substantial engineering effort in creating visibility instead of using visibility to improve products.

Before moving to Sevalla, production information often felt fragmented.

Logs lived in one place. Metrics lived somewhere else. Deployment history existed independently.

The information existed, but understanding what was happening required assembling the story manually.
That process wasn't difficult because engineers lacked skill.

It was difficult because the system itself required unnecessary effort.

Production Visibility Shouldn't Be a Separate Project

One of the biggest changes after moving to Sevalla wasn't deployment speed. It was production awareness.

Logs became easier to access.

Metrics became easier to interpret.

Deployment history became easier to correlate with incidents.

Engineers spent less time searching for information and more time acting on it.

That distinction matters.

Many teams believe they need better monitoring.

In reality, they often need fewer layers between themselves and production insights.

When response times increased, we could quickly identify whether the issue coincided with a deployment.

When errors appeared, logs were immediately available.

When resource utilisation changed, the information was easy to find and understand.

The value wasn't more dashboards.The value was reducing the effort required to answer operational questions.

Instead of asking where information lived, we could focus on solving problems.

That's a very different way of operating.

Faster Recovery Creates Better Products

Production incidents are inevitable.

The goal isn't eliminating every failure.The goal is to reduce the time required to understand and resolve them.

Yet many organisations make incident response harder than it needs to be.

Engineers investigate issues across multiple tools.

They correlate logs manually.

They reconstruct deployment timelines.

They piece together metrics from separate systems.

This work adds friction precisely when speed matters most.

After moving away from that model, one thing became obvious.

The faster teams can understand production, the faster they can improve it.

Shorter investigations lead to shorter disruptions.

Shorter disruptions lead to better customer experiences.

Better customer experiences lead to stronger products.

The objective isn't operational sophistication.

The objective is delivering value.

Most Product Teams Don't Need More Infrastructure Flexibility

One of the strongest arguments for managing infrastructure directly is flexibility.
Technically, that's true.

Owning every layer gives teams more control.
The question is whether that control creates meaningful value.

For many product teams, it doesn't.

Most organisations aren't constrained by insufficient infrastructure flexibility. They're constrained by limited engineering capacity.

The bottleneck isn't cloud architecture. The bottleneck is time.

Every hour spent managing infrastructure is an hour unavailable for customer research, product improvements, bug fixes, experimentation, and feature development.

When viewed through that lens, infrastructure ownership starts looking very different.
The question stops being: "Could we manage this ourselves?" And becomes: "Why are we managing this ourselves?"

The Lesson Had Nothing to Do With Sevalla

The biggest takeaway from this experience wasn't that Sevalla is better than AWS.

That's not the point. The point is that many product teams have inherited infrastructure complexity they don't actually need.

They've inherited operational responsibilities that consume engineering attention without creating meaningful competitive advantage.

They've accepted infrastructure ownership as a default rather than a choice.

Moving to a PaaS forced me to challenge that assumption.

Once I did, I realised how much of our operational work existed simply because we had chosen to own it.

Not because customers demanded it.

Not because the business required it.

Not because it differentiated the product.

Simply because it had become normal.

Final Thoughts

Most product teams should optimise for product velocity, not infrastructure flexibility.

They should optimise for shipping, not operating.

They should optimise for customer outcomes, not cloud ownership.

The default assumption should not be that every engineering team needs to build and maintain its own platform.

The default assumption should be that engineering time is valuable and should be spent creating customer value whenever possible.
Infrastructure ownership isn't free.

It consumes attention. It slows releases. It creates operational burden. It turns product engineers into part-time platform engineers.

For the small percentage of organizations whose business genuinely depends on custom infrastructure, that trade-off may be justified.

For everyone else, it deserves much more scrutiny than it usually receives.

The question isn't whether your team can manage infrastructure.

The question is whether managing infrastructure is helping your team win.

For most product teams, the answer is probably no.

The Moment Your Team Realises They Are Spending More Time Deploying Than Building

Manish Shivanandhan — Thu, 04 Jun 2026 14:44:12 +0000

There is a specific moment that happens inside product engineering teams running production software.

It usually does not happen during a major outage. It does not happen during a failed sprint. It rarely happens during a dramatic postmortem.

Instead, it happens quietly.

A developer spends half a day investigating why a deployment succeeded in staging but failed in production. Another engineer pauses feature work to update IAM permissions that suddenly broke the CI/CD pipeline. Someone else spends an afternoon rolling back a release because an infrastructure change created unexpected side effects.

At some point, someone asks a simple question:

"Why are we spending so much time getting software into production instead of building software?"

For SaaS companies, fintech platforms, healthcare applications, enterprise software vendors, and other product organisations, that question has become increasingly common.

The problem is not that deployment has become harder.

The problem is that many product teams have gradually inherited responsibility for infrastructure ownership and are now paying a hidden engineering tax as a result.

Over time, responsibilities accumulate. Teams adopt containers, cloud infrastructure, deployment pipelines, monitoring platforms, secrets management systems, infrastructure-as-code frameworks, security tooling, and observability stacks. Each decision makes sense in isolation.

Together, they create an operational burden that quietly consumes engineering capacity.

Developers are no longer spending most of their time building products.

They are spending a growing percentage of their time operating deployment machinery.

That realisation is leading many organisations to reconsider whether managing infrastructure themselves still makes strategic sense.

The Hidden Engineering Tax Nobody Planned For

Modern software development has become dramatically faster.

AI-assisted coding tools, code generation platforms, and mature frameworks allow engineering teams to create functionality at a pace that would have seemed impossible a decade ago.

According to the 2025 Stack Overflow Developer Survey, 84% of developers are already using or planning to use AI tools in their workflow, and more than half of professional developers use them daily.

The bottleneck is no longer writing code.

The bottleneck is everything that happens after the code is written.

Many product teams now maintain an extensive collection of operational systems. They manage CI/CD pipelines, cloud infrastructure, deployment workflows, networking rules, container registries, environment configurations, certificates, monitoring integrations, scaling policies, and security controls.

Each component requires maintenance.

Each component occasionally breaks.

Each component demands attention from engineers whose primary responsibility is building products.

Consider a typical week inside a growing software company.

A deployment pipeline fails after a dependency update. An engineer spends two hours identifying the root cause. A release is delayed because a production environment contains configuration values that differ from staging. A senior developer is pulled into a permissions issue after a cloud policy change unexpectedly blocks deployments. A rollback requires manual intervention because database migrations were not designed to reverse cleanly.

None of this work appears on a product roadmap.

None of it creates customer value.

Yet it consumes real engineering time.

Research from SonarSource found that developers spend roughly 30% of their working hours on maintenance-related activities. While maintenance encompasses more than deployment work, infrastructure ownership increasingly contributes to that burden.

This is the hidden engineering tax that many organisations never formally measure.

Most Product Teams Accidentally Became Infrastructure Teams

Many engineering leaders accept deployment complexity as an unavoidable cost of modern software development.

For some companies, that assumption is valid.

Organisations whose business depends on operating large-scale cloud infrastructure, distributed systems, or specialised computing platforms often need direct control over every layer of their environment.

Most product companies are different.

A SaaS company selling project management software does not gain a competitive advantage from maintaining Kubernetes networking policies.

A fintech startup does not win customers because its engineers spent weeks optimising deployment pipelines.

A healthcare software provider is not differentiated by custom infrastructure automation.

Customers pay for products.

They do not pay for deployment architecture.

Yet many organisations continue investing engineering effort into infrastructure capabilities that provide little direct business value.

What begins as a practical decision gradually evolves into an organisational habit.

Teams inherit deployment systems built years earlier. New engineers learn internal infrastructure tooling. Operational responsibilities expand. More time is allocated to maintaining the platform.

Eventually, infrastructure management becomes a significant part of the engineering function itself.

The result is a strange situation where product organisations devote increasing resources to solving infrastructure problems rather than customer problems.

When Deployment Becomes the Product

One of the clearest warning signs appears when deployment work begins competing directly with product work.

Engineering teams start planning around release windows instead of customer priorities.

Developers become hesitant to deploy because pipelines have become fragile.

Lead times increase because releases require multiple approvals and infrastructure reviews.

Production incidents require a small group of specialists who understand legacy deployment systems.

The DevOps Research and Assessment (DORA) framework measures software delivery performance through deployment frequency, lead time for changes, change failure rate, and recovery time.

When deployment systems become excessively complex, every one of these metrics suffers.

Deployment frequency declines because releases feel risky.

Lead times increase because infrastructure coordination slows delivery.

Recovery times expand because operational knowledge becomes concentrated among a few engineers.

Change failure rates increase because environments drift apart over time.

Many teams experience this firsthand.

Code works perfectly in development environments but fails in staging.

Staging succeeds, but production behaves differently because feature flags are configured inconsistently.

CI pipelines pass while deployment automation fails due to missing permissions.

Rollbacks that should take minutes stretch into hours because multiple systems must be coordinated.

These issues often become accepted as normal.

They should not be.

They are symptoms of a deployment process consuming more engineering attention than it should.

The Cost Most Organisations Never Calculate

Infrastructure complexity creates costs that rarely appear in budget discussions.

Companies often compare the price of cloud infrastructure against the price of platform tooling.

That comparison misses the larger expense.

Engineering time is usually the most expensive resource inside a software organisation.

Imagine a 20-person engineering team.

Every week, engineers collectively spend time investigating failed deployments, managing environment drift, reviewing infrastructure changes, troubleshooting permissions issues, maintaining deployment scripts, and responding to operational alerts.

Even a few hours per engineer quickly becomes significant.

Recent industry research suggests that invisible operational work now accounts for approximately 31% of developer time in many organisations.

For a team of 20 engineers, losing just 3 hours per week per developer to deployment-related work adds up to more than 3,000 engineering hours per year.

That is the equivalent of nearly two full-time engineers spending an entire year on activities that do not directly improve the product or create customer value.

Few organisations would intentionally allocate that much engineering capacity to deployment overhead. Yet many teams lose those hours gradually through manual releases, environment drift, configuration issues, and repetitive operational tasks without fully recognising the impact.

The expense remains hidden because it is distributed across the engineering team.

The cost is real nonetheless.

Why Platform as a Service Changes the Equation

This is where Platform as a Service becomes strategically important.

The strongest argument for PaaS is not convenience.

It is focus.

Most product teams do not need infrastructure to be a competitive differentiator.

Deployment automation, rollback management, environment provisioning, observability, scaling, and security controls are largely solved problems.

Rebuilding those capabilities internally rarely creates meaningful business value.

A mature PaaS abstracts much of that operational complexity behind a standardised platform layer.

Instead of configuring servers, engineers deploy applications.

Instead of maintaining deployment pipelines, engineers focus on product delivery.

Instead of managing infrastructure primitives, engineers work on customer-facing functionality.

Capabilities such as automated deployments, environment management, scaling, monitoring, security controls, and rollback mechanisms become platform features rather than engineering responsibilities.

This dramatically reduces operational cognitive load.

Developers spend less time thinking about deployment mechanics and more time thinking about product outcomes.

Organisations looking at modern platform approaches often evaluate solutions such as Platform.sh, Render, Fly.io, and other managed deployment platforms that reduce the operational burden placed on product teams.

The common goal is not simply infrastructure simplification.The goal is reclaiming engineering time.

The Economics Favour an Engineering Focus

One of the most common objections to PaaS adoption is cost.

At first glance, self-managed infrastructure often appears cheaper.

However, raw infrastructure pricing tells only part of the story.

The real comparison is not infrastructure versus platform.

The real comparison is engineering time versus engineering output.

Suppose a 15-person engineering team spends an average of 10 hours per week per developer on deployment-related maintenance, infrastructure troubleshooting, pipeline management, environment issues, and operational tasks.

That represents 150 engineering hours every week.

Over the course of a year, the total exceeds 7,500 hours.

For most organisations, the labour cost associated with those hours exceeds the annual subscription cost of many commercial platform solutions.

This is one reason platform engineering has become such a major focus throughout the industry.

According to DORA's platform engineering research, organisations increasingly evaluate platform success based on improvements in deployment frequency, lead time, recovery time, and overall delivery performance.

The objective is not simply to reduce infrastructure spending.

The objective is to increase engineering output.

The Talent Retention Problem

There is another consequence of infrastructure ownership that receives less attention.

Developers generally join product companies because they want to build products.

They want to solve meaningful problems.

They want to create experiences that customers use every day.

Very few engineers are motivated by spending large portions of their week debugging deployment pipelines or investigating configuration drift.

When operational overhead continues to grow, frustration follows.

Research from Storyblok found that 58% of senior developers in medium and large organisations have considered leaving because of legacy technology and maintenance burdens.

Infrastructure complexity is not the only factor contributing to that frustration, but it is often part of the problem.

The more time engineers spend maintaining deployment systems, the less connected they feel to customer outcomes.

A strong platform strategy helps reverse that trend.

Developers spend more time building.

Organisations ship more frequently.

Engineering teams remain focused on delivering value rather than maintaining operational machinery.

The Question Product Teams Should Be Asking

The software industry has entered an era where writing code is no longer the primary constraint.

AI tools continue accelerating development.

Frameworks continue to reduce implementation effort.

Managed services continue to eliminate repetitive engineering work.

The next competitive advantage will not come from writing code faster.

It will come from turning ideas into production outcomes faster.

For years, the default assumption was that engineering teams should own deployment infrastructure because there were few alternatives.

Today, that assumption deserves scrutiny.

If engineers spend significant portions of their week managing pipelines, troubleshooting environment drift, resolving permissions issues, maintaining deployment tooling, and planning rollback procedures, the problem may not be deployment complexity.

The problem may be infrastructure ownership itself.

The most effective product teams of the next decade will not necessarily be the teams with the most sophisticated deployment systems.

They will be the teams that invest the least engineering effort into deployment machinery and the most engineering effort into building products that customers actually want.

That is the moment many organisations eventually reach.

Not when deployment becomes difficult.

But when they begin asking whether managing infrastructure should be their responsibility at all.

Hope you enjoyed this article. You can connect with me on LinkedIn.

The Tradeoff That Slows Production Teams Down: Flexibility vs Actually Shipping

Manish Shivanandhan — Sun, 24 May 2026 11:25:12 +0000

Every company says it wants speed.

Roadmaps talk about velocity. Leadership meetings talk about reducing cycle time. Quarterly goals talk about faster execution and quicker releases.

Every business wants teams moving faster.

Then many of those same companies make a decision that quietly slows everything down. They optimise for infrastructure flexibility instead of product delivery.

It sounds reasonable in the beginning. Teams want control. Engineers want options. Platform architects want systems that can support every future scenario.

So production teams start building infrastructure ecosystems around themselves.

Deployment pipelines get built from scratch. Cloud resources become heavily customised. Internal platforms gain endless knobs, switches, and configuration layers. New projects begin with architecture discussions instead of customer problems.

Months later, software delivery slows down.

Product teams miss timelines. Releases move out by quarters. Customer feedback arrives later. Competitors keep shipping.

The tradeoff hiding underneath all of this is simple. Teams choose flexibility over actually shipping.

And beyond a certain point, flexibility becomes one of the most expensive forms of organisational drag a company can create.

The Myth That More Flexibility Creates Better Production Systems

Engineering teams love optionality. The logic sounds convincing.

If infrastructure is fully customizable, teams can adapt to future requirements. If deployment systems are built internally, every use case can be supported. If every layer is configurable, engineers can optimise for unique situations.

This feels like responsible engineering. But it often becomes expensive business behaviour.

Most production teams massively overestimate how often they need deep infrastructure flexibility.

What actually happens becomes predictable.

A product team starts a new initiative. Instead of shipping an early version and learning from customers, discussions begin.

Should Kubernetes clusters be organised by team or service?

Should CI/CD use GitHub Actions or Jenkins?

Should secrets management use Vault or cloud-native tooling?

Should observability use Prometheus or Datadog?

Should deployment strategies use canary releases, blue-green deployments, or something custom?

Weeks disappear. No customer sees anything. No assumptions get tested. No learning happens.

Meanwhile, product managers wait. Leadership waits. Customers wait.

Even with agentic coding tools like Claude generating code, scaffolding systems and accelerating implementation, teams still lose speed when every output collides with infrastructure decisions and deployment debates.

The problem is not technology.

The problem is optimising around theoretical future flexibility instead of present business outcomes.

Software creates value when customers use it. Everything else is support work.

Infrastructure Ownership Quietly Becomes a Second Business

Traditional deployment models accidentally create a dangerous pattern.

Companies think they are building products.

Slowly, they start building infrastructure organisations.
Production teams provision servers. Then networking. Then IAM systems. Then deployment pipelines. Then, observability layers. Then secrets management. Then autoscaling. Then rollback systems.

Every decision feels reasonable in isolation.
Collectively, teams create an operational machine they now own forever.

And ownership is where the hidden cost appears.
Because infrastructure work does not end after launch. It expands.

Pipelines need maintenance. Security policies change. Monitoring systems require tuning. Platform dependencies break. Internal tooling needs upgrades.

Production teams gradually spend more time maintaining systems around software than improving software itself.

This creates a strange situation.

Highly paid engineers become caretakers for infrastructure instead of builders of customer value.

No customer purchases a product because deployment pipelines have become elegant. No customer upgrades because IAM policies are beautifully designed. No competitor loses market share because Kubernetes YAML looks sophisticated.

Customers care about products solving problems. Infrastructure only matters when it slows product delivery.

And infrastructure ownership creates endless opportunities for that to happen.

The Real Cost Is Delayed Customer Learning

The biggest cost of infrastructure complexity is not engineering effort. It is delayed learning.

Software companies win through feedback loops. Teams ship something. Customers react. Teams learn. Products improve.

The faster this cycle operates, the stronger the company becomes.
Infrastructure work interrupts that loop.

Every month spent building deployment systems is a month where customers are not using new features. Every quarter spent designing internal platforms delays customer feedback. Every architecture discussion delays real market signals.

This is where many organisations misunderstand velocity.

They look at sprint metrics. They measure tickets completed. They count engineering output.

But business speed is not measured through internal activity.

Business speed measures how quickly ideas become customer reality.
Infrastructure ownership slows that process dramatically.

And slower learning creates slower companies.

PaaS Changes the Optimisation Function

This is where Platform as a Service changes the equation.

PaaS forces organisations to optimise around shipping rather than infrastructure ownership. That shift matters more than most teams realise.

Instead of spending weeks designing deployment architecture, production teams connect repositories and deploy.

Instead of building pipelines manually, pipelines already exist.

Instead of designing scaling systems, scaling becomes infrastructure behaviour rather than engineering work.

Instead of repeatedly building foundations, infrastructure becomes a utility.

That sounds simple. It should be simple. Deployment should feel boring.

The fact that deployment often becomes a major organisational project is usually evidence of unnecessary complexity rather than unavoidable complexity.

PaaS providers remove entire categories of decisions.

Many engineers see that as a compromise. It is often the opposite.
Constraints create speed. Speed creates learning. Learning creates better products.

The Best Production Teams Remove Decisions

There is a common misconception that elite engineering organisations maximise options. The opposite is often true.

High-performing production teams aggressively eliminate decisions. They standardise. They create defaults. They remove unnecessary choices.

Because every decision carries a cost.

Cognitive load grows. Coordination increases. Meetings multiply.

Dependencies expand. Eventually, the workaround software becomes larger than the software itself.

PaaS systems follow a different philosophy. They intentionally reduce optionality.

That reduction creates focus. And focus creates product velocity.

Product velocity creates business outcomes.

The chain is straightforward. Too many organisations break it by introducing infrastructure ownership far too early.

Custom Infrastructure Usually Solves Problems Nobody Has Yet

One of the most expensive habits in software companies is solving future problems before current ones exist.

Teams build for scale before scale exists. They create multi-region architectures before international users arrive. They build deployment frameworks before deployment pain appears.

This usually comes from good intentions. Engineers want to avoid future rewrites.

The irony is that premature flexibility creates an immediate business slowdown.

A startup with twenty engineers should not operate like a company with ten thousand engineers. Yet many production teams copy infrastructure patterns from giant technology firms.

What gets ignored is context. Large technology companies have entire platform teams maintaining internal systems. They have thousands of engineers supporting infrastructure investments.

Most companies do not.

Copying technical architecture without copying organisational scale creates enormous inefficiency.

PaaS acts as protection against this behaviour. It prevents teams from accidentally becoming infrastructure companies before they become successful product companies.

The Real Competitive Advantage Is Shipping Faster

Companies rarely lose because infrastructure flexibility was insufficient. They lost because competitors learned faster.

Speed matters. Not speed in sprint or linear dashboards. Not speed in story points.

Actual speed. The ability to move ideas into production quickly.
The ability to test assumptions rapidly. The ability to learn continuously.

Shipping creates learning. Learning creates improvement. Improvement creates advantage.

Infrastructure complexity interrupts this loop. PaaS strengthens it.

This is why deployment decisions should never be treated as purely technical discussions. They are business decisions.

Infrastructure ownership affects company velocity. Velocity affects market outcomes.

The argument is not about servers. The argument is about competitive speed.

When PaaS Might Not Be the Right Choice

There are situations where PaaS can become limiting.

Organisations with highly specialised infrastructure requirements may require direct control over networking, security layers, hardware optimisation, or deployment behaviour.

Some industries have regulatory requirements that create unusually specific infrastructure needs.

Large organisations with mature platform engineering teams may also justify custom infrastructure investments.

There are also cases where platform costs become meaningful at very large scale.

These scenarios exist.

But many companies use edge cases as justification years before they become relevant.

They prepare for infrastructure problems they may never have while struggling to ship ordinary product releases today.

That sequence creates unnecessary friction.

Stop Building Infrastructure Businesses By Accident

Engineering culture often celebrates flexibility.

Flexibility sounds sophisticated. It sounds future-proof. It sounds like good systems thinking.

But flexibility carries a cost.

Every additional option creates complexity. Every additional decision slows movement. Every additional layer creates maintenance work.

Production teams should ask a simpler question. Does this help us ship customer-facing software faster? If the answer is no, it deserves scrutiny.

Too many companies accidentally build infrastructure ecosystems that optimise for hypothetical future needs.

Meanwhile, competitors deploy products, learn from customers and improve faster.

Shipping beats flexibility. And for many production teams, choosing a PaaS is one of the clearest ways to prove it.

Hope you enjoyed this article. You can connect with me on LinkedIn.

Every New Project Shouldn’t Feel Like Starting From Zero

Manish Shivanandhan — Mon, 18 May 2026 08:21:13 +0000

Every production engineering team knows the pattern.

A new project begins with energy. Product goals are clear. Deadlines are ambitious. Teams want to move quickly and deliver something customers can use.

Then the real work starts.

Infrastructure must be provisioned. CI/CD pipelines need to be set up. Secrets require management. Monitoring needs wiring. Databases need deployment. Logging needs configuration. Security policies need implementation. Networking rules need review.

Weeks disappear before users see anything useful.

Many organisations treat this as normal. They call it engineering rigour. They assume this operational setup phase is simply part of software development.

It is not.

For teams already running production systems, rebuilding infrastructure foundations for every new project is organisational waste. It is repetitive operational labour disguised as an engineering discipline.

The uncomfortable question is not, “How can we do this setup faster?”

The real question is: why are we still doing it ourselves at all?

This is where Platform as a Service changes the conversation.

A good PaaS shifts the starting point from “rebuild the foundations” to “start shipping.”

Because new projects should begin closer to customer value, not closer to infrastructure assembly.

In this article, we will look at why many production teams waste time rebuilding the same infrastructure for every new project, how PaaS helps remove that work, and why engineering teams should question if managing complex infrastructure still makes sense for most projects.

Starting From Zero Is a Process Failure

Most Teams Were Not Hired to Build Infrastructure

Software teams exist to solve business problems.

Customers do not care whether Kubernetes manifests were structured elegantly. They do not admire carefully designed Terraform modules. They do not celebrate handcrafted networking policies.

Customers care about outcomes.

They care about faster onboarding. Better recommendations. Smoother payments. Fewer bugs. Simpler workflows.

Yet many engineering organisations spend huge portions of time doing work customers never see.

Teams repeatedly create deployment pipelines. Configure environments. Manage certificates. Set up observability stacks. Tune infrastructure rules. Assemble cloud primitives.

Infrastructure matters. Reliability matters. Security matters.

The problem is duplication.

If every project independently recreates the same operational systems, organisations are rebuilding internal platforms over and over again without admitting it.

This behaviour has become so normalised that teams barely notice it anymore.

But rebuilding the same foundation repeatedly is not operational maturity.

It is inefficiency scaled across the organisation.

AWS Primitives Are Not a Competitive Advantage

Many teams confuse cloud ownership with strategic advantage.

Owning Kubernetes clusters does not create differentiation. Managing IAM rules does not create customer value. Writing infrastructure glue code does not strengthen market position.

These are implementation details.

Yet many organisations spend extraordinary energy managing them as if they are core business assets.

Some teams effectively become part-time infrastructure companies without realising it.

Their engineers slowly accumulate operational responsibilities until maintaining systems consumes more effort than delivering products.

The outcome becomes predictable. Infrastructure expands. Operational complexity grows. Delivery speed declines.

Nobody notices because the pain arrives gradually.

A team starts with one Kubernetes cluster. Then another environment appears. More deployment pipelines emerge. Additional tooling gets layered on top. Logging systems become fragmented. Monitoring evolves differently across products.

Eventually, teams spend increasing amounts of time maintaining systems they never intended to own.

Infrastructure ownership is often not a strategy. It is inertia.

Most Teams Should Not Be Managing Kubernetes

Kubernetes has become an engineering culture.

It appears in architecture diagrams, conference talks, hiring requirements, and internal roadmaps. Its adoption often feels inevitable.

But normalisation and necessity are not the same thing.

Many organisations adopted Kubernetes because industry momentum made it seem like the default path.

Not because they had workloads that required its complexity. But the result is predictable.

Small and medium teams end up managing orchestration systems designed for massive operational environments.

They maintain YAML configurations, networking layers, ingress systems, deployment strategies, and operational tooling stacks before delivering meaningful product value.

This has become strangely accepted.

A ten-person engineering team maintaining infrastructure patterns designed for internet-scale organisations should raise serious questions.

A small team pretending to be a platform team is an operational dysfunction.

Many companies adopted infrastructure complexity built for organisations operating at a vastly different scale.

They inherited the burden without inheriting the benefits.

PaaS Changes the Starting Point

Traditional infrastructure approaches force teams to think from the bottom upward.

Servers come first. Then operating systems. Then networking. Then deployment systems. Then monitoring.

Eventually, applications arrive.

PaaS reverses this sequence.

Developers begin with applications and business goals. The platform absorbs operational complexity.

Teams stop asking, “How do we provision resources?”

They start asking, “What problem are we solving?”

That sounds like a small shift. In practice, it changes everything.

A mature PaaS environment often provides deployment pipelines, integrated observability, databases, scaling behaviour, security controls, and operational standards before a team writes meaningful application logic.

Projects begin with product development rather than infrastructure construction.

That dramatically changes time-to-value.

Repetition Creates Hidden Organisational Waste

Organisations often underestimate operational waste because repetitive work feels familiar.

Setting up a deployment pipeline may consume only a few days. Configuring logging may feel routine. Creating security rules may seem manageable.

No individual task appears expensive. The cost appears when repetition scales.

If ten projects independently spend two weeks rebuilding nearly identical operational systems, months of engineering capacity disappear.

Those engineers could have shipped customer capabilities. They could have reduced friction. They could have tested new ideas.

Instead, they rebuilt plumbing.

Engineering teams understand leverage in nearly every other area. Nobody rewrites sorting algorithms for every application. Nobody recreates database engines from scratch. Nobody builds networking stacks repeatedly.

Reuse is accepted as basic engineering wisdom.

Infrastructure should not receive special treatment. Build once. Reuse many times.

PaaS simply applies software engineering principles to operational systems.

Standardisation Is Usually Faster Than Flexibility

Engineering teams often resist standardisation because they fear losing control.

Every project feels unique. Every system appears different. The desire for flexibility sounds reasonable.

But complete flexibility often creates operational chaos.

Different teams deploy applications differently. Logging behaves inconsistently. Monitoring varies across systems. Security implementations drift.

Documentation fragments. Onboarding slows. Incident response becomes harder. Complexity quietly accumulates.

PaaS introduces constraints, and many engineers instinctively resist constraints.

They should not.

Useful constraints often increase speed.

Predictable deployment patterns reduce confusion. Shared monitoring standards simplify troubleshooting. Consistent environments reduce cognitive overhead.

Developers spend less energy understanding infrastructure differences and more time delivering product functionality.

Consistency compounds.

Platform Teams Become Multipliers

Many organisations interpret PaaS as buying a vendor product.

That misses the bigger idea.

PaaS is fundamentally about creating reusable capabilities. Some organisations buy platforms. Others build internal platforms.

The principle remains the same.

A platform team creates systems once and allows everyone else to benefit.

Instead of dozens of product teams independently solving operational problems, a dedicated group centralises expertise and builds reusable solutions.

The effect becomes substantial.

One deployment improvement accelerates every future release. One observability improvement strengthens every application. One security enhancement protects every team.

Platform teams create organisational leverage.

Without this model, expertise stays fragmented. With it, expertise compounds.

Easier Starts Create More Innovation

Operational friction changes behaviour.

When launching projects becomes expensive, organisations become cautious.

Teams avoid experiments. Small ideas feel risky. Prototypes become difficult to justify.

Over time, innovation slows.

Not because organisations lack ideas. Because starting became too expensive.

Teams running mature platforms understand this relationship. Reducing startup friction increases experimentation. Smaller projects become practical. Learning cycles become shorter.

New ideas appear more often because the cost of testing them falls dramatically.

The easier it becomes to launch something, the more opportunities organisations create.

PaaS reduces startup friction.

That reduction changes culture.

When Specialised Control Actually Matters

There are exceptions.

Massive data platforms, highly specialised machine learning systems, and extremely customised environments may require lower-level infrastructure ownership.

Some workloads genuinely need deeper operational control. But these scenarios are exceptions, not defaults.

Too many teams inherit infrastructure complexity designed for edge cases and treat it as standard practice.

Most production applications do not need custom orchestration layers.

Most teams do not need to own Kubernetes. Most engineering groups do not need to spend weeks assembling infrastructure before shipping software.

The default assumption should be the opposite.

Starting From Zero Is a Process Failure

Many organisations normalise unnecessary operational drag.

Long setup cycles become accepted. Infrastructure duplication becomes routine. Cloud complexity becomes expected.

Eventually, teams stop questioning it.

They assume this is simply how engineering works. It is not.

If launching a new application requires weeks of foundational setup before customer value appears, that is not an engineering discipline.

The goal was never to become an infrastructure company. It was to ship software.

Why Your “Simple Deploy” Turned Into a Week of Infrastructure Work

Manish Shivanandhan — Tue, 05 May 2026 04:40:19 +0000

If you are running production workloads, this is for you.

Not side projects. Not early-stage experiments. Not a single-service app with low traffic.

This is for teams shipping real systems. Systems with users, uptime expectations, and release pressure.

Because at that stage, your deploy process is no longer a convenience. It is part of your product.

And right now, for most teams, it is the weakest part.

The Promise You Were Sold

Every modern stack makes the same promise.

Shipping is easy. Deploying is automated. Infrastructure is abstracted away.

Push your code. Watch it go live. That promise works , until it doesn’t.

And when it breaks, it does not fail gracefully. It expands.

A “simple deploy” turns into a multi-day investigation across systems you never intended to own.

Not because your team is careless. Because the model itself assumes you will take on more responsibility than it admits.

The Hidden Contract You Are Already Operating Under

When you deploy today, you are not just shipping code.

You are agreeing to run a distributed system of tools.

You own the build pipeline. The container lifecycle. The runtime configuration. The network rules. The secrets layer. The scaling logic. The observability stack.

Each of these is presented as a separate concern. In reality, they are tightly coupled.

And you are the only layer holding them together. That is the hidden contract.

You Are Already Acting Like a Platform Team

If your deploy process involves CI pipelines, container registries, cloud services, environment variables, and monitoring tools, you are not just an application team anymore. You are running a platform.

You are defining how code moves from commit to production. You are deciding how failures are handled. You are shaping how services communicate.

That is platform engineering work.

The issue is not that this work exists. The issue is that most teams take it on unintentionally, without the structure, tooling, or dedicated ownership a real platform team would require.

The Cost Is Not Complexity. It Is Time

It is easy to describe this problem as “complexity.”

That undersells it.

The real cost shows up in how your team spends its time.

Deploys that should take minutes stretch into hours. Then days.

Engineers context-switch from product work into debugging CI caches, fixing misconfigured secrets, or tracing network failures across services.

Releases slow down. Not because your team cannot build features, but because shipping them becomes unpredictable.

Onboarding gets harder. New engineers do not just learn the codebase. They have to learn your deployment system.

None of this appears on a roadmap. But it directly impacts how fast you can move.

Why “It Works on My Machine” Still Exists

We were supposed to have solved this.

Containers. Infrastructure as code. Reproducible builds.

Yet the gap between local and production still shows up at the worst possible moment.

Because the problem was never just environment parity.
It is system parity.

Your local setup does not include the same limits, permissions, network paths, or scaling behavior as production.

Those differences only surface when everything is wired together.
Which means they surface during deploys.

Fragmentation Is the Root Problem

Modern tooling did not remove infrastructure complexity.
It redistributed it.

Instead of managing servers, you manage integrations between services.

Instead of a single failure domain, you have many.

A deploy can fail because of a CI issue, a registry timeout, a secret misconfiguration, a networking rule, or a scaling limit.

Each lives in a different system. Each requires different context.
Individually, these tools are well-designed. Collectively, they form a system that is hard to reason about under pressure.

This Model Breaks as You Scale

This only works while your system is small.
But production systems do not stay small.

More services mean more pipelines. More configurations. More failure points.

Over time, the effort required to maintain your deployment system grows faster than the product itself.
That is the inflection point.

Where engineering time shifts away from building features and toward maintaining the machinery that ships them.

If you are already feeling that shift, it is not temporary. It is structural.

At some point, there is a question that becomes hard to ignore: Why are you still managing this yourself?

Not because you cannot. But because it is no longer clear that you should.

The Shift Toward Platforms

This is where Platform as a Service changes the model.

Not by adding more tools. But by taking ownership of the system those tools create.

A PaaS defines a path from code to production. That path is opinionated, constrained, and consistent.

Those constraints are not limitations. They are what remove entire categories of failure.
Instead of assembling a deployment pipeline, you adopt one.

What You Stop Paying For

Moving to a PaaS is often framed as convenience. For production teams, it is closer to cost removal.

You stop spending time deciding how builds run, how services are exposed, how scaling is configured, how logs are collected.

You stop debugging the integration points between those decisions. You trade flexibility for predictability.

And for most teams, predictability is the constraint that actually matters.

From Infrastructure Work Back to Product Work

The biggest change is not in your architecture.
It is in your allocation of engineering effort.

Time spent debugging deploys shifts back to building features.
Time spent maintaining pipelines shifts to improving the product.
Deploys become routine again.

Not because they are simpler in theory, but because the system around them is controlled.

Collapsing the Stack

The advantage of a PaaS is not abstraction. It is consolidation.

Build, deploy, runtime, and observability are integrated into a single system.

There are fewer layers to coordinate. Fewer places to look when something fails. And fewer decisions to get wrong.

Platforms like Sevalla, Railway, and Render are pushing this further by tightening the loop between code and production, reducing both the number of systems involved and the surface area developers need to understand.

The goal is operational clarity.

The Trade-Off You Are Actually Making

The common objection is control. And it is valid.

You give up the ability to customize every layer of your infrastructure.

But in practice, most teams are not using that control to create differentiation. They are using it to keep a fragile system running, and it’s what keeps teams stuck maintaining systems they shouldn’t own.

Every custom configuration adds another failure point. Another dependency. Another thing to maintain under pressure.
The trade-off is not control versus convenience.

It is control versus reliability.

When This Becomes Urgent

You do not need a major outage to justify a change.
The signals show up earlier.

Deploys feel unpredictable. Releases slow down. Engineers spend more time on pipelines than product logic. Onboarding takes longer than it should.

These are not isolated issues.

They are indicators that your current model is not scaling with your system.

What a “Simple Deploy” Actually Means

A simple deploy is not one that feels easy when everything works. It is one that continues to work as your system grows.

It is predictable. Failures are rare. When they happen, they are easy to diagnose.

And most importantly, it does not require your engineers to think about infrastructure to ship code.

That outcome is not achieved by adding more tools. It is achieved by reducing the system you have to manage.

Closing Thought

Your deploy did not turn into a week of infrastructure work because you missed something. It turned into that because you are operating a model that expects you to.

You can continue investing in that model. Or you can adopt one where deploying is a solved problem.

For production teams, that is no longer a philosophical choice. It is an operational one.

The Hidden Tax of Infrastructure: Why Your Team Shouldn’t Be Running It Anymore

Manish Shivanandhan — Wed, 22 Apr 2026 06:19:29 +0000

Most engineering teams do not set out to manage infrastructure. They start with a product idea, a customer need, or a business problem.

Infrastructure enters the picture as a means to an end. Servers need to be provisioned. Databases need to be configured. Networks need to be secured. At first, this work feels necessary and even empowering. It gives teams control.

But over time, that control turns into a burden.

What begins as a few Terraform scripts or cloud console clicks evolves into a growing layer of responsibility.

Teams find themselves maintaining deployment pipelines, debugging networking issues, rotating credentials, patching systems, and responding to incidents unrelated to their product logic.

This is the hidden tax of infrastructure. It is not a line item in your budget, but it is paid every day in engineering time, cognitive load, and lost focus.

Infrastructure is not a one-time cost

A common mistake teams make is treating infrastructure as a setup task. Something you “get right” once and move on from.

In reality, infrastructure is a continuous system. It changes with scale, traffic patterns, security threats, and team structure.

Every component you introduce adds a long tail of operational work. A load balancer is not just a load balancer. It requires configuration tuning, monitoring, failover planning, and periodic upgrades. A database is not just storage. It brings backup strategies, replication concerns, indexing decisions, and performance tuning.

Even with infrastructure-as-code tools, the maintenance burden does not disappear. It becomes codified, but it still exists. Engineers must review changes, manage state, handle drift, and respond when things break.

The cost compounds quietly. It shows up in slower delivery cycles, longer onboarding times for new engineers, and increased risk during deployments. It is not visible in sprint planning, but it is always there.

The cognitive load problem

One of the most underestimated aspects of infrastructure management is cognitive load.

Modern systems are complex. Distributed architectures, microservices, container orchestration, and multi-region deployments all introduce layers of abstraction that engineers must understand.

When a team owns its infrastructure, every engineer becomes partially responsible for this complexity. Even if you have dedicated platform engineers, application developers still need to understand enough to debug issues and deploy changes safely.

This context switching has a real cost. An engineer working on a feature must also think about container resource limits, networking rules, observability gaps, and failure modes. Instead of focusing on business logic, they are juggling operational concerns.

Cognitive load slows teams down. It increases the chance of mistakes. It makes systems harder to reason about. And it reduces the time engineers spend on the work that actually differentiates your product.

Reliability is harder than it looks

Running infrastructure in production means owning reliability. This includes uptime, latency, data integrity, and incident response. Many teams underestimate how difficult this is to do well.

High availability is not just about redundancy. It requires careful design, testing, and ongoing validation. Failover mechanisms must be exercised. Monitoring systems must be tuned to detect real issues without creating noise. Incident response processes must be defined and practised.

When something goes wrong, the cost is immediate and visible. Engineers are pulled into debugging sessions. Customers are affected. Business metrics drop. Postmortems are written. Action items are created, which often add more infrastructure complexity.

Over time, teams build layers of safeguards and tooling to improve reliability. But each layer adds more to manage. The system becomes harder to change. The risk of unintended consequences increases.

This is the paradox of self-managed infrastructure. The more you invest in reliability, the more complex your system becomes, and the more effort it takes to maintain that reliability.

Security and compliance never stand still

Security is another dimension where the hidden tax becomes clear. Threats evolve constantly. Best practices change. Compliance requirements grow more stringent.

When you run your own infrastructure, you are responsible for staying ahead of these changes. This includes patching systems, managing access controls, encrypting data, auditing logs, and responding to vulnerabilities.

Even small gaps can have serious consequences. A misconfigured permission, an outdated dependency, or an exposed endpoint can lead to breaches. The cost of prevention is an ongoing effort. The cost of failure can be catastrophic.

Compliance adds another layer. For teams in regulated industries, infrastructure must meet specific standards. This often requires documentation, audits, and controls that go beyond basic security practices.

All of this work is necessary, but it does not directly contribute to your product’s value. It is part of the hidden tax you pay for owning infrastructure.

The illusion of control

One of the main reasons teams continue to manage their own infrastructure is the belief that it gives them control. They can customise everything. They can optimise for their specific needs. They are not dependent on external platforms.

While this is true in theory, in practice, the level of control is often overstated. Most teams do not need deep customisation at the infrastructure level. They need reliability, scalability, and predictable behaviour.

The control you gain comes at the cost of responsibility. Every customisation must be maintained. Every optimisation must be monitored. Every deviation from standard patterns increases the risk of issues.

In many cases, teams end up recreating capabilities that are already available in managed platforms. They build internal tooling for deployment, scaling, and monitoring, only to maintain it indefinitely.

The question is not whether you can manage your own infrastructure. It is whether you should. Most small to mid-sized teams should not be managing infrastructure at all. If it is not your competitive advantage, it is a distraction.

The rise of PaaS as an alternative

Platform-as-a-Service, or PaaS, changes the equation. Instead of managing infrastructure directly, teams deploy applications to a platform that handles the underlying complexity.

With PaaS, concerns like provisioning, scaling, load balancing, and patching are abstracted away. Engineers focus on code and configuration, not on servers and networks.

This does not eliminate all operational work, but it shifts the responsibility. The platform provider handles the heavy lifting. Your team benefits from standardised, battle-tested infrastructure without having to build and maintain it.

PaaS also reduces cognitive load. Developers interact with a simpler interface. Deployments become more predictable. Observability is often built in. This allows teams to move faster and with greater confidence.

Importantly, PaaS aligns infrastructure with application needs. Instead of designing infrastructure first and fitting applications into it, teams define what their application requires, and the platform provides it.

Heroku was the first to bring PaaS mainstream. Since Heroku is shutting down, I moved to Sevalla for its simplicity and the speed with which new features, especially agentic tools, are introduced. Here is a list of alternatives.

Speed is a competitive advantage

In most markets, speed matters. The ability to ship features quickly, respond to feedback, and iterate on ideas is a key competitive advantage.

Infrastructure management can slow this down. Changes require coordination. Deployments carry risk. Debugging issues takes time away from development.

By reducing the infrastructure burden, PaaS enables faster delivery. Teams can deploy changes more frequently. They can experiment with new ideas without worrying about underlying systems. They can recover from failures more quickly.

This is not just about engineering efficiency. It has a direct impact on business outcomes. Faster delivery leads to better products, happier customers, and a stronger market position.

Cost is more than the cloud bills

When teams evaluate infrastructure strategies, they often focus on direct costs. Cloud bills, reserved instances, and resource utilisation are measured and optimised.

But the hidden tax of infrastructure is mostly indirect. It includes engineering time spent on maintenance, the opportunity cost of delayed features, and the risk of outages and security incidents.

These costs are harder to quantify, but they are often larger than the direct costs. A single incident can consume days of engineering time. A delayed feature can impact revenue. A security breach can damage a reputation.

PaaS may appear more expensive on paper, but it often reduces total cost when you account for these hidden factors. It shifts spending from operational overhead to product development.

Rethinking ownership

The core question is not about tools or technologies. It is about ownership. What should your team own, and what should it delegate?

Your product is your core asset. It is what differentiates you in the market. Infrastructure, while critical, is a means to support that product.

By continuing to manage infrastructure, teams take on responsibilities that do not directly contribute to their goals. They pay the hidden tax in time, focus, and risk.

PaaS offers a way to rebalance this. It allows teams to delegate infrastructure concerns and focus on building value.

The shift is not always easy. It requires changes in mindset, tooling, and processes. But for many teams, it is a necessary step.

Because the real cost of infrastructure is not what you pay your cloud provider. It is what you give up to run it yourself.

From Metrics to Meaning: How PaaS Helps Developers Understand Production

Manish Shivanandhan — Mon, 20 Apr 2026 08:25:47 +0000

Modern production systems generate more data than most developers can realistically process.

Every request emits logs. Every service exports metrics. Every dependency introduces another layer of signals.

In theory, this should make systems easier to understand. In practice, it does the opposite.

Dashboards become dense, alerts become noisy, and when something breaks, the same questions still come up. What is actually wrong? Who is affected? Where do you even start?

The problem is not observability. It is interpretation.

Most teams are not short on metrics. They are short on meaning.

And that gap exists because developers are often forced to reason about infrastructure when they should be focused on application behaviour.

Metrics exist to describe systems, but without the right level of abstraction, they become another layer of complexity.

This is where modern PaaS platforms change the equation.

They do not remove metrics. They turn them into signals that developers can actually use.

This article breaks down five metrics that consistently matter in production systems. More importantly, it shows how a PaaS helps translate these metrics into something actionable, without requiring developers to act as infrastructure operators.

I’ll be using the Sevalla dashboard to explain these metrics but other platforms like Railway and Render will have similar metrics.

Latency Becomes a Clear Performance Signal

Latency is the most direct representation of user experience. It tells you how long your system takes to respond.

When latency increases, users feel it immediately. Pages slow down. APIs become unreliable. Even small delays impact engagement.

Most developers know to look at percentiles like p95 or p99 instead of averages. The slowest requests are what define perceived performance.

But in many environments, understanding latency is not straightforward.

A spike could come from inefficient code. Or from cold starts. Or from scaling delays. Or from network routing issues. Developers are forced to investigate layers they did not build.

This is where a PaaS changes the role of latency.

Instead of being a starting point for infrastructure debugging, latency becomes a clean signal of application performance. Scaling, routing, and resource allocation are handled by the platform. What remains is a clearer relationship between code and outcome.

When latency increases, developers can focus on what they actually control. Queries, logic, dependencies.

The metric stays the same. The meaning becomes clearer.

Error Rate Becomes a Reliable Indicator of Failure

Error rate answers a simple question. Is the system working or not?

It is usually measured as the percentage of requests that fail due to server-side issues. These are failures users cannot recover from. A broken checkout flow or a failed API call directly impacts trust.

In theory, error rate should be one of the easiest metrics to act on.

In practice, it rarely is.

Errors can come from application bugs, but also from timeouts, resource limits, failed deployments, or unstable instances. Developers end up correlating errors with infrastructure events just to understand what happened.

This slows everything down.

A PaaS reduces this ambiguity.

Failures caused by scaling, instance crashes, or transient infrastructure issues are handled at the platform level. Retries, isolation, and recovery mechanisms are built in.

What remains is a tighter link between error rate and application correctness.

When the error rate increases, it is far more likely to be something in the code or a dependency, not an invisible infrastructure issue.

This shifts the error rate from a noisy metric into a reliable signal.

Throughput Becomes Context Instead of a Problem

Throughput measures how many requests your system handles over time.

It provides context for everything else. Latency and error rate only make sense when you know how much traffic the system is handling.

A spike in latency during high traffic is expected. The same spike during low traffic is a warning sign.

But in many systems, throughput introduces operational complexity.

Traffic changes require scaling decisions. Teams define autoscaling rules, tune thresholds, and try to predict demand. When things go wrong, they revisit those decisions.

Developers end up thinking about capacity instead of behaviour.

A PaaS shifts this responsibility.

Scaling is automatic. Traffic spikes are absorbed by the platform. Developers do not need to decide how many instances should be running or when to scale.

Throughput becomes what it should be. Context.

It helps explain what is happening, without forcing developers to manage how the system adapts.

Resource Utilisation Moves Out of the Critical Path

Resource utilization measures how much CPU, memory, and I/O your system consumes.

Traditionally, this has been central to operating systems. High CPU or memory usage signals potential issues. Teams monitor these metrics to avoid failures and plan scaling.

But for most developers, resource utilization is not where value is created.

Yet in many environments, developers are still responsible for interpreting these signals. They tune memory limits, investigate CPU spikes, and try to optimise resource usage to keep systems stable.

This is operational work.

A PaaS changes the role of these metrics.

Resource management is handled by the platform. Allocation, scaling, and isolation happen automatically. Developers do not need to constantly watch CPU graphs or memory charts to keep the system running.

These metrics still exist, but they move into the background.

They become diagnostic tools rather than primary signals.

Developers can focus on performance at the application level, instead of managing how infrastructure behaves under load.

Instance Health Becomes Invisible by Design

Instance health tracks restarts, crashes, and lifecycle events.

In many systems, this is a critical metric. Frequent restarts indicate instability. Memory leaks, crashes, or resource exhaustion often show up here first.

Teams monitor instance health to catch issues early and prevent cascading failures.

But this also reveals something important.

Developers are aware of, and responsible for, the lifecycle of infrastructure.

They track restarts, investigate crashes, and try to stabilise the system manually.

A PaaS removes this responsibility.

Unhealthy instances are restarted automatically. Load is redistributed. Capacity is maintained without manual intervention.

Instance health does not disappear, but it no longer requires constant attention.

It becomes part of the platform’s internal behaviour, not something developers need to actively manage.

From Metrics to Meaning

These five metrics have not changed.

Latency still reflects performance. Error rate still reflects correctness. Throughput still reflects demand. Resource utilization still reflects efficiency. Instance health still reflects stability.

What changes is how much work it takes to interpret them.

In lower-level environments, developers have to connect these signals themselves. A latency spike leads to checking throughput, then resource usage, then instance behaviour. Each step requires context, assumptions, and time.

This is where complexity accumulates.

A PaaS reduces that gap.

It handles scaling, recovery, and resource management so that metrics map more directly to application behaviour. The signals become easier to interpret because fewer variables are exposed.

Instead of asking multiple questions across layers, developers can move more directly from symptom to cause.

Why This Matters for Developers

Most developers do not want to manage infrastructure.

They want to build features, ship improvements, and respond to user needs.

But as systems grow, operational responsibility expands. Monitoring becomes more complex. Debugging requires more context. A significant portion of time shifts from building to maintaining.

Metrics are part of this shift.

They are necessary, but they also reflect how much of the system you are responsible for understanding.

A PaaS does not eliminate metrics. It reduces the effort required to make sense of them.

It ensures that when something changes in production, the signals developers see are closer to the reality they care about.

Application behaviour. User experience. System correctness.

The Real Advantage Is Clarity

The goal is not to have fewer metrics.

It is to have metrics that mean something without requiring deep infrastructure reasoning.

These five metrics form a complete picture of system health. But their real value depends on how directly they map to what developers control.

The more layers you have to think about, the harder mapping becomes.

A good PaaS removes those layers.

It turns metrics from raw data into usable signals.

And that shift from metrics to meaning is what allows developers to understand production systems without being buried under them.

From Prompt Engineer to Agent Engineer: The 7 Skills You Need to Build AI Agents

Manish Shivanandhan — Wed, 15 Apr 2026 20:12:20 +0000

Discover the key skills you need to build AI agents that thrive in real-world environments, moving beyond crafting prompts to engineering robust systems.

The world of artificial intelligence is rapidly evolving. Just a few years ago, being a “prompt engineer” was about crafting clever instructions for a language model.

But times have changed. Today, building AI agents that function in the real world requires much more.

The role is far broader and demands a diverse set of skills. This transition from a focus on crafting prompts to engineering sophisticated systems is like moving from following a recipe to becoming a chef.

As we delve into these seven essential skills, you’ll see exactly where to focus your efforts to become a successful “agent engineer.”

The Changing Landscape of AI Engineering

There’s an identity shift happening in technology today. What once was the realm of prompt engineers is now evolving into something much broader—agent engineering.

In the past, crafting well-designed prompts was enough when working with general-purpose AI models like GPT. However, today’s AI agents are not just responding to questions; they’re performing actions, making decisions, interacting with databases, and much more. This means the skills required have expanded significantly.

When building AI systems that perform real functions, like booking flights or processing refunds, writing effective prompts is just a starting point. The real challenge lies in engineering systems that can function seamlessly and handle unexpected situations.

It’s like moving from being a cook who follows recipes to becoming a chef who understands all aspects of culinary creation. A chef knows about ingredients, techniques, and workflows, and this is the mindset you need to become an agent engineer.

System Design: The Foundation of AI Agents

Effective system design is the cornerstone of building reliable AI agents.

When constructing an agent, you’re creating a complex system with multiple components that must work together harmoniously. This involves an architecture in which data flows smoothly, and every component understands its role. You might have a language model making decisions, tools executing actions, and databases storing states. Like an orchestra, these elements must harmonise without stepping on each other’s toes.

Thinking of it like designing a complex software backend can be helpful. You’ll deal with situations where one component may fail and must handle requests that require coordination between several parts. If you have experience with system design, this might sound familiar. If not, it is crucial to start learning, as software systems, like AI agents, require solid structure and thoughtful orchestration.

Here is a wonderful resource put together on System Design - https://github.com/karanpratapsingh/system-design

Tool and Contract Design: Establishing Clear Communication

Agents interact with the world through tools, and each tool operates on a contract. A contract is a set of clear expectations about inputs and outputs.

The importance of precise tool design cannot be overstated. Vague contracts lead agents to make assumptions, which can be catastrophic, especially in critical tasks like financial transactions.

For example, if a tool’s input schema says “user ID is a string,” the agent might interpret it in various unintended ways. But by specifying a pattern that must be matched, you guide the agent toward consistent, error-free operation.

Clear tool contracts are like the terms of a handshake agreement. When both sides know exactly what’s expected, operations run smoothly, reducing room for ambiguity and errors. This precision in design ensures that your agents function effectively without resorting to guesswork or imagination, qualities that are less than ideal in automated systems.

Mastering Retrieval Engineering

Retrieval Engineering, specifically Retrieval Augmented Generation (RAG), is a critical component in enhancing an agent’s performance. Instead of relying solely on pre-trained knowledge, RAG involves fetching relevant documents to enrich the model’s context. The quality of these retrieved documents directly affects the agent’s output, making this a complex yet essential skill.

Achieving optimal retrieval involves several factors. Documents must be split into appropriately-sized chunks—large enough to maintain context but small enough to avoid obscuring important details.

Additionally, embeddings, which the model uses to represent similar concepts, must be accurately aligned to ensure meaningful context. Finally, re-ranking mechanisms ensure the most relevant documents are prioritised. This deep discipline requires careful attention, but understanding its basics can significantly enhance your agent’s performance.

Reliability Engineering: Ensuring Consistent Agent Performance

Reliability is a non-negotiable aspect of agent engineering.

APIs can fail, networks can time out, and external services may go down unexpectedly. These situations can render your agent ineffective or stuck, trying to execute an unachievable task. Therefore, reliability engineering principles like implementing retry logic with back-off, setting timeouts to prevent indefinite hang-ups, and creating fallback paths are critical.

Think of these techniques as proactive measures to protect your system from cascading failures and ensure your agent can maintain a high level of performance, even under less-than-ideal conditions. While these concepts may be familiar to those with a background in backend development, they are crucial for any aspiring agent engineer who wishes to build robust and resilient systems.

Security and Safety: Protecting Your AI Systems

Security is a crucial concern in agent engineering.

Agents can be targets for attacks, such as prompt injections, where malicious instructions are embedded in user input to mislead the system. Without proper defences, an agent might inadvertently comply with harmful requests. Thus, it’s essential to apply security engineering principles to a new kind of system.

This involves implementing input validation to filter malicious requests, output filters to ensure responses adhere to policy, and permission boundaries to limit the agent’s actions. These measures protect your system from unauthorised manipulation and ensure the agent functions within safe and compliant parameters.

In this sense, security engineering is about anticipating potential vulnerabilities and reinforcing your system to prevent misuse.

Evaluation, Observability, and Product Thinking

An agent’s effectiveness can only be improved if its performance is well-evaluated. Techniques for evaluation, along with observability tools, allow you to track your agent’s actions, understand why decisions were made, and identify areas for improvement.

Tracing every decision, logging each tool interaction, and keeping a comprehensive timeline are essential practices for effective debugging and enhancing performance.

Beyond technical prowess, product thinking emphasises the human aspect of agent engineering. Agents should align with user expectations, offering clear feedback when confident or uncertain, and handle errors gracefully. Product thinking involves designing user-friendly systems that build trust and encourage use, even when unpredictable AI behaviour is involved.

Conclusion

Transitioning from a prompt engineer to a full-fledged agent engineer involves mastering a diverse skill set, much like a chef mastering the culinary arts.

By understanding system architecture, designing precise tool contracts, optimising information retrieval, ensuring reliable operations, fortifying security, and integrating evaluation and product thinking, you’re well on your way to building AI agents that perform seamlessly in the real world.

These seven skills are your recipe for success, paving the way for creating robust, reliable, and human-friendly AI systems. As the expectations for AI systems evolve, so too must our skills. The future belongs to those who adapt and grow with it.

Getting Started with Terraform: From Zero to Production

Manish Shivanandhan — Mon, 13 Apr 2026 09:28:54 +0000

Infrastructure has undergone a fundamental shift over the past decade.

What was once configured manually through dashboards and shell access is now defined declaratively in code. This shift is not just about convenience. It is about repeatability, auditability, and control.

Terraform sits at the center of this transformation. It allows you to define infrastructure using configuration files, apply those configurations consistently across environments, and evolve systems safely over time.

For teams building modern applications, especially on platform abstractions, Terraform becomes the control plane for everything from application deployment to databases and networking.

The Terraform provider from Sevalla extends this model by allowing teams to manage the entire application platform as code, not just underlying infrastructure. It enables you to define applications, databases, networking, storage, and deployment workflows in a single, unified configuration.

Instead of stitching together multiple tools or relying on manual setup, everything from code deployment to traffic routing and environment configuration can be expressed declaratively. This creates a consistent, repeatable system where environments can be replicated easily, changes are version-controlled, and production setups can evolve safely over time.
This article walks through how to go from zero to a production-ready setup using Terraform and the Sevalla Terraform Provider, focusing on practical concepts rather than theory.

What Terraform Actually Does

Terraform is an infrastructure-as-code tool that translates configuration files into real infrastructure. You describe the desired state of your system, and Terraform figures out how to achieve it.
At a high level, Terraform operates in three phases.
First, it initializes the working directory and downloads required providers. Providers are plugins that allow Terraform to interact with specific platforms.
Next, it creates an execution plan. This plan shows what resources will be created, modified, or destroyed to match your configuration.
Finally, it applies the plan, making the necessary API calls to bring your infrastructure into the desired state.
The key idea is that Terraform is declarative. You define what you want, not how to do it. Terraform handles the orchestration.
This abstraction becomes extremely powerful as systems grow more complex.

Setting Up Terraform for the First Time

Getting started with Terraform requires very little setup. You install the CLI, create a working directory, and define a basic configuration.
A Terraform configuration is written in HCL, a domain-specific language designed to be human-readable. Even a simple configuration establishes the core concepts.
You define the required provider, configure authentication, and declare resources.
Here is a minimal example that provisions an application using a managed platform provider.

terraform {
 required_providers {
   sevalla = {
     source  = "sevalla-hosting/sevalla"
     version = "~> 1.0"
   }
 }
}

provider "sevalla" {
}
data "sevalla_clusters" "all" {}
resource "sevalla_application" "web" {
 display_name = "my-web-app"
 cluster_id   = data.sevalla_clusters.all.clusters[0].id
 source       = "publicGit"
 repo_url     = "https://github.com/example/app"
}

This configuration does several things.
It declares the provider, which tells Terraform how to communicate with the platform. It fetches available clusters using a data source. It defines an application resource that points to a Git repository.
Even at this stage, you are already defining infrastructure in a reproducible way.
To execute this configuration, you run three commands.
You initialize the project, generate a plan, and apply it.

export SEVALLA_API_KEY="your-api-key"
terraform init
terraform plan
terraform apply

After applying, your application is deployed without manual steps.

Understanding Providers, Resources, and Data Sources

Terraform revolves around three core constructs.
Providers act as the bridge between Terraform and external systems. They expose APIs in a structured way that Terraform can use.
Resources represent the infrastructure you want to create. These are the building blocks of your system. Applications, databases, load balancers, and storage buckets are all modeled as resources.
Data sources allow you to query existing infrastructure. Instead of creating something new, you retrieve information that can be used elsewhere in your configuration.
The combination of these constructs allows you to build flexible and composable systems.
For example, you can fetch a list of available clusters using a data source and then dynamically assign your application to one of them. This reduces hardcoding and improves portability.
As your configuration grows, these abstractions help you maintain clarity and structure.

Building a Real Application Stack

A production system is rarely just a single application. It typically includes multiple components that need to work together.
With Terraform, you can define the entire stack in one place.
You might start with an application, then add a managed database, connect them internally, and expose the application through a load balancer.
A simplified flow looks like this.
You define the application resource that pulls code from a repository. You provision a database resource, such as PostgreSQL or Redis. You establish an internal connection between the application and the database. You configure environment variables for credentials. You optionally add a custom domain or routing layer.
Each of these components is a resource, and Terraform ensures they are created in the correct order.
This approach eliminates configuration drift. Instead of manually setting up each component, everything is defined in code and version-controlled.
It also makes environments consistent. Your staging and production setups can be identical except for a few variables.

Managing Configuration and Secrets

Production systems require configuration. This includes environment variables, API keys, and connection strings.
Terraform provides multiple ways to handle this.
You can define variables in your configuration and pass values at runtime. Sensitive values, such as API keys, are typically injected via environment variables.
For example, authentication is handled through an API key that can be set as an environment variable.

export SEVALLA_API_KEY="your-api-key"

This avoids hardcoding credentials in configuration files.
You can also define environment variables as part of your infrastructure. This allows you to configure applications consistently across environments.
The important principle is separation of concerns. Infrastructure definitions should remain clean, while sensitive data is managed securely.

Scaling and Process Configuration

Modern applications often consist of multiple processes. A web server handles incoming requests, background workers process jobs, and scheduled tasks run periodically.
Terraform allows you to define these processes explicitly.
You can configure different process types, allocate resources, and scale them independently. This is particularly useful for handling variable workloads.
For example, you might scale web processes based on incoming traffic while keeping background workers at a steady level.
By defining this in code, scaling becomes predictable and repeatable.
You avoid manual intervention and ensure that your system behaves consistently under load.

Adding Networking and Traffic Management

As systems grow, managing traffic becomes more important.
Terraform enables you to define networking components such as load balancers and routing rules. You can map domains to applications, distribute traffic across multiple services, and control access.
This is essential for production readiness.
A load balancer can improve availability by distributing traffic across instances. Domain configuration ensures that users can access your application through a stable endpoint.
You can also define restrictions, such as IP allowlists, to enhance security.
All of this is managed declaratively, which reduces the risk of misconfiguration.

Pipelines and Continuous Deployment

Production systems require reliable deployment workflows.
Terraform can be used to define deployment pipelines and stages. This allows you to model how code moves from development to production.
You can define multiple stages, associate applications with each stage, and control how deployments are triggered.
This brings infrastructure and deployment logic into a single system.
Instead of relying on external scripts or manual processes, everything is defined in a structured and version-controlled way.
It also improves traceability. You can see exactly how a system is configured and how changes are applied over time.

From Configuration to Production

Moving from a simple setup to production involves more than just adding resources. It requires discipline in how you manage infrastructure.
Version control becomes critical. Every change to your infrastructure should go through code review. This reduces the risk of introducing breaking changes.
State management is another key aspect. Terraform keeps track of the current state of your infrastructure. This state must be stored securely and consistently, especially in team environments.
You also need to think about environment separation. Development, staging, and production should be isolated but defined using similar configurations.
Finally, observability should be integrated from the start. While Terraform provisions infrastructure, you need monitoring and logging to understand how it behaves in production.

Why Terraform Scales with You

Terraform works well for small projects, but its real value becomes apparent as systems grow.
As you add more services, environments, and dependencies, manual management becomes unsustainable. Terraform provides a structured way to manage this complexity.
It enforces consistency. It enables automation. It creates a single source of truth for your infrastructure.
Most importantly, it allows teams to move faster without sacrificing reliability.
By defining infrastructure as code, you reduce ambiguity. You make systems easier to understand, easier to debug, and easier to evolve.
That is what takes you from zero to production in a way that actually scales.

Building AI Agents That Can Control Cloud Infrastructure

Manish Shivanandhan — Thu, 26 Mar 2026 05:36:48 +0000

Cloud infrastructure has become deeply programmable over the past decade.

Nearly every platform exposes APIs that allow developers to create applications, provision databases, configure networking, and retrieve metrics.

This shift enabled automation via Infrastructure as Code and CI/CD pipelines, allowing teams to manage systems through scripts rather than dashboards.

Now another layer of automation is emerging. AI agents are starting to participate directly in development workflows. These agents can read codebases, generate implementations, run terminal commands, and help debug systems. The next logical step is to allow them to interact with the infrastructure itself.

Instead of manually inspecting dashboards or remembering complex command-line syntax, developers can ask an AI agent to check system state, deploy services, or retrieve metrics. The agent performs these tasks by interacting with cloud APIs on behalf of the user.

This capability opens the door to a new type of workflow where infrastructure becomes conversational, programmable, and deeply integrated into development environments.

In this article, we will explore how AI agents can interact with cloud infrastructure through APIs, the challenges of exposing large APIs to AI systems, and how architectures like MCP make it possible for agents to discover and execute infrastructure operations safely.

We will also look at a practical example of connecting an AI agent to a cloud platform like Sevalla using the search-and-execute pattern.

AI Agents Are Becoming Part of the Development Environment

Modern developer tools increasingly embed AI assistants directly inside coding environments. Editors such as Cursor, Windsurf, and Claude Code allow developers to ask questions about their projects, generate new code, and execute commands without leaving the editor.

Instead of manually navigating documentation or writing boilerplate code, developers can simply describe what they want. The AI interprets the request and produces the necessary actions.

This approach is already common for tasks like writing functions, refactoring code, or debugging errors. However, infrastructure management is still largely handled through dashboards, terminal commands, or external tooling.

If AI agents are going to assist developers effectively, they need access to the same systems developers interact with every day. That means accessing APIs that manage applications, databases, deployments, and other infrastructure resources.

The challenge is providing that access in a structured and scalable way.

Connecting AI Agents to External Systems

AI agents do not inherently know how to interact with external services. They need a framework that allows them to call tools and access data safely.

Model Context Protocol, or MCP, provides one such framework. MCP is designed to let AI assistants connect to external tools in a standardized way.

An MCP server exposes tools that an AI agent can call when it needs information or wants to act. These tools might retrieve data from a database, query logs, interact with APIs, or execute commands on a remote system.

When the AI agent receives a request from the user, it determines which tool to call and executes that tool through the MCP server. The results are returned to the agent, which can then continue reasoning about the problem.

This architecture allows AI assistants to interact with complex systems while maintaining a clear boundary between the agent and the external environment.

The Challenge of Large Cloud APIs

While MCP enables connecting AI agents to infrastructure systems, cloud platforms introduce an additional challenge.

Most cloud platforms expose large APIs with many endpoints. A typical platform might include endpoints for managing applications, databases, storage, networking, domains, metrics, logs, and deployment pipelines.

If an MCP server exposes each endpoint as a separate tool, the number of tools can quickly grow into the hundreds.

This creates several problems. First, the AI agent must understand the purpose and parameters of every available tool before deciding which one to use. This increases the amount of context required for the agent to operate effectively.

Second, maintaining hundreds of tools becomes difficult for developers who build and maintain the MCP server.

Third, the system becomes rigid. Every time a new API endpoint is added, a new tool must also be created and documented.

For large APIs, this approach quickly becomes impractical.

A Simpler Pattern for API Access

A different architecture solves this problem by dramatically reducing the number of tools exposed to the AI.

Instead of providing a separate tool for every API endpoint, the MCP server exposes only two capabilities.

The first capability allows the agent to search the API specification. This lets the agent discover available endpoints, understand parameters, and inspect request or response schemas.

The second capability allows the agent to execute code that calls the API.

In this model, the AI agent dynamically generates the code required to call the API. Because the agent can search the specification and write its own API calls, the MCP server does not need to define individual tools for every endpoint.

This pattern drastically reduces the complexity of the integration while still giving the agent full access to the underlying platform.

Why Sandboxed Code Execution Is Important

Allowing AI agents to generate and execute code raises important security considerations.

If the generated code runs unrestricted, it could potentially access sensitive parts of the system or perform unintended operations. To prevent this, the execution environment must be carefully controlled.

A common solution is running the generated code inside a sandboxed environment. In this setup, the code runs in an isolated runtime with limited permissions. The environment exposes only specific functions that allow interaction with the platform’s API.

Because the code cannot access the host system directly, the risk of unintended behavior is greatly reduced. At the same time, the AI agent retains the flexibility to generate custom API calls as needed.

This combination of dynamic code generation and sandboxed execution makes it possible for AI agents to interact with complex APIs safely.

Practical Example with Sevalla

A practical implementation of this architecture can be seen in the Sevalla MCP server, which exposes a cloud platform’s API to AI agents through the search-and-execute pattern.

Sevalla is a PaaS provider designed for developers shipping production applications. It offers app hosting, database, object storage, and static site hosting for your projects. We also have other options, such as AWS and Azure, that come with their own MCP tools.

Instead of registering hundreds of tools for every API endpoint, the server provides only two tools that allow the AI agent to explore and interact with the entire platform. Find the full documentation for Sevalla’s MCP server here.

The first tool, search, allows the agent to query the platform’s OpenAPI specification. Through this interface the agent can discover available endpoints, understand parameters, and inspect response schemas.

Because the API specification is searchable, the agent does not need to know the structure of the platform’s API in advance. It can explore the API dynamically based on the task it needs to perform.

For example, if the user asks the agent to list all applications running in their account, the agent can begin by searching the API specification.

const endpoints = await sevalla.search("list all applications")

The result returns the relevant API definitions, including the correct path and parameters required for the request. Once the agent understands which endpoint to use, it can generate the necessary API call.

The second tool, execute, runs JavaScript inside a sandboxed V8 environment. Within this environment the agent can call the API using a helper function provided by the platform.

const apps = await sevalla.request({ method: "GET", path: "/applications" })
Because the code runs inside an isolated V8 sandbox, the generated script cannot access the host system. The only permitted interaction is through the API helper function. This ensures that the AI agent can perform infrastructure operations safely while still retaining the flexibility to generate dynamic API calls.

This approach allows an agent to discover and interact with many parts of the platform without requiring predefined tools for each capability. After discovering endpoints through the API specification, the agent can retrieve application data, inspect deployments, query metrics, or manage infrastructure resources through generated API calls.

The design also significantly reduces context usage. Traditional MCP integrations might require hundreds of tools to represent every endpoint of a large API. In contrast, the search-and-execute pattern allows the entire API surface to be accessed through just two tools.

For developers connecting AI assistants to infrastructure platforms, this architecture provides a practical way to expose large APIs while keeping the integration simple and efficient.

What This Means for Developers

Allowing AI agents to interact with infrastructure APIs changes how developers manage systems.

Instead of manually navigating dashboards or writing long sequences of commands, developers can describe what they want in natural language. The AI agent can interpret the request, discover the relevant API endpoints, and execute the required operations.

This approach also improves observability and debugging. When something goes wrong, the agent can query logs, inspect metrics, and retrieve system state without requiring the developer to manually gather information.

Over time, this type of integration could significantly reduce the friction involved in managing complex cloud systems.

The Next Evolution of Infrastructure Automation

Infrastructure automation has evolved through several stages. Early cloud systems relied heavily on manual configuration through web interfaces. Infrastructure as Code later allowed teams to define infrastructure using scripts and configuration files.

CI/CD pipelines then automated the process of deploying and updating systems.

AI agents represent the next step in this progression. By combining APIs, MCP integrations, and sandboxed execution environments, developers can allow intelligent systems to reason about infrastructure and interact with it safely.

Instead of static integrations, agents can dynamically discover and call APIs as needed. This makes infrastructure management more flexible and accessible while maintaining the reliability of programmable systems.

As AI tools become more deeply embedded in development environments, the ability for agents to understand and control infrastructure will likely become a standard capability for modern platforms.