Selected work
Systems, then what changed.
Built inside organizations. Some of these systems run in client environments and cannot be publicly detailed. Where that limit applies, the note stays on the problem, the architecture, the scale, and the outcome.
01 — Platform
Up to 35% lower running cost
Cloud enablement platform
A platform I built and operated across 12 AWS regions and more than 150 accounts.
The problem
A large cloud estate run by hand drifts. Accounts, Kubernetes clusters, spend, and policy each live in a different place, and the cost of that drift shows up on the bill.
What I built
A reusable cloud enablement platform: standardized foundations, automation, and the operational controls for a multi-account estate. It ran fully serverless. I built it and operated it.
How it worked
Account onboarding, inventory, compliance, security findings, and cost reporting sat on one platform. A Neptune graph held how the estate is related. A Kubernetes crawler covered EKS, AKS, and GKE, so the platform was not limited to a single cloud’s console. Recommendations and reports were what the organization remediated.
Before
- Separate accounts
- Separate consoles
- Spend and policy found by hand
After
- Account discovery
- Cost
- Security and compliance
- Inventory
- Serverless cloud enablement platform
- Neptune graph
- Reporting
- Kubernetes crawler — EKS, AKS, GKE
- AWS estate, with Azure and Google Cloud where the clusters ran
Outcome
The estate on this platform ran in 12 AWS regions and more than 150 accounts, with a cloud bill above one million dollars a month. After the recommendations and reports were remediated, running cost came down by up to 35 percent.
Technology
Terraform · Python · Kubernetes · Neptune · Checkov
02 — Onboarding
Four to six weeks → one click
Landing zone automation
A product enters a governed cloud environment in one action, not a multi-team queue.
The problem
Onboarding a new product or workload took four to six weeks. Organization policies, identity, baseline infrastructure, network placement, security, and encryption were separate pieces of work, coordinated across teams.
What I built
Landing zone automation that deploys the cloud foundation and the product-specific configuration in a single action. The point is not a new account. The point is a workload that arrives inside policy, on the right network, ready for the team that will build on it.
How it worked
One action applies organization policies, SSO roles, baseline infrastructure, the correct Cloud WAN segment, shared-network access, security policy, and encryption. Accounts already sat on Cloud WAN, joined by segments. For a different organization, the same pattern attached through Transit Gateway.
Before
- Policies
- Identity
- Baseline
- Network
- Security
- Several teams, four to six weeks
After
- Foundation and product-specific configuration
- Workload in the governed environment, on the correct segment
Outcome
Onboarding no longer waits four to six weeks. The workload arrives on the correct network segment, inside policy, and encrypted. On a separate Azure landing zone, tagging, guardrails, and cost visibility were followed by about 20 percent lower cloud spend.
Technology
Terraform · Cloud WAN · Transit Gateway · Organizations · SSO
03 — Service platform
The next service starts on the platform
Automated service foundations
Infrastructure, delivery, and operational wiring generated with the service. Canary included.
The problem
Every new service rebuilt the same plumbing: infrastructure, structure, configuration, pipeline, and the public-or-private edge. The product work waited on that.
What I built
I was the initial developer of a service generator. It takes the required information and produces the foundational layer: infrastructure, service structure, configuration, CI/CD, deployment, and operational wiring. Canary deployment is included by default.
How it worked
The generator stamps the service, the container, and the pipeline. The edge in production was public and private Apigee on Google Cloud, and public and private AWS API Gateway. The team that follows writes the business function on a platform that already knows how to ship.
Shape
- Required service information
- Generator — infrastructure, structure, configuration, CI/CD, operations
- Canary deployment by default
- Apigee or API Gateway — public or private
Outcome
The second service does not rebuild the platform. Authentication, the public-or-private choice, the pipeline, and a canary path are already there.
Technology
Python · Apigee · API Gateway · CI/CD
04 — Data platform
A producer writes only if it passes
Data and event platform
Event-driven ingestion into Iceberg, with schema and quality checks before the write.
The problem
Producers published events, and each team invented its own path into durable tables. A bad payload could land beside good ones, and the analytical dataset drifted.
What I built
An onboarding path for any Kafka producer: schema check, Great Expectations, guardrails, then an Iceberg table in that producer’s own partition. Failures stay out of the lake.
How it worked
The producer is registered once. Validation runs before the write. What lands is an analytical table the rest of the platform can trust, partitioned by producer, rather than a shared bucket of unchecked events.
Shape
- Schema check
- Great Expectations
- Guardrails
- Iceberg table in that producer’s partition
Outcome
Each producer gets its own partition. Quality failures do not land in the lake.
Technology
Kafka · Great Expectations · Iceberg
05 — Asset pipeline
Upload, scan, durable URL
Digital asset pipeline
Any digital asset, not images alone, ends as a URL a product can keep.
The problem
A product needed a checked, durable address for a file. A folder was not something it could rely on.
What I built
A path from upload through scan to a CDN URL, for any digital asset.
How it worked
The file is scanned before it is published. What the product stores is the URL, not a copy of the object.
Outcome
An asset is scanned before it is published. What remains is a durable CDN URL.
Technology
Upload · Scan · CDN