The Go and gRPC Version of the SaaS Stack

Part 2 of 2. Part 1: The SaaS Stack I'd Use for LLM-Assisted Product Development.

The Go version of the SaaS stack should not be a personality change.

It should be a graduation.

I would not start every product with Go, gRPC, protobufs, service meshes, and a full Google Cloud architecture. That can be a smart architecture for the wrong moment. Early SaaS work needs product learning, short feedback loops, and simple deployment. A Python and TypeScript stack can give you that without pretending the product is already a platform.

But there is a moment when the flexible stack starts to show strain.

The API boundary stabilizes. Internal clients multiply. Async jobs become more important than request handlers. Python type hints help, but runtime behavior and concurrency bugs are taking more review time. The team is already on Google Cloud. The product has user-facing workflows that need lower latency, better service contracts, and cleaner operational ownership.

That is where I would reach for Go and gRPC.

A Concrete Scenario#

Imagine the product from Part 1 worked.

The team has paying users, a real workflow, Stripe events, product analytics, and a few AI-backed features. The first FastAPI service did its job: it helped the team find the product. Now the backend owns billing webhooks, workspace permissions, document ingestion, AI job scheduling, reporting, and internal APIs for admin and support tooling.

The failure mode is subtle.

Nothing is "broken." The product ships. The tests pass often enough. The team can still add endpoints. But every new workflow crosses the same crowded backend. Background jobs share too much application state. Internal clients depend on undocumented JSON shapes. The code is understandable if you already know the story, but expensive if you are new.

The tradeoff has changed.

At the beginning, the team needed fewer boundaries. Later, the team needs better boundaries.

Go and gRPC are not magic. They are useful when the system has earned service contracts.

The key decision is not "Go versus Python."

The key decision is where the product has stable contracts that deserve a stronger boundary.

Why Go Fits This Graduation#

Go is attractive for SaaS service work because it is small, typed, fast to compile, straightforward to deploy, and comfortable with concurrency. It does not remove architectural thinking, but it does make certain classes of backend work feel more explicit.

Google Cloud has also been making Go application startup smoother. The Google Cloud blog post on simplifying creation of Go applications on Google Cloud describes using gonew templates so teams can create deployable Go services with Google Cloud conventions already in place. That is the kind of tooling I like because it turns "how do we start correctly?" into a repeatable baseline.

For Cloud Run, the Go quickstart gives the basic deployment shape: containerized service, HTTP endpoint, managed scaling, and source-to-service workflow. Cloud Run is a good fit when the team wants managed containers without taking on Kubernetes too early.

The first Go service should be boring:

package main
 
import (
	"encoding/json"
	"log"
	"net/http"
	"os"
)
 
type HealthResponse struct {
	Status string `json:"status"`
}
 
func main() {
	http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
		w.Header().Set("Content-Type", "application/json")
		_ = json.NewEncoder(w).Encode(HealthResponse{Status: "ok"})
	})
 
	port := os.Getenv("PORT")
	if port == "" {
		port = "8080"
	}
 
	log.Fatal(http.ListenAndServe(":"+port, nil))
}

That service does not prove the need for Go. It proves the deployment path. The need for Go comes from boundaries, throughput, ownership, and operational clarity.

Where gRPC Earns Its Keep#

I like gRPC for internal service contracts. I do not like it as a default public API for a product dashboard.

Public app surfaces still usually want HTTP/JSON. Browsers, support tooling, webhooks, and simple integrations all expect that shape. gRPC becomes valuable behind the edge, where services talk to services and the team benefits from generated clients, typed messages, streaming options, and explicit contracts.

The gRPC Go quickstart is the right starting point for the mechanics. Cloud Run also supports gRPC; the Cloud Run gRPC docs are the operational reference for deploying it there.

A minimal internal contract might look like this:

syntax = "proto3";
 
package workflow.v1;
 
option go_package = "github.com/example/app/gen/workflow/v1;workflowv1";
 
service WorkflowService {
  rpc CreateRun(CreateRunRequest) returns (CreateRunResponse);
  rpc GetRun(GetRunRequest) returns (GetRunResponse);
}
 
message CreateRunRequest {
  string account_id = 1;
  string workflow_id = 2;
  map<string, string> inputs = 3;
}
 
message CreateRunResponse {
  string run_id = 1;
  string status = 2;
}
 
message GetRunRequest {
  string run_id = 1;
}
 
message GetRunResponse {
  string run_id = 1;
  string status = 2;
  string result_json = 3;
}

That file is not just serialization. It is a team agreement.

The mistake is adopting gRPC before the agreement exists. If the team is still changing the product language every day, protobuf churn can become ceremony. If the boundary is stable, protobufs become leverage.

The Google Cloud Shape#

The GCP version I would consider has a small number of services:

• A public HTTP API facade on Cloud Run.
• One or more internal Go services on Cloud Run.
• A Postgres layer through Cloud SQL or Supabase, depending on whether the team wants Google Cloud-native operations or Supabase product speed.
• Pub/Sub or Cloud Tasks for async work.
• Secret Manager for runtime secrets.
• Cloud Logging, Cloud Trace, Error Reporting, and OpenTelemetry for operational visibility.
• Stripe webhooks at the edge.
• PostHog events from the frontend and backend where useful.

The database choice deserves honesty.

If Supabase is already giving the product team auth, admin visibility, SQL, realtime, and fast iteration, I would not rip it out just because the backend moved to Go. If the team is standardizing on Google Cloud operations, needs private networking, wants Cloud SQL controls, or has compliance requirements that make one cloud boundary easier to govern, Cloud SQL starts to make more sense.

This is the pattern I like:

Public edge:
  Browser -> HTTP/JSON -> API facade
 
Internal services:
  API facade -> gRPC -> account/workflow/ai services
 
Async work:
  Service -> Pub/Sub or Cloud Tasks -> worker
 
Data:
  Services -> Postgres
 
Observability:
  Services -> OpenTelemetry -> Cloud operations stack

The architecture stays understandable because every protocol has a job.

Cost Is Different Here#

The cost story changes when you move to Google Cloud.

Cloud Run can still be inexpensive for low-traffic services, and the Cloud Run pricing page is the source to check before committing numbers. The trap is that a more capable platform gives you more ways to spend quietly: always-on databases, logs, traces, egress, background jobs, minimum instances, private networking, and overprovisioned service settings.

I would think about costs in bands rather than fake precision.

The cost question is not whether Go is cheaper than Python.

The better question is whether the service boundary pays for itself in reliability, reviewability, latency, or team speed.

Switch Triggers#

I would consider the Go and gRPC path when at least a few of these are true:

• The API contract is stable enough that generated clients would reduce mistakes.
• Multiple internal services or workers need the same domain operations.
• Python async behavior is taking too much debugging time.
• The backend has clear hot paths where latency and memory profile matter.
• Cloud Run and Google Cloud operations are already the team's default.
• Background work needs clearer ownership than "run another task in the web service."
• The team wants protobuf schemas as part of the product contract.

I would avoid the switch when the product language is still changing daily, when one backend service is still easy to reason about, or when the team is mainly trying to feel more serious.

Feeling serious is not an architecture requirement.

Go/gRPC Adoption Checklist#

This is the operational artifact I would use before creating the first protobuf file.

# Go/gRPC Adoption Checklist
 
## Boundary
 
- What product capability owns this service?
- Which calls stay public HTTP/JSON?
- Which calls become internal gRPC?
 
## Proto Ownership
 
- Which team owns the `.proto` files?
- What versioning rule will prevent breaking generated clients?
- Where are generated clients committed or published?
 
## Client Generation
 
- Which languages need generated clients now?
- How are clients regenerated in CI?
- How do services roll forward and roll back across proto changes?
 
## Auth
 
- How does the public API authenticate users?
- How do internal services authenticate to each other?
- Which claims or account context cross the gRPC boundary?
 
## Observability
 
- Which trace IDs flow from HTTP to gRPC to background jobs?
- What logs are safe to retain?
- Which errors page a human?
 
## Rollback
 
- Can the API facade route traffic back to the old implementation?
- Can old and new protobuf versions coexist during deploy?
- What data migrations are reversible?

The checklist keeps the team from treating Go as a rewrite language. It makes Go a boundary language.

That is the version of the stack I would sell to technical peers: start with the product-learning default, then graduate the parts that have earned stronger contracts. The stack grows because the product has learned something, not because the architecture wanted to impress itself.