Startups damage their infrastructure from two directions. Some build for a scale they have no evidence of reaching: a Kubernetes cluster serving fifty users, multi-region failover no customer asked for, and governance designed for an engineering org that does not exist yet. Others never build the foundation at all: the application runs directly on a VM, deploys happen by hand, and the first real traffic spike arrives as an outage.
Both directions cost real money. Flexera’s 2026 State of the Cloud report puts estimated wasted IaaS and PaaS spend at 29% of the bill, the first increase in five years. On the other side, the Startup Genome project found that 74% of failed high-growth startups died from premature scaling, spending ahead of validated demand across the business, infrastructure included.
Josef Bárta, Chief Architect at Revolgy and previously CTO of a SaaS company that scaled on Google Cloud through a PE acquisition, has sat on both sides of the decision:
Both of them are shooting themselves in the foot in a slightly different way. The difficult thing is you don’t even know which actually makes you more vulnerable. You never know when you hit the hockey stick.
Rightsizing infrastructure means matching what you build to the stage you are actually in, and knowing which signals tell you the match is off. This guide, based on a conversation between Michael Fitzgerald, Solutions Manager at Revolgy, and Josef Bárta, covers the signs your infrastructure is overengineered, the signs it is unprepared for growth, the steps to rightsize it on Google Cloud, and the practices that keep it aligned as you grow.
Signs your infrastructure is overengineered for scale
Overbuilding rarely looks like waste from the inside. It looks like diligence. Bárta names the mechanism: “You start thinking, what if this, what if that, and you basically start building out a really complex system in your head.” The costs land in cash, but mostly in something scarcer: the people and time.
These are the signals the diligence has tipped into overengineering:
- Kubernetes runs your application, and an engineer runs Kubernetes. “Usually the complexity of your application doesn’t warrant the sheer overhead of managing a Kubernetes cluster,” Bárta says. If cluster upkeep is a standing line in your sprint, the platform is heavier than the product.
- Your architecture answers hypothetical questions. Multi-region readiness, sharding strategies, and event buses justified by traffic projections nobody validated. Bárta’s test for each one: “Is it something that really matters, or is it just your anxiety and FOMO?”
- The team operates the platform more than it ships the product. Count the sprint hours spent on infrastructure that no customer feels. When that number rivals feature work before product-market fit, the ratio is inverted.
- You pay for capacity that never serves a request. Idle staging environments, over-provisioned node pools, and committed capacity bought against a forecast are the line items that quietly build a bill running ahead of usage.
- Your governance assumes an org chart you do not have. Approval chains, project hierarchies, and module boundaries designed for ten teams, enforced on one.
The failure mode has also moved. On managed platforms, raw capacity scales without you, so the thing left to overbuild is complexity itself. “These days you build for scale in different ways. The infrastructure scales fine. It’s more modularity and complexity of infrastructure and governance if you overscale at the beginning,” Bárta says.
Signs your infrastructure is unprepared for scale
Underbuilding hides better than overbuilding, because everything works right up until it matters. The bill stays small, the team ships fast, and the gaps only surface when growth applies pressure. These are the signals the pressure will find:
- The application runs directly on a VM. “Don’t make the mistake of running your application directly on a VM,” Bárta says. Without a container, you cannot reproduce the environment, autoscale it, or move it, and every later option narrows.
- Deploys are manual, slow, or feared. Changes made in the console with no infrastructure-as-code behind them mean nobody can state what production looks like, and rollback is guesswork.
- A traffic spike is an incident. If demand doubles and your first response is a war room, there is no scaling path. Slow application startup shows up here too: platforms like Cloud Run can add instances in seconds, but only if your service starts fast enough to catch the wave instead of returning 502s.
- Nobody can say what a single service costs. One unlabelled bill for the whole company means cost problems are discovered by the finance team, months late, instead of by the engineer who caused them.
- The product creaks before the infrastructure does. Past a certain scale, the strain moves up the stack. “It’s not just the infrastructure that starts creaking. It’s in fact your product itself,” Bárta says. Falling feature velocity under growth is an architecture signal, and it usually means the re-engineering conversation is overdue.
The damage pattern is the inverse of overbuilding: the cost arrives all at once, at your best commercial moment, as downtime, lost deals, and a rebuild done under pressure instead of on your schedule.
How to rightsize your infrastructure on Google Cloud for scale
The sequence below builds the cheap foundation first and adds complexity only when evidence demands it. Each step keeps the next one open.
- Containerize the application. This is the single change that preserves every later option: the same image runs on Cloud Run, GKE, or another cloud entirely. Store images in Artifact Registry and make the container the unit of deployment from day one.
- Default to managed runtimes and databases. Run stateless services on Cloud Run, and pick the managed database that fits the data model: Cloud SQL for relational, Firestore for documents. Bárta’s economics are blunt: take the infrastructure cost over the cost of managing it in-house, “up to a scale where perhaps the economics may really start flipping. But for a startup CTO you may just as well forget it.”
- Put cost guardrails in before the first invoice. Set Cloud Billing budgets with alerts, and label every resource by service and environment. This costs an afternoon now and buys the per-service cost visibility that underbuilt teams discover they need mid-crisis.
- Escalate compute on evidence, never on ambition. When a workload outgrows Cloud Run, the next step is GKE Autopilot, where Google manages the nodes and bills for the resources your pods request, before GKE Standard and its full operational surface. Google documents migration paths between Cloud Run and GKE in both directions, so this decision is recoverable at every stage.
- Pre-scale for the demand you can see coming. Planned spikes are an engineering task, never a surprise. Bárta’s team once had a platform event featured in prime time on French national television: “We expected that it would be popular, so we had it pre-scaled.” Set minimum instances ahead of the event, load test at the projected peak, and verify startup times.
- Apply for credits before spending your own money. The Google for Startups Cloud Program covers up to $200,000 in Google Cloud costs over two years, and up to $350,000 for AI startups, as of July 2026. The larger tiers gate on institutional funding, and the criteria take some reading; a Google Cloud partner can confirm eligibility before you apply.
Teams get this sequence wrong by running it backwards: adopting GKE at step one, then retrofitting containers, cost labels, and deployment discipline underneath a platform already in production. The order is the point. The foundation steps are cheap while you are small and brutal to retrofit once the organization has grown around their absence.
Best practices for keeping infrastructure rightsized
Rightsizing is a recurring judgment call, revisited every time requirements change. These are the practices that keep the calls honest:
- Use the complexity check before every architecture decision. “Usually if something seems to be getting complicated, it is too complicated,” Bárta says. His remedy is to say the design out loud to a co-founder or mentor and pare it back to what the product actually needs.
- Treat platform limits as design input. If a feature forces your infrastructure several levels up in complexity, question the feature before you build the infrastructure. Sometimes the limitation is the correct answer.
- Build fit for purpose on a short horizon. “Make sure that your infrastructure is fit for purpose. Today, tomorrow, but don’t worry about the three to five years horizon,” Bárta says. “In that time there are other things you should be focusing on more.”
- Treat platform choices as recoverable. “It is important, but it’s very much recoverable. Any cloud will do at the beginning,” Bárta says, an unusual admission from a Google Cloud partner. Decisions made at the compute layer can be corrected; only the skipped foundation cannot.
- Remember what infrastructure is for. “Infrastructure is rarely the problem that brings the business down, because it typically is not business critical in terms of the IP, in terms of your go-to-market,” Bárta says. It is a means of shipping the product, which is exactly why it is a candidate for outsourcing while your team builds what differentiates you.
Talk to a Revolgy architect about rightsizing your infrastructure
If you have read this far and still cannot tell which side of the line your setup falls on, whether the next build is diligence or anxiety, that uncertainty is the starting point for an Architecture Clinic with Revolgy.
Revolgy’s architects have made this call in both directions: the environments where the honest answer was to strip complexity out, and the ones where the foundation needed building before growth arrived to punish its absence. That judgment is worth borrowing before you commit a quarter of engineering time either way.
The Clinic is a free 45-minute 1:1 working session with a senior Revolgy Google Cloud architect. Within 24 hours, you receive a structured summary of the gaps and the recommended next steps.
Book a free 45-minute Architecture Clinic with a Revolgy Google Cloud expert now. Only 6 slots run per week. Claim yours now.
Frequently asked questions
What is premature scaling in infrastructure?
Premature scaling in infrastructure is investing in capacity, complexity, or governance for a growth stage you have no evidence of reaching. Premature scaling is one of the primary causes of failure among high-growth startups. In infrastructure terms it shows up as orchestration platforms, multi-region setups, and microservice architectures adopted before any workload demands them.
What infrastructure should a startup build first on Google Cloud?
A startup’s first infrastructure on Google Cloud should be containerized workloads on Cloud Run, a managed database such as Cloud SQL or Firestore, billing budgets with alerts, and resource labels from the first deployment. This foundation costs little at small scale and keeps every scaling path open. Compute platform upgrades come later and on evidence; the foundation cannot be cheaply retrofitted.
When should you move from Cloud Run to GKE?
Move from Cloud Run to GKE when the workload needs something Cloud Run does not provide: full Kubernetes APIs, custom networking and service mesh, specialized hardware, or sustained always-on traffic that undermines request-based pricing. Google documents migration paths in both directions, so starting on Cloud Run carries no lock-in penalty. Teams that need partial Kubernetes control without node management should evaluate GKE Autopilot first.
How do you know if your infrastructure is over-engineered?
Infrastructure is over-engineered when the team spends more time operating the platform than shipping the product it runs. Supporting signals include capacity that never serves requests, architecture justified by unvalidated traffic projections, and governance designed for a larger organization. The working heuristic from practitioners: if the design feels too complicated, it almost always is.