I interviewed 200 CTOs from growing startups - here's what came up
This article explains:
- Why did 48% of CTOs move from Heroku to AWS.
- Why migrating to AWS is a "hell" (a word I've often heard in my interviews).
- How to simplify AWS and meet the needs of growing startups.
From Heroku to AWS
Early in the life of a startup, the CTO's objective is to design a product quickly and then validate that the product's value proposition is the right one with the defined target. Technical decisions are pragmatic, saving valuable time on product delivery. For application hosting, the majority choice of CTOs is Heroku - because it's easy to get started, with virtually zero upfront cost, a price that grows with usage, and maximum time spent on the product rather than managing the complexity of a server and database infrastructure.
When the startup's market positioning is the right one, the product is successful. The questions of recruitment and team structuring naturally arise, and it is from this point on that the CTO realizes that:
- Heroku is not for teamwork: a group of developers will have to share the same environments (staging, development) at the risk of getting stuck on modifications. Heroku quickly shows its limitations in this mode of operation and prevents development teams from being productive and efficient.
- Heroku is not for enterprise applications: Heroku considers the deployment and management of applications as a single unit. However, today an application is often made up of several apps - a frontend, a backend, and a database. Heroku does not allow you to manage a set of applications as a single application. This leads to difficulties in complexity management. And therefore, loss of team productivity.
- Heroku is outrageously expensive: even though AWS is not known for being cheap, Heroku is up to 10x more expensive than AWS for the same use. The more you use it, the more your bills go up. Peace of mind at a price, but it's tough to scale with Heroku.
These negative points lead 48% of CTOs to replace Heroku with AWS. But not everything is as green on the other side of the fence...
AWS hell for CTOs
Pre-sales engineers at AWS have a real strength to promote the many advantages of their Cloud solution. Arguments such as free services for up to 2 years and technical support by a dedicated account manager and a team of Cloud architects resonate exceptionally well. Their crews know the field correctly and learn how to reassure. Their products are of outstanding quality, and reliability is well proven. However, most of the CTOs we interviewed have no experience of using a Cloud provider such as AWS. From a technical point of view, you have to start from scratch - everything has to be built from the ground. Meaning configuring the network, configuring the services, creating a CI for integration, and a CD for deployment - in short, getting your hands in the engine. In our study, we found two types of CTOs: those who love to get their hands dirty in the infrastructure and those who don't want to. The latter is predominant, and even in the first case, he lacks time to do what is necessary. The CTO then often turns to someone from his team who will have the cumbersome task of " re-creating " how Heroku works but constantly learning on the job. Months can go by until the CTO decides to do so:
- Contracting an external DevOps company
OR
- Internalize this skill by recruiting it
From that moment on, I often heard, "Recruiting a DevOps is a real hell; I wouldn't wish it on anyone". Not surprisingly, this skill is scarce and expensive - ~$180k/year in San Francisco. Recruiting a DevOps can take up to 12 months, not counting the months of work needed to get a tenth of a Heroku functionality.
AWS is complex to use, as it has to meet the needs of all businesses worldwide. However, it is possible to simplify AWS. Here are some areas for improvement...
Simplify AWS and meet the needs of growing startups
To meet the needs of growing startups, we should combine Heroku's simplicity with the flexibility of AWS. But where to start? Here are my thoughts:
A UX designed for developers
Heroku gets it; the developer is now the king. He's the one who turns ideas into products. Developers should be able to use AWS without any effort. AWS must be fully integrated into their working environment (IDE) to request what they need transparently. "I need a PostgreSQL version 12 database, a 20GB disk, and to have my application available at https://foo.bar - and of course all this on my Cloud account".
An opinionated approach
Even if there is no consensus work methodology in the R&D departments of startups, most of them try to copy their elders with a functioning (most often) in the form of a Squad. The idea would be to ensure that the product can fit team working. GitOps and environment isolation (production, staging, dev) methodologies by the "git" branch are a perfect start. GitOps methodologies would allow developers to maximize their productivity and never slow down their colleagues on deploying new features.
Extensible
Heroku's move to AWS is not insignificant. A growing startup needs technical extensibility. Deploying applications automatically is suitable, but allowing you to change everything at any time is even better. This leaves room for future DevOps to join the growing startup.
To go further
These areas of improvement apply to AWS and other cloud providers such as Google Cloud Platform and Azure. At Qovery, we have begun this work of simplifying the Cloud. Our mission is to make it accessible to any developer, enabling growing startups to become the unicorns of tomorrow.
.svg)
.svg)
.svg)
Suggested articles
The cluster coming up is the easy part. What catches teams off guard is what happens six months later: certificates expire without a single alert, node pools run at 40% over-provisioned because nobody revisited the initial resource requests, and a manual kubectl patch applied during a 2am incident is now permanent state. Agentic control planes enforce declared state continuously. Monitoring tools just report the problem.
The instinct when setting up Kubernetes observability is to instrument everything and send it all to your APM vendor. That works fine at ten nodes. At a hundred, the bill becomes a board-level conversation. The less obvious problem is the fix most teams reach for: aggressive sampling. That is how intermittent failures affecting 1% of requests disappear from your monitoring entirely.
Scaling your deployments to zero is only half the battle. If your cluster autoscaler does not aggressively bin-pack and terminate the underlying worker nodes, you are still paying for idle metal. True environment sleeping requires tight integration between your ingress layer and your node provisioner to actually realize FinOps savings.
The structure, table, tool list, and code blocks are all worth keeping. The main work is fixing AI-isms in the prose, updating the case study to real metrics, correcting the FAQ format, and replacing the CTAs with the proper HTML blocks. The tool descriptions need the "Core strengths / Potential weaknesses" headers made less template-y, and the intro needs a sharper human voice.
For years, Red Hat OpenShift has been the safe choice for heavily regulated, on-premise environments. It operates as a secure fortress. But in the public cloud, that fortress acts as an expensive prison. Paying proprietary per-core licensing fees on top of your standard AWS or GCP compute bill is a redundant "middleware tax." Escaping OpenShift requires decoupling your infrastructure from your developer experience by running standard, vanilla Kubernetes paired with an agentic control plane.
Agentic Kubernetes resource reclamation is the practice of using an autonomous control plane to continuously identify, suspend, and delete idle infrastructure across a multi-cloud Kubernetes fleet. It replaces manual cleanup and reactive autoscaling with intent-based policies that act on business state, eliminating the configuration drift and cloud waste typical of unmanaged fleets.
Kubernetes focuses on container orchestration, but the reality on the ground is far less forgiving. Provisioning a single cluster is a trivial Day-1 exercise. The true operational nightmare begins on Day 2. Teams that treat multi-cloud fleets like isolated pets inevitably face crushing YAML configuration drift, runaway AWS bills, and severe scaling bottlenecks.
.webp)