For engineering teams where developers spend more time on infrastructure than shipping product. I build the golden paths, hand them off, and leave your team owning the result.
You work directly with me — not an account manager routing work to a team you never meet. The same person who scopes it builds it.
Let's talk about your platformNine months of implementation. A dedicated platform team to maintain it. Fifteen percent of your engineers actually use it. The other eighty-five percent found workarounds.
A new service takes three weeks to bootstrap. Service accounts, databases, secrets, load balancers — all configured from scratch, all slightly different, all waiting to drift.
You have a Vertex AI demo. You don't have a Vertex AI product. Your team knows how to run things on Google Cloud — but not how to run them well.
Platform engineering fails the same way every time: a portal gets built before the backend exists. Developers get a Backstage instance with nothing behind it. Adoption flatlines. The portal becomes the project.
I build in the opposite direction. Golden paths first — the Terraform modules, GitHub Actions workflows, and repository templates that encode your team's infrastructure decisions. The portal, if you want one, is a frontend for a platform that already works.
Your developers already live in GitHub. Platform capabilities delivered as GitHub Actions workflow templates and repository scaffolding meet them where they work. No new portal to learn. No new tool to adopt. Zero-friction golden paths.
Platform state lives in Git. Changes are pull requests. Rollback is a revert. Your audit trail is your commit history. Nothing competes with Git for source of truth — so nothing does. Every engagement produces a working CI/CD pipeline — not a diagram of one.
The YAML interface that developers use to provision infrastructure is the same interface AI agents use. A developer can type a request; an agent can open a pull request with the complete infrastructure declaration. The platform serves both without modification.
My delivery is built on the same infrastructure-as-code methodology I build for clients — Terraform modules, templated workflows, and AI-assisted implementation that compress weeks of setup into hours. You get the output of a team and a single person accountable for every line.
In teams I've worked with, developers routinely spend 40–50% of their time on infrastructure instead of shipping product. I build the platform layer that changes that.
What this looks like in practice: a GitHub-native IDP — golden path templates for Cloud Run services, GKE workloads, Vertex AI endpoints, event-driven pipelines. Each template provisions the complete infrastructure stack automatically: service accounts, IAM bindings, database connections, secrets injection, load balancers, monitoring. Developers declare what they need in a 30-line YAML file. The platform handles everything else.
The pattern is proven in production — deployed across 100+ Google Cloud projects in a regulated healthcare environment. Service bootstrap time drops from weeks to hours. Developers stop writing infrastructure code. IAM tickets stop.
Security posture is built into every engagement — IAM least-privilege bindings, CMEK encryption, VPC-SC perimeter configuration, and Cloud Armor policy — not treated as a separate workstream or left for a later phase.
You have a Vertex AI prototype. You don't have a Vertex AI product. The gap between the two is production infrastructure — observability, cost governance, IAM, networking, deployment pipelines for non-deterministic workloads.
I specialize in the infrastructure layer that makes AI workloads production-grade on Google Cloud: Vertex AI endpoint deployment, RAG pipeline infrastructure, Agent Engine configuration, cost governance for GPU/TPU workloads, and the IAM patterns that actually secure AI serving without breaking it.
This is not model selection or prompt engineering. It is the platform layer that makes AI reliable in production.
Your software engineers are excellent. They don't know Google Cloud — not the IAM model, not the networking primitives, not the patterns that make services actually work in production.
I build the knowledge and the infrastructure together. Your team leaves the engagement understanding the decisions that were made, able to operate what was built, and confident building new things on the same foundation. The goal is independence, not dependency.
Analytics infrastructure that holds up in production: BigQuery schema design, Looker and Looker Studio deployments, Dataflow pipeline infrastructure, and the IAM and networking patterns that make data pipelines reliable at scale.
Built for engineering teams that need their data infrastructure to be as correct as their application infrastructure — governed, auditable, and production-ready from day one.
Google Workspace deployment, configuration, and administration for organizations moving off legacy platforms or scaling their existing environment.
Organizational unit structure, device management, security policy configuration, and the integrations that connect Workspace to your cloud infrastructure. I've managed Workspace environments at K-12 district scale and in regulated enterprise settings — the patterns that work at 5,000 users are different from the ones that work at 50.
Before writing a line of Terraform, I mapped the primitive set that every Google Cloud deployment requires — the minimum orthogonal concepts that, composed together, can express any workload from a Cloud Run service to a Vertex AI agent to a data pipeline.
215 real production failure cases across six domains: IAM and identity, networking and connectivity, encryption and key management, deployment and promotion, AI serving infrastructure, and IaC generation failures. Platform engineering post-mortems. IAM misconfigurations that took down production. Vertex AI service agent grants that nobody knew existed until the deployment failed. AI-generated Terraform that passed linting and broke in production.
Seven primitives emerged. Together they explain every case without forcing.
| Primitive | What the developer declares | What gets configured automatically |
|---|---|---|
| Workload | Platform, image, compute configuration | Tier presets, API enablement, security policies |
| Identity | Service account name (optional) | SA creation, naming convention, all IAM bindings |
| Dependencies | What resources this service accesses | IAM role bindings in the right project, service agent grants, connection injection |
| Credentials | Secret names, environment variable names | Secret accessor bindings, injection configuration |
| Connectivity | VPC, egress mode | VPC attachment, PSA ranges, Cloud NAT |
| Exposure | Internal / external / none | Load balancer, serverless NEG, TLS, Cloud Armor |
| Promotion | Stages, approval requirements | Cloud Deploy pipeline, environment parameterization, immutable artifact enforcement |
The YAML a developer writes:
application: payment-service
project: my-project-prod
tier: prod
workloads:
- name: payment-api
platform: cloudrun
image: us-docker.pkg.dev/my-repo/payment-api:v1.2.3
dependencies:
- type: cloud_sql
name: payments-db
engine: postgresql
- type: pubsub_topic
name: payment-events
role: publisher
credentials:
- env: STRIPE_API_KEY
secret: stripe-api-key
exposure:
type: internal
auth: required
promotion:
stages: [dev, staging, prod]
approval: [prod]What I configure from this declaration — none of which your developers write:
roles/cloudsql.client bound in the Cloud SQL instance's project — not the workload project, which is the most common IAM failure in Google Cloud production environmentsroles/cloudkms.cryptoKeyEncrypterDecrypter on the CMEK key (prod tier; automatic)roles/bigquery.dataViewer bound on the dataset in the analytics projectroles/pubsub.publisher bound on the topic resourceroles/run.invoker bound for the fraud-detector cross-service callroles/secretmanager.secretAccessor bound on each specific secretUTILIZATION mode — not CONNECTION, which is the Terraform provider default and incompatible with serverless NEGsINGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER — direct bypass is impossibleaiplatform.user and storage.objectViewer on the model artifact bucketZero IAM knowledge required. Zero networking knowledge required. Zero Google Cloud service-specific configuration knowledge required.
This is what "production-grade" means. Not a checkbox. A specific guarantee about what fails in production and why it can't fail here.
A scoped investigation of your current Google Cloud infrastructure. Deliverable: annotated findings, gap analysis, sequenced 90-day roadmap, one follow-up call. Fixed scope, fixed price: $2,000. This is the right starting point if you want to understand the state of your platform before committing to a larger engagement.
The full golden path implementation: Terraform module library, GitHub Actions workflows, repository templates, IAM baseline, and documentation your team can operate. Timeline: 4–8 weeks depending on scope. Deliverable: a working platform your team owns.
2–4 weeks of focused platform engineering alongside your team. Right for organizations that have a platform team but are blocked on a specific hard problem — VPC-SC configuration, Vertex AI production deployment, multi-environment promotion pipelines.
Hiring a senior Google Cloud platform engineer takes 3–6 months and costs $180–250K per year once you factor in salary, benefits, and ramp time. An engagement takes 2–8 weeks and leaves your team owning the result — with documentation, tests, and the institutional knowledge to extend it.
You also get expertise you couldn't hire for that price. Someone who has done this specific work, across production environments at scale, and knows where it breaks.
I'm a Google Cloud engineer and platform architect with 20 years in IT — municipal infrastructure, K-12 district technology at scale, and for the past four years, enterprise cloud at a Premier Google Cloud Partner. My Google Cloud work has been in regulated environments: healthcare compliance frameworks, 100+ project infrastructure at a major healthcare network, data architecture and analytics modernization for state government agencies.
I passed six Google Cloud Professional certifications in four days — not because I crammed, but because I'd already built the infrastructure those exams test. Certifications are how I confirmed what I knew, not how I learned it. Architect, Developer, DevOps Engineer, Data Engineer, Network Engineer, and Security Engineer — the full platform engineering stack.
I work directly with the teams I engage with. There's no handoff to a junior resource after the sales call. The person you talk to is the person who builds the thing.
My delivery methodology is built around getting to working infrastructure faster than clients expect — without cutting corners on the things that matter in production: IAM correctness, CMEK, monitoring, promotion pipeline discipline. I've mapped those requirements rigorously. The spec exists before the first line of code.
My work is Google Cloud-focused. When engagements involve migrations from AWS or multi-cloud architecture decisions, I work from first principles and bring in the right specialists when the depth requires it.
I take on a limited number of engagements at a time — enough to give each one full attention. If you're building on Google Cloud and the infrastructure is slowing you down — or you want to get it right before it does — the form below takes two minutes.