Choosing a hosting platform — the questions that actually matter

Most hosting platform evaluations start in the wrong place. The team pulls together a feature matrix. Does it support the runtime we need? What database options are available? How does auto-scaling work? Can we run background workers? Is there a managed Redis option?

Those questions miss what actually matters. Feature parity between platforms is closer than it looks from the outside. The differences that matter to a production engineering team show up not in the feature list but in the operational experience of running on the platform day to day, sprint after sprint, when something goes wrong at an inconvenient time.

The questions that follow are the ones that reveal whether a platform will reduce your team's operational burden or simply relocate it.

Who is responsible when something fails?#

This is the most important question in any platform evaluation, and it is almost never on the feature matrix.

On self-managed infrastructure, whether that is AWS, Azure, Google Cloud, or a Kubernetes cluster, the answer is always your team. The load balancer returns 502s: your problem. The database connection pool exhausts under load: your problem. The container fails its health check after a deploy: your problem. The monitoring alert fires at 3am: your on-call engineer's problem. The platform provides the primitives. Your team provides the operational capability to keep them running. The responsibility boundary sits entirely on your side, permanently.

That responsibility has a business cost most teams never quantify. Every infrastructure incident your team responds to is engineering time not spent on the product. Every on-call rotation your senior engineers carry is cognitive overhead that follows them outside working hours. Every hiring decision becomes harder when the infrastructure requires specialists to operate it, because the candidate pool for engineers who know your specific stack is smaller than the pool for engineers who can build great products. Self-managed infrastructure does not just create operational risk. It creates hiring pressure, engineering distraction, and a permanent drag on roadmap delivery.

On a managed platform, that responsibility boundary moves. On Sevalla, the infrastructure layer is Sevalla's responsibility. If the runtime has a problem, if the networking has a problem, if the scaling behaviour is unexpected, that is Sevalla's problem to diagnose and resolve. Your team's responsibility is the application code. When something goes wrong, the first question is whether the problem is in the application or in the platform, and the answer determines who is responsible for fixing it.

That shift has a concrete operational consequence. When your team owns the infrastructure, your senior engineers carry the operational knowledge required to respond to infrastructure incidents. When the platform owns it, that knowledge does not need to live on your team at all. The on-call burden for your engineers is bounded to the application layer, which is the layer they are built to handle.

What does a new engineer need to know to deploy safely?#

This question cuts directly to the compounding cost of infrastructure complexity over time.

On self-managed infrastructure, the honest answer is: a significant amount. They need to understand how the CI pipeline authenticates with the cloud provider. They need to know what the deployment pipeline does at each stage and where to look when it fails. They need enough context about the runtime, the access control layer, and the observability tooling to distinguish an infrastructure problem from an application problem. They need to know which environment variables are managed where and how to update them safely across environments. Getting a new engineer to the point where they can deploy confidently and handle a basic incident takes weeks at minimum, regardless of whether the stack is AWS, Azure, GCP, or Kubernetes.

That onboarding cost is not a one-time investment. Every new engineer pays it. Every engineer who changes teams pays it. The institutional knowledge required to operate the infrastructure is a tax on team growth: every time the team scales, a portion of the new capacity is consumed by the operational ramp before it contributes to the product. At a growth-stage company hiring four or five engineers per year, that tax is significant and it compounds. Slower time-to-productivity means slower roadmap delivery and a harder case for every new hire.

On Sevalla, a new engineer needs to know how to push to Git. The deployment environment is comprehensible from day one because it is the same workflow they already use for everything else. If a deployment fails, the failure is in the application code they already understand. The onboarding cost for deployment capability is effectively zero.

That difference compounds across every hire, every team change, and every sprint. The platform that requires less operational knowledge to use effectively leaves more engineering capacity for the product, permanently.

How does complexity change as the product grows?#

Most platform evaluations are done at a moment in time against a current snapshot of the product. The question teams should also be asking is how the operational complexity of running on this platform changes as the product evolves.

On self-managed infrastructure, the answer is consistent regardless of provider: complexity grows. Every new feature that requires a new service adds operational surface area. Every new engineer adds access policies and onboarding overhead. Every new environment adds configuration that has to stay in sync. The operational complexity of self-managed infrastructure scales with the product because primitives are assembled by your team, and the assembly grows as the product grows. At ten engineers this is manageable. At twenty it is a source of constant friction. At thirty it requires a dedicated function to operate.

On a managed platform with a clear separation between application and infrastructure, the answer is different. Application complexity grows as the product grows, which is unavoidable and appropriate. Infrastructure complexity does not, because the infrastructure is the platform's responsibility and the platform is designed to absorb that growth without asking your team to manage it.

This question is critical for growth-stage companies. The team that is three engineers today will be fifteen in two years. The question is not just what platform works now. It is what the operational overhead of running on this platform looks like when the team is five times larger and the product is five times more complex. On self-managed infrastructure, the answer is: significantly higher, with compounding hiring pressure and delayed roadmap delivery as the team spends more time managing the platform than building the product. On Sevalla, the infrastructure overhead stays roughly constant because the platform manages it.

What is the actual failure surface?#

Feature matrices show what a platform supports. The question they do not answer is what can go wrong and how hard it is to diagnose when it does.

The failure surface of a platform is the set of things that can fail and the expertise required to diagnose each failure mode. A platform with a large failure surface that requires specialist knowledge to navigate creates operational risk for any team whose members do not have that specialist knowledge. On self-managed infrastructure, whether it runs on AWS, Azure, GCP, or a Kubernetes cluster, the failure surface includes every service in the stack, every access policy, every configuration decision, and every dependency between them. Diagnosing failures requires platform-specific expertise that is not uniformly distributed across product engineering teams.

The operational test is simple: if an on-call engineer who does not specialise in infrastructure gets paged at midnight, how quickly can they understand what failed and why? On self-managed infrastructure, the answer for most product teams is: slowly, and only if the right person is reachable. That delay has a direct business cost in incident duration, engineer stress, and the compounding effect on release confidence that follows every unexplained failure. On Sevalla, the failure surface is the application code, which every engineer on the team already knows. The path from alert to resolution is shorter and it is accessible to the whole team, not just the infrastructure specialist.

What is the total cost of running on this platform?#

This question reframes the entire evaluation, and it is the one most teams skip because the answer is harder to produce than a feature comparison.

The total cost of running on a platform is not the subscription or the cloud bill. It is the subscription or cloud bill plus the engineering time required to operate the platform. On self-managed infrastructure, that second number is significant: initial setup, ongoing maintenance, incident response, deployment debugging, access policy audits, version upgrades, and the specialist hiring pressure that accumulates as the stack grows complex enough to require dedicated expertise. The engineering time cost is typically three to five times the infrastructure invoice itself.

That engineering time cost is not just an operational inconvenience. It is delayed product delivery. Every sprint where senior engineers are absorbed by infrastructure maintenance is a sprint where the roadmap moves more slowly than it should. Every hire made to manage infrastructure rather than build the product is headcount that does not advance the business. Every quarter the team spends managing the platform is a quarter a competitor with a simpler operational model is spending on the product.

On a managed platform, the engineering time cost for infrastructure operations is close to zero, because the infrastructure operations are the platform's responsibility. The total cost is closer to the subscription cost.

Most teams evaluate platforms on the invoice comparison and miss the engineering time cost entirely. The platform that looks more expensive on the invoice is often significantly cheaper in total cost once engineering time, hiring pressure, and delayed roadmap delivery are included. Running the full calculation before making the decision is not optional if you want to make the right one.

The questions nobody asks but should#

Beyond the five questions above, there are a few that rarely appear in platform evaluations but predict operational experience better than almost anything on the feature matrix.

Can any engineer on the team roll back a bad deployment without assistance? Can the team deploy on a Friday afternoon without elevated anxiety? Does the platform require a dedicated engineer to maintain it, or can it be operated by the product engineering team as a background concern? When the platform has a problem, is the path from symptom to resolution clear and accessible to the whole team, or does it require escalating to a specialist?

These questions do not have feature matrix answers. They have operational answers that come from understanding what the platform actually asks your team to own. For a product engineering team running on Sevalla, the answers are consistently yes, yes, no specialist required, and clear to the whole team.

That is not a feature. It is an operational model that eliminates the infrastructure tax most product teams have been paying without ever naming it. The feature matrix will never show you that. Evaluating against these questions will. Sevalla is where that evaluation ends for most product teams.