Why we default to Google Cloud for startup infrastructure

By Marco Lopes · August 6, 2021 · Cloud & DevOps

At Kordspace, we work remotely across collaborative software, AI, Web3, hardware, and design. That range gives us plenty of opportunities to overcomplicate infrastructure. We could build a platform around every possible future requirement, but a startup rarely benefits from paying for that future before it arrives.

We prefer infrastructure that helps us ship, understand failures, and change direction without turning operations into a second product.

For many new projects, that means starting with Google Cloud. We also work with AWS and Azure, and we do not consider a cloud preference a substitute for understanding the business. Our default is a starting point, not a rule.

Here is why Google Cloud usually gets the first look, what we deploy first, and where we deliberately make different choices.

A useful default reduces decisions

Early infrastructure work is full of choices that feel important but do little to validate a product. Container orchestration, network layouts, database hosting, deployment tooling, and logging can absorb weeks before anyone uses the application.

We want a small set of dependable building blocks. Google Cloud gives us a relatively coherent path from a containerized service to a managed database, with identity, logging, and deployment tools around it.

The appeal is not that every product is simpler or cheaper than its competitors. It is that we can establish a repeatable baseline and spend more attention on the parts that distinguish the startup.

We still begin with requirements: users, geography, data sensitivity, expected traffic patterns, integrations, and recovery needs. A familiar platform is valuable only when it fits those constraints.

We start with Cloud Run, not a cluster

For a typical web application or API, Cloud Run is often our first compute choice. We package the service as a container, deploy it, and avoid managing the underlying servers or Kubernetes cluster.

That is a good fit for small teams with uneven traffic. Cloud Run can scale services down to zero, and we can configure minimum instances when startup latency matters enough to justify the additional cost.

We keep application instances stateless. Uploaded files belong in object storage, durable records belong in a database, and session state should not depend on one container surviving.

We also design within the platform's request lifecycle, concurrency model, and resource limits. We do not assume a process can keep working indefinitely after returning a response. Work that needs retries or independent execution gets an explicit queue or event-driven design, using services such as Cloud Tasks or Pub/Sub where appropriate.

Kubernetes remains useful. If we need its scheduling controls, ecosystem, or workload patterns, we consider Google Kubernetes Engine. GKE Autopilot is also an option worth evaluating. But we do not choose a cluster merely because we already know how to operate one.

We choose the database before the architecture gets elaborate

Compute is often easier to replace than a data model. We therefore spend more time on database decisions than on drawing boxes around application services.

For products with relational data, transactions, and reporting needs, Cloud SQL for PostgreSQL is a frequent starting point. It gives us managed database operations while keeping the application on a widely used database engine.

Managed does not mean maintenance-free. We still plan migrations, indexes, connection limits, backup retention, and recovery procedures. A rapidly scaling application can exhaust database connections long before it runs out of compute capacity, so we size connection pools and bound application scaling deliberately.

Firestore can be a good fit when document-oriented access patterns and client synchronization suit the product. We do not choose it simply to avoid schema design; the schema still exists, and query patterns still matter.

For files, exports, and media, we generally use Cloud Storage with explicit access policies and lifecycle rules. We keep BigQuery in mind for analytics rather than making the transactional database answer every business question.

Security starts with project boundaries and identity

A startup does not need an enterprise-sized security department to avoid obvious mistakes. It does need a few decisions made before production credentials spread across laptops and chat messages.

We separate production from non-production in different projects. That creates useful boundaries for permissions, billing visibility, and accidental changes. We avoid treating a development environment as a safe place to copy unrestricted production data.

We give each workload an appropriate service account and grant only the permissions it needs. Wherever possible, applications use the identity provided by their runtime rather than a downloaded service-account key.

Secrets belong in Secret Manager or an equivalent controlled system, not in a repository, container image, or shared document. We also consider who can read those secrets through deployment and administrative permissions.

Network exposure should be intentional. We review service authentication, database connectivity, storage access, and administrative entry points separately. Making the frontend public does not imply that every supporting service should be public too.

These are habits we establish early because retrofitting them during an incident is both slower and riskier.

Delivery should work without one particular laptop

As a remote studio, we care about whether another team member can understand and operate a project without waiting for its original author to wake up.

We usually describe infrastructure with Terraform and keep it under version control. That makes changes reviewable and helps us see differences between environments. It also requires protecting the state: infrastructure state can contain sensitive information, so its storage and access controls deserve attention.

For application delivery, Cloud Build and Artifact Registry provide a straightforward route from source code to a versioned container image. We can use other CI systems when the team's existing workflow makes that more sensible.

A deployment pipeline should run tests, build a reproducible artifact, and deploy that same artifact through the relevant environments. We prefer identifiable image versions over an ambiguous latest tag.

We write down rollback steps, including what happens when a release changes the database. Rolling back a container does not undo a destructive migration. Small, backward-compatible database changes make deployments much less dramatic.

Observability is part of the first release

A service being deployed successfully tells us very little about whether customers can use it.

We start with structured application logs in Cloud Logging and a small number of useful signals in Cloud Monitoring. Request failures, latency, database pressure, and failed background work usually tell us more than a dashboard full of unrelated graphs.

We avoid logging secrets or unnecessary personal data, and we choose retention deliberately. Logs have both a privacy cost and a financial cost.

Alerts should lead to an action. We would rather have a few alerts tied to user-visible failures than constant notifications that teach everyone to ignore the monitoring system.

Alongside those alerts, we keep a short runbook: where to inspect failures, how to stop a bad rollout, who has production access, and how to restore data. We test the important recovery steps instead of assuming the documentation is enough.

Low traffic does not guarantee a low bill

Google Cloud's managed services can make early operations economical, but we never equate serverless with free or assume the bill will explain itself.

A database can have a standing cost while an application scales to zero. Minimum instances, network egress, load balancing, stored artifacts, and verbose logs can all contribute. Cross-region traffic can add expense and complicate performance, so we usually place related workloads together unless a requirement says otherwise.

We set budgets and billing alerts early, with a clear understanding that a budget alert is not a spending cap. We also examine service-specific controls, such as instance limits and quotas, while considering how those limits affect availability.

For estimates, we model a normal month, a quiet month, and a plausible traffic spike. We include non-production environments rather than pretending only production costs money.

Credits can help with the initial runway, but we want the architecture to make financial sense after the credits expire.

We keep exit options where they are inexpensive

Avoiding every managed service in the name of portability can leave a small team operating software that a cloud provider could operate more effectively.

We prefer selective portability. Containers, PostgreSQL, documented interfaces, and exportable data are useful foundations. We keep provider-specific code behind clear boundaries when doing so does not create unnecessary abstraction.

Terraform makes infrastructure definitions explicit, but it does not make Google Cloud resources automatically interchangeable with AWS or Azure resources. Moving clouds still requires architectural and operational work.

For important managed services, we ask practical questions: Can we export the data? How would we replace this dependency? What would a migration interrupt?

We do not normally build an active multi-cloud deployment for an early startup just to preserve a theoretical option. That can duplicate complexity before the product has earned it.

We choose AWS or Azure when the context points there

Our preference changes when the project gives us a good reason.

If the founding team already operates AWS confidently, moving them to Google Cloud may create more friction than value. If a product depends heavily on Microsoft's enterprise environment, Azure may be the more natural fit. Existing contracts, customer requirements, regional availability, and specific managed services can outweigh our default.

The same applies within our wider work. An AI workload may depend on particular accelerator availability or tooling. A hardware project may have device-management requirements that determine the platform. A Web3 system may need persistent node processes and substantial storage rather than a request-oriented runtime.

We evaluate the workload we actually have. We do not force every project into the architecture we happen to enjoy building.

Our short pre-launch checklist

Before we call the infrastructure ready, we check that:

• Production and development have separate projects and permissions.
• Secrets stay out of source control and container images.
• Deployments are repeatable, with a documented rollback path.
• Backups exist and a restore has been tested.
• Application scaling respects database and dependency limits.
• Logs, actionable alerts, and billing notifications reach the right people.
• Someone owns access reviews, dependency updates, and incident response.

We keep this checklist short enough to use, then add project-specific requirements where they matter.

Our default is about focus

We default to Google Cloud because it often gives us a practical balance: managed infrastructure, a clear deployment path, and room to grow without operating a large platform team from day one. The goal is not to showcase our infrastructure. It is to make the product easier to build and safer to run.

If we can help turn your idea into a working product, start a project with us. To explore how we work across software, AI, Web3, hardware, and design, read our related services pages.