Skip to Content

Founding Engineer · Platform Infrastructure · Cloud Architecture · Product Engineering

I build the infrastructure that makes software work.

I work across cloud architecture, platform engineering, and product development, turning complex infrastructure and operational problems into systems teams can ship, scale, and operate with confidence.

Explore Selected Work Get in Touch
Environments
7–8
Release
<6 min
Provisioning
<1 min
Products shipped
3
System topologyA scope map of my work. Platform infrastructure: Terraform modules and a GitHub Actions pipeline feed three environments, production, UAT and development, observed by Prometheus, Grafana and CloudWatch with Slack alerts. Product engineering: a WhatsApp dashboard, a comparison tool and a B2B catalogue, each built or adapted, deployed and handed off.Terraformreusable modulesGitHub Actionsbuild + deploy<6 min / release7–8 ENVIRONMENTSproductionECS · ALB · RDSuatsame modulesdevelopmentsame modulesPRODUCT ENGINEERING · BUILT, DEPLOYED, HANDED OFFWhatsApp dashboardinternal toolComparison toolinternal toolB2B cataloguelive · publicObservabilityPrometheus · Grafana · CloudWatch→ Slack alerts
Fig. 01: Scope map of my work

01 / Selected Work

Building the systems behind the product.

Cloud infrastructure, developer platforms, deployment systems, internal products, and the engineering decisions that make them work in production.

My work spans founding-stage infrastructure, multi-environment cloud platforms, internal applications, developer experience, and infrastructure migrations across AWS, Azure, Cloudflare, Kubernetes, and bare-metal systems.

See all seven projects →

SymblTechnical Lead · Mar 2023 – Present

Platform Engineering · Cloud Operations

Symbl · 2023–Present

Operating the platform behind Symbl

I work directly with the founders as Technical Lead, with broad ownership of infrastructure and engineering operations across approximately 7–8 AWS production, UAT, and development environments. The platform serves the entire internal team and all of Symbl’s users.

That spans reusable Terraform modules, a move from Jenkins toward GitHub Actions with ECS/ECR (releases under six minutes), monitoring through Prometheus, Grafana, CloudWatch, and Slack, and networking behind NGINX with Certbot-managed TLS, alongside cloud security, billing and cost tracking, and incident response.

Explore the platform architecture

At a glance

production, UAT, and development
7–8 environments
release duration
Under 6 minutes

Key engineering areas

  • AWS and multi-environment infrastructure
  • Terraform modules
  • ECS, ECR, and GitHub Actions
  • Observability and Slack alerting
  • Networking, NGINX, and TLS
  • Security, billing, and incident response
Symbl cloud platform blueprintFour layers. Infrastructure and environments: reusable Terraform modules define approximately seven to eight environments. Deployment and delivery: GitHub Actions validates, builds, versions and pushes images to ECR for deployment on ECS, replacing earlier Jenkins deployments to EC2. Observability and operations: Prometheus, Grafana, CloudWatch and Slack alerts, with incident response. Security, networking and cost: NGINX with Certbot TLS, access and secrets, and billing and cost tracking.01Infrastructure& environments02Deployment& delivery03Observability& operations04Security, network& costTerraformreusable modules≈7–8 AWS ENVIRONMENTSproductionuatdevelopmentGITHUB ACTIONS · UNDER 6 MIN PER RELEASEvalidatebuildversionECRECSreplaced: Jenkins-based deployments to EC2PrometheusGrafanaCloudWatchSlack alertsincident response · troubleshootingEdge & routingNGINX · Certbot TLSAccess & securityIAM · Secrets ManagerCost & billingtracking · ownershipdocumented workflowgrouping only, no data path implied
Symbl cloud platform blueprint, in four layers.
WhatsApp dashboard and handoffAn internal dashboard, adapted from open source, works with the Meta WhatsApp Business Platform: Cloud API, templates and webhooks. After handoff, the development team built the CRM integration.Dashboardinternal toolMeta WhatsAppCloud API · webhooksHANDOFFCRM integration · development team

Product Engineering · Integrations

Building an internal WhatsApp operations dashboard

I researched and selected an open-source tool as a starting point, then adapted it substantially into an internal WhatsApp operations dashboard for Symbl, integrated with the Meta WhatsApp Business Platform: Cloud API, message templates, webhooks, and messaging.

Explore the integration and handoff

Comparison workflowA care expert adds options and generates a link. The customer compares options, the selection locks, and the customer continues on WhatsApp.CARE EXPERTCUSTOMER1Options2Link3Compare4Lock5WhatsAppunique link per customer · selection locks

Product Engineering · Internal tools

From clinical recommendations to a customer-ready comparison

An internal application for Symbl’s care experts: they add medicine or lab-test options from different vendors, the tool generates a unique comparison link, and the customer opens it, selects an option (locked once chosen), and is redirected to Symbl’s WhatsApp with a prefilled message.

Explore the workflow and handoff

Catalogue stackAn open-source foundation, adapted with a custom frontend and backend, delivers the live B2B catalogue at catalogue.symbl.health.catalogue.symbl.healthliveCustom frontend + backendOpen-source foundationadapt

Product Engineering · Open source

Adapting an open-source platform into Symbl’s B2B catalogue

I researched and selected an open-source CRM/application as a foundation, then adapted it for Symbl’s B2B use case with a custom frontend and backend, covering the user experience, application workflows, deployment, domain, and routing.

Explore the catalogue project

The CRM integration for the WhatsApp dashboard and the comparison tool was done by the development team after handoff.

Prepare.shFounding Engineer · Feb 2025 – Jul 2026

Developer Infrastructure

Prepare.sh · 2025–2026

Rebuilding the developer environment stack

Interactive developer environments exposed the limitations of the existing Azure AKS and vCluster approach. I contributed to the move to bare-metal Hetzner infrastructure running K3s, alongside a new GitHub Actions-based delivery workflow.

The result: environment provisioning dropped from approximately 2–3 minutes to under a minute.

Explore the architecture and migration

At a glance

environment provisioning
Under 1 minute
infrastructure cost before and after migration, as reported by the company
~$7,900 → ~$330 / month
platform scale
~10,000 users

Key engineering areas

  • Kubernetes and K3s
  • Azure AKS and vCluster
  • Docker and environment isolation
  • Bare-metal infrastructure on Hetzner
  • GitHub Actions and CI/CD
  • Terraform and Helm
Developer environment architectureGitHub Actions deploys to a bare-metal Hetzner K3s cluster that runs isolated learner environments. Static assets, object storage and databases sit on Cloudflare R2, D1 and Workers. A dashed box shows the earlier Azure AKS and vCluster setup.AFTERGitHub ActionsCI/CDK3s · Hetzner bare metalself-managed clusterenvenvenvisolated · provision <1 minCloudflareR2object storageD1databasesWorkers+ CDNBEFOREAzure AKS · vClusterDocker-in-Docker limits · provisioning ~2–3 min · ACR, Functions, Event Hub, Blob, CDN
Architecture
Provisioning time before and afterBefore, provisioning an isolated environment took about two to three minutes on Azure AKS. After the move to bare-metal K3s it takes under one minute.01 min2 min3 minAzure AKSbefore~2–3 minBare-metal K3safter< 1 min
Environment provisioning time, before and after (approximate)
Monthly infrastructure cost before and afterThe company reported infrastructure costs of about 7,900 dollars per month on Azure, and about 330 dollars per month after the migration, roughly 96 percent lower.$0$4,000$8,000Azurebefore~$7,900 / monthAfter migrationafter~$330 / month≈96% lower (calculated)
Monthly infrastructure cost before and after the migration. Company-reported; reflects the migration as a whole.

  • Cloud Infrastructure & Platform Architecture

    Moving core infrastructure across cloud boundaries

    Worked on migrating core infrastructure involving CDN, object storage, and databases from Azure toward Cloudflare R2, D1, and Workers, alongside multi-region bare-metal Kubernetes infrastructure on Hetzner.

    The work spanned infrastructure architecture, platform components, and the trade-offs involved in moving services across different hosting environments.

    Explore the infrastructure migration

    Service migration mapAzure AKS and vCluster moved to K3s on Hetzner. Azure DevOps pipelines moved to GitHub Actions. Azure CDN, object storage and databases moved to Cloudflare CDN with Workers, R2 and D1.BEFORE · AZUREAFTER · SELF-MANAGED + CLOUDFLARECOMPUTEAzure AKS + vClusterCOMPUTEK3s on Hetzner bare metalCI/CDAzure DevOps YAML pipelinesCI/CDGitHub ActionsCDNAzure CDNCDNCloudflare CDN + WorkersOBJECT STORAGEAzure Blob StorageOBJECT STORAGECloudflare R2DATABASESAzure-hosted databasesDATABASESCloudflare D1
    Service migration map, Azure to Hetzner and Cloudflare

  • Developer Tooling & Platform Engineering

    Building an interactive AWS training platform

    Designed and implemented an interactive AWS training platform by extending LocalStack to replicate/support core capabilities associated with LocalStack Pro, integrated into a custom frontend and backend.

    This work connected infrastructure behavior with a user-facing developer experience, bringing cloud-service simulation into an interactive learning environment.

    Explore the platform and implementation

    AWS training platform architectureA learner uses a custom frontend, which talks to a custom backend, which drives LocalStack extended to support core LocalStack Pro capabilities and simulate AWS services.Learnerhands-onFrontendcustom GUIBackendcustomLocalStackextended for coreLocalStack Procapabilitiessimulated AWS
    Architecture

02 / How I Work

I own it first, then delegate with oversight.

Product direction comes from the founder and me. I build the first version myself, get the process right, then delegate with access I control, and stay on the escalation path.

How I own a systemFive steps. Define the product with the founder. Build the first version myself. Ship it: hosting, domain, staging then production. Then delegate by granting access so developers build, and oversee by testing on staging and stepping in on escalations. Feedback from oversight returns to the definition step.FEEDBACK LOOPDefinewith founderPRD + feedbackBuildI build thefirst versionShiphost · domainstaging → prodDelegategrant accessdev team buildsOverseetest on stagingescalationsI do it myselfonce the process is solid

Where this shows up

  • Symbl platform

    1. Designed and built it myself
    2. Delegated implementation once the process was solid
    3. I own billing, security and incidents, and step in on escalations

  • Mobile apps

    1. Developers build the apps
    2. I manage the build and every release: release notes, App Store, Play Store
    3. Until each app is live in production

  • WhatsApp dashboard · Comparison tool

    1. Built, hosted on AWS, domain and routing
    2. Developers integrate it into the CRM, as I ask
    3. I test on staging, then push to prod

  • B2B catalogue

    1. Selected the open-source base and adapted it
    2. Frontend and backend, hosting and domain
    3. Live as the B2B entry point

  • Prepare.sh

    1. Worked alongside the founder on everything: web, content, labs, clients, deployment
    2. Delegated part of it to a teammate
    3. The founder and I focused on product and tech

I did it myselfdelegated, with me overseeing

Technologies I work with

Cloud
AWSAzureCloudflareHetzner
Platform
KubernetesK3sDockerTerraformHelmAnsible
Delivery & ops
GitHub ActionsJenkinsAzure DevOpsPrometheusGrafanaCloudWatch
Systems
LinuxNGINXCertbotNetworking
Product & integrations
Meta WhatsApp Business PlatformLocalStackOpen-source adaptation
Languages
GoPythonBash

03 / Engineering Principles

How I approach infrastructure.

  1. 01

    Match the architecture to the constraint.

    Moving isolated environments from AKS to bare-metal K3s followed a specific limit, Docker-in-Docker, not a preference for one platform.

    From constraint to architectureDocker-in-Docker limits on Azure AKS and vCluster led to bare-metal K3s on Hetzner, and provisioning dropped from about two to three minutes to under one minute.CONSTRAINTDocker-in-Dockerlimits on AKS + vClusterARCHITECTUREBare-metal K3sHetznerOUTCOME< 1 minwas ~2–3 min

  2. 02

    Automate what repeats.

    Reusable Terraform and Helm modules exist so the second environment costs far less than the first.

    One module set, many environmentsReusable Terraform and Helm modules produce the same stack in development, UAT and production.Terraform · Helmreusable moduleswritten oncedevelopmentsame stackuatsame stackproductionsame stack

  3. 03

    Make it observable.

    A deploy is only done when you can see it working. Prometheus, Grafana, CloudWatch and Slack close that loop.

    Ship, observe, alertA loop: a deploy ships through GitHub Actions, Prometheus, Grafana and CloudWatch observe system health, and Slack carries the alerts.ShipGitHub Actions→ ECSObservePrometheus · GrafanaCloudWatchAlertSlack

  4. 04

    Know how it fails.

    Every design has a failure mode: a node, a bad release, a drifted environment. Name it before it names itself.

    Failure modes and responsesThree general failure modes and the response planned for each: a failed node reschedules on spare capacity, a bad release redeploys the previous image tag, and environment drift is caught by reviewing plan output.Node failsreschedule on spare capacityBad releaseredeploy the previous image tagEnvironment driftsreview plan output, reconcile

  5. 05

    Infrastructure serves delivery.

    The point is a team that ships and operates with confidence, so releases got shorter and environments got boring.

    Release pipeline under six minutesGitHub Actions validates, builds, versions and pushes an image to ECR and deploys it on ECS. A release takes under six minutes. It replaced Jenkins-based deployments to EC2.validatebuildversionECRECSunder 6 minutes per release

04 / Contact

Building something that has to run?

If you are a founder, an engineering leader or a collaborator with infrastructure that needs to ship and stay up, I would like to hear about it.