Building with Claude on Google Cloud: Zero to Deployed in 30 Minutes

1. The big idea: Claude as the whole engineering team

Traditional software development assigns distinct roles to distinct people: someone designs the architecture, someone writes the code, someone reviews it for security, someone deploys it. Each handoff introduces delay and information loss.

The demo at the heart of this session asks a different question: what if Claude could fill all five roles in sequence — or even in parallel — within a single 30-minute window?

The answer is a working feedback application, built from an empty directory and deployed to Google Cloud, without the developer writing a line of code manually. By the end of the session, a public URL is live and accepting user feedback.

What makes this possible is the combination of three primitives:

• MCP servers that give Claude direct, structured access to Google Cloud APIs — so it can create Cloud Run services, write to Firestore, and set IAM policies without leaving the session
• Subagents that handle distinct phases of the build in parallel or sequence, each with its own focused context
• Skills that encode the team’s deployment conventions, security baselines, and API patterns so Claude applies them consistently without being reminded every time

Together these three primitives turn Claude from a coding assistant into a build system that understands not just how to write code, but how your team ships.

2. System architecture: how the pieces connect

Before the first line of code runs, it helps to understand what’s actually wired together. The session uses a layered architecture where Claude is the orchestrating intelligence and Google Cloud provides the managed runtime.

The five roles Claude plays

The session explicitly walks through five distinct phases, each corresponding to a traditional engineering role:

1. Architect — Claude reads the project brief, chooses the stack (Cloud Run + Firestore), and produces a design document before a single file is created.
2. Developer — Claude writes the application code, Dockerfile, and infrastructure-as-code, following the architecture it just designed.
3. QA engineer — A subagent with fresh context reviews the code against a test checklist, catching issues the developer subagent might have reasoned around.
4. Security reviewer — Another subagent applies the security skill: checks IAM permissions for least-privilege, ensures secrets go through Secret Manager, and flags any hardcoded credentials.
5. Deployer — Claude uses MCP server tools to run gcloud commands directly, build the container image, push it to Artifact Registry, and deploy to Cloud Run.

The developer never runs a terminal command manually. Claude does.

3. MCP servers: giving Claude authenticated hands

The most important infrastructure decision in this demo is the MCP server layer. Without it, Claude can write deployment scripts, but a human still has to run them. With MCP servers, Claude calls authenticated APIs directly.

What an MCP server gives you

An MCP server exposes a set of typed tools to Claude over a standard protocol. In this demo, the Google Cloud MCP server exposes tools like:

gcloud_run_deploy(service, image, region, env_vars)
firestore_create_collection(name, schema)
secretmanager_create_secret(name, value)
cloudbuild_submit(source_dir, tag)
iam_bind_policy(resource, member, role)

Claude calls these the same way it calls any other tool — by generating structured JSON that the MCP server receives, validates, and executes against the real Google Cloud API using the developer’s stored credentials.

Why MCP over writing scripts

You could instruct Claude to write a deploy.sh script instead. The difference is verifiability in the moment: when Claude calls an MCP tool, it sees the API response synchronously and can branch on the result. If gcloud_run_deploy returns an error about a missing IAM binding, Claude adds the binding and retries — within the same session, without the developer running anything. A generated script, by contrast, stops at the first failure and waits for a human.

4. Subagents: parallel roles, focused context

Subagents are the mechanism that makes the five-role model practical. Rather than stuffing all five roles’ instructions into one massive context, each phase gets its own agent invocation with a tightly scoped brief.

How the handoffs work

The orchestrator (the main Claude session) maintains a shared workspace — files on disk, a design document, an evolving BUILD_LOG.md. Each subagent is launched with:

1. A pointer to the shared workspace
2. A specific, bounded task: “Review app.py and Dockerfile for security issues. Output a checklist of issues in security-review.md.”
3. The relevant skills for that role (the security reviewer loads the security baseline skill; the QA engineer loads the test checklist skill)

When the subagent finishes, it writes its output to the shared workspace and exits. The orchestrator reads that output and decides what to do next — fix issues, proceed to deployment, or escalate for human review.

Fresh context as a feature, not a bug

The QA and security subagents never see the developer subagent’s reasoning. This is intentional. A reviewer that watched every decision the developer made is subtly biased toward those decisions — it has already “made peace” with tradeoffs it observed. A fresh subagent sees only the artifact (the code file) and applies the checklist without that prior reasoning weighing on it. Independent review through independent context is a structural advantage of the subagent model.

What the developer subagent produces

In the demo, the developer subagent generates:

feedback-app/
  app.py              # Flask app with /submit and /list endpoints
  requirements.txt    # Flask, google-cloud-firestore, gunicorn
  Dockerfile          # Python 3.12-slim, non-root user, health check
  cloudbuild.yaml     # Cloud Build steps: build → push → deploy
  .env.example        # Template for required environment variables

This is a complete, deployable application. The subagent wrote it, the QA subagent verified it, the security subagent reviewed it, and the deployer subagent ships it — all without the developer touching a code file.

5. Skills: encoding what your team knows

Skills are the mechanism that makes the agent’s behavior consistent across sessions, team members, and roles. Instead of trusting every subagent to rediscover your team’s conventions from scratch, you encode them once and reference them on demand.

What the demo uses as skills

The session demos at least three skills that different subagents load:

google-cloud-standards.skill.md — loaded by the developer subagent. Contains:

• Which Cloud Run region to target (us-central1 for lowest latency to the demo audience)
• Minimum instance configuration (--min-instances=0 for cost, --max-instances=10 for scale)
• Required health check endpoint (/health)
• Container conventions (non-root user, read-only filesystem where possible)

security-baseline.skill.md — loaded by the security reviewer subagent. Contains:

• IAM principle of least privilege checklist
• Prohibited patterns: hardcoded credentials, overly broad roles like roles/editor
• Required: all secrets via Secret Manager, not environment variables passed at deploy time
• Required: VPC connector if the app needs to reach private resources

firestore-patterns.skill.md — loaded when the developer subagent writes data access code. Contains:

• Collection naming conventions
• Required indexes for the query patterns the app uses
• Quota-aware batching guidance for bulk writes

Skills vs system prompt

The alternative to skills is a very long system prompt that includes all three bodies of knowledge at all times. The cost: every token in your system prompt costs context window on every single turn, even when the developer subagent is writing a Dockerfile that has nothing to do with Firestore query patterns.

Skills load on demand. The developer subagent loads google-cloud-standards when it starts and firestore-patterns when it reaches the data access layer. The security reviewer loads security-baseline and nothing else. Context is preserved for the actual reasoning task.

# google-cloud-standards.skill.md

## Deployment target
- Region: us-central1
- Runtime: Cloud Run (fully managed)
- Container registry: Artifact Registry (not Container Registry)

## Cloud Run configuration
- --min-instances=0 (scale to zero when idle)
- --max-instances=10
- --memory=512Mi
- --cpu=1
- --port=8080

## Required endpoints
Every service must expose GET /health returning {"status": "ok"} within 2 seconds.

## Container conventions
- Base image: python:3.12-slim
- Run as non-root user (uid 1000)
- COPY requirements.txt first (layer caching)
- CMD via gunicorn, not flask dev server

6. The build in real time

The demo runs in approximately 24 minutes. Here is the lifecycle as it unfolds:

Minutes 0–4: Architecture and planning

Claude reads a two-sentence brief: “Build a feedback collection app. Users submit text feedback; we store it and can list all submissions.” Rather than immediately writing code, Claude produces a design document:

• Chosen stack and rationale
• API surface (POST /submit, GET /list, GET /health)
• Data model (feedback collection in Firestore: text, timestamp, session_id)
• Deployment target (Cloud Run, us-central1)
• What IAM roles are needed and why

This document becomes the shared ground truth that all subagents work from.

Minutes 4–12: Development subagent

The developer subagent runs with the architecture document and the google-cloud-standards and firestore-patterns skills. It produces all five files (app, requirements, Dockerfile, cloudbuild.yaml, .env.example), running a syntax check on each before moving to the next.

Minutes 12–18: QA and security review

Two subagents run in parallel (or in rapid sequence in the demo). The QA subagent checks that the health endpoint exists, that the Dockerfile follows the container conventions, and that the app handles malformed input gracefully. The security subagent applies the security baseline skill and flags one issue: the initial draft passed the Firestore API key as an environment variable rather than reading it from Secret Manager. The developer subagent (in a quick fix pass) corrects this.

Minutes 18–24: Deployment

The deployer phase uses the MCP server to execute in sequence:

1. Create the Firestore database (if not already present)
2. Store the service account key in Secret Manager
3. Build the container image via Cloud Build
4. Push the image to Artifact Registry
5. Deploy to Cloud Run with the Secret Manager reference mounted as an env var
6. Test the live /health endpoint
7. Submit a test feedback entry and verify it appears in /list

The final output is a Cloud Run URL. The session ends with Claude posting a working form submission in the terminal to prove the end-to-end flow works.

gcloud services enable \
  run.googleapis.com \
  cloudbuild.googleapis.com \
  firestore.googleapis.com \
  artifactregistry.googleapis.com \
  secretmanager.googleapis.com

# Install via npm (the official Google Cloud MCP server)
npm install -g @google-cloud/mcp-server-gcloud

# Or add to your Claude Code MCP configuration
claude mcp add gcloud -- npx @google-cloud/mcp-server-gcloud

claude mcp list
# Should show: gcloud (connected)

mkdir -p .claude/skills

## Cloud Run deployment target
- Project: YOUR_PROJECT_ID
- Region: us-central1
- Registry: us-central1-docker.pkg.dev/YOUR_PROJECT_ID/apps

## Cloud Run settings
- --min-instances=0 --max-instances=10
- --memory=512Mi --cpu=1 --port=8080
- --allow-unauthenticated (for public apps)

## Container conventions
- Base image: python:3.12-slim
- Non-root user (uid 1000)
- COPY requirements.txt before application code
- CMD: gunicorn --bind :8080 --workers 1 app:app

## Required: health check endpoint
Every service must expose GET /health → {"status": "ok"} (< 2s response)

## IAM: least privilege
- Use purpose-specific service accounts, not default compute SA
- Required roles only; never roles/editor or roles/owner on service accounts
- Review every IAM binding before deploying

## Secrets
- ALL secrets (API keys, DB passwords) via Secret Manager
- Reference in Cloud Run as: --set-secrets=ENV_VAR=SECRET_NAME:latest
- Never pass secrets as plain --set-env-vars

## Container security
- No hardcoded credentials in Dockerfile or source code
- Read-only root filesystem where possible
- Scan image with `gcloud artifacts docker images scan` before deploy

cat > CLAUDE.md << 'EOF'
# Feedback App

## Stack
- Backend: Python / Flask on Cloud Run
- Database: Firestore (Native mode)
- CI: Cloud Build
- Secrets: Secret Manager

## Conventions
- Load the google-cloud-standards skill before writing any infrastructure code
- Load the security-baseline skill before the security review phase
- All deployments go through the deployer workflow — do not use gcloud run deploy directly

## Commands
- Local dev: flask run (set FLASK_APP=app.py)
- Deploy: trigger Cloud Build with gcloud builds submit
EOF

claude

We need a feedback collection app. Users submit text feedback via a web form; 
we store it and can list all submissions. 

Load the google-cloud-standards skill. Before writing any code, produce a 
design document covering: stack choice, API surface, data model, and IAM 
requirements. Wait for my approval before proceeding.

Now run a security review. Load the security-baseline skill. Review all files 
in this directory for security issues. Write your findings to security-review.md.

The security review is clear. Deploy the app to Cloud Run using the MCP tools:
1. Create the Firestore database
2. Store any secrets in Secret Manager  
3. Build and push the container image
4. Deploy to Cloud Run
5. Test the /health endpoint
6. Submit a test feedback entry and verify it is stored

# Claude will have provided the URL — substitute it below
FEEDBACK_URL="https://YOUR_SERVICE-HASH-uc.a.run.app"

curl "$FEEDBACK_URL/health"
# → {"status": "ok"}

curl -X POST "$FEEDBACK_URL/submit" \
  -H "Content-Type: application/json" \
  -d '{"text": "This demo is excellent"}'
# → {"id": "...", "status": "stored"}

curl "$FEEDBACK_URL/list"
# → [{"id": "...", "text": "This demo is excellent", "timestamp": "..."}]

Where to go next

• Tool, Skill, or Subagent? Decomposing an Agent — the conceptual framework behind the subagent/skill design used in this demo
• Ship Your First Managed Agent — if you want the deploy phase to be handled by Anthropic-managed infrastructure rather than Google Cloud
• Watch the original demo to see the live build in real time — the deployment phase in particular is worth watching end to end
• Google Cloud MCP server documentation for the full list of available tools and authentication options