Case study · Symbl · 2023–Present

Operating the platform behind Symbl

As Technical Lead I own the cloud platform behind Symbl: approximately 7–8 AWS environments, reusable Terraform, GitHub Actions delivery to ECS/ECR with releases under six minutes, observability, networking and security, billing, and incident response.

AWS production, UAT and development environments: 7–8
Per release, within the GitHub Actions to ECS workflow: <6 min
Reusable modules shared across environments: Terraform

Role · Technical Lead, Cloud & Engineering

What I did

Own cloud architecture and infrastructure across the environments.
Designed the reusable Terraform modules.
Moved deployments from Jenkins on EC2 toward GitHub Actions with ECS/ECR.
Run monitoring, alerting, networking, security, cloud billing and cost tracking, and incident response.
Set product direction with the founder, then build and ship internal applications, including hosting, domains and routing.
Managed the mobile apps’ builds and releases to the App Store and Play Store, through to production, while the developers built the apps.

Team context

What the team did

Once a process is solid I delegate: I grant developers access and they do the implementation, while I stay hands-on with core infrastructure.
I oversee releases, test on staging and push to production, and step in when things are escalated to me.
Applications I hand over, such as the CRM integration, are completed by the developers as I ask.

Context

Symbl is a healthtech startup. I joined in March 2023 as a Founding Engineer and am now Technical Lead, working directly with the founders with broad ownership of infrastructure and engineering operations. The product was rebranded from YORE Care to Symbl along the way.

The platform runs on AWS across approximately 7–8 dedicated production, UAT and development environments, spanning VPCs, IAM, ECS, EC2, ECR, Route 53, ALBs, RDS, Secrets Manager and CloudWatch. The platform serves Symbl’s entire internal team and all of its users.

Problem

Seven to eight environments only stay useful if they stay consistent. A platform only stays reliable if someone also owns the less visible parts: releases, monitoring, networking, access, billing and incidents.

Constraints

A small, fast-moving engineering team working closely with the founders.
Separate production, UAT and development environments.
Existing Jenkins-based deployments to EC2 to move away from.
One owner across architecture and day-to-day operations, including cloud billing and cost tracking.

Architecture

Fig. 01: Symbl cloud platform blueprint, in four layers.

Layered view of the platform. Solid arrows show documented workflows; dashed outlines group related components without implying a data path.

Layer 1: infrastructure and environments, defined by reusable Terraform modules.
Layer 2: deployment and delivery, with GitHub Actions building images and deploying to ECS from ECR.
Layer 3: observability and operations: Prometheus, Grafana, CloudWatch and Slack alerts.
Layer 4: security, networking and cost: NGINX with Certbot TLS, access, and billing and cost tracking.

Fig. 03: One set of Terraform modules, the same stack in every environment

Alternatives

What happened

The earlier approach deployed from Jenkins onto EC2. The change moved toward GitHub Actions with Amazon ECS and ECR.

Retrospective analysis

Keep Jenkins and improve it: Possible, but keeps a server to maintain and patch alongside the product.
Kubernetes on AWS: More flexible, with more to operate. ECS is simpler for a small team with ordinary container workloads.
Copy-paste per environment: Fast at first, and the usual source of environment drift.

Decision

Describe every environment with reusable Terraform modules, and ship through GitHub Actions to ECS with images in ECR. The pipeline lives next to the code, and a new environment is a configuration change rather than a project.

Implementation

01
1 · Infrastructure & environments
Reusable Terraform modules standardize provisioning across approximately 7–8 AWS environments, significantly reducing manual setup work.
02
2 · Deployment & delivery
GitHub Actions automates validation, image builds, versioning and production deploys to ECS from ECR, replacing Jenkins-based deployments to EC2. Releases take under 6 minutes. Release timing is case by case: I test on staging, then push to production. I ship and iterate quickly on what the business needs.
03
3 · Observability & operations
Prometheus, Grafana and CloudWatch monitor system health, with Slack alerting for faster incident detection. I handle incident response and troubleshooting.
04
4 · Security, networking & cost
Linux production infrastructure runs behind NGINX with Certbot-managed TLS, with routing and cloud security on top. Where ECS would not make sense cost-wise, I run dedicated EC2 servers, locked down with IAM, NACLs and security groups, with Elastic IPs routed and attached to a domain. I also own cloud hosting, billing and cost tracking.

Results

Releases take under 6 minutes.
New environments come from shared modules, not manual setup.
Faster incident detection through Slack-integrated alerting.

Measurable outcomes

7–8: AWS environments operated; From my work
<6 min: Release duration within Symbl’s GitHub Actions to ECS workflow; From my work

Trade-offs & Failure Modes

From the project

Moving from Jenkins on EC2 to GitHub Actions on ECS/ECR traded a self-run build and deploy path for managed services and pipelines that live next to the code.

General analysis

Blast radius: Shared modules mean a change can reach every environment, so changes need review and staged rollout across environments.
Environment drift: Modules reduce drift, but out-of-band changes in the console can still diverge state and need detection.
Rollback: Versioned images make rollback a redeploy of a previous tag; database migrations are the harder case.
Alert fatigue: Alerts that fire often and mean little teach a team to ignore them, so thresholds need revisiting.
Concentrated ownership: Broad ownership concentrates knowledge in one person, so documentation and handoffs matter.

Lessons

Standardize what repeats. Modules pay for themselves from the second environment.
Pipeline speed compounds: short releases encourage smaller, safer changes.
Observability is part of delivery. A fast deploy only helps if you can see whether it worked.
Ownership includes the unglamorous parts: networking, billing and incidents.

Questions People Ask

The follow-ups this work tends to raise, answered directly.

How do you keep 7–8 environments consistent?

Reusable Terraform modules define the shared infrastructure, so every environment is built from the same code instead of manual setup.

How fast do releases go?

Under 6 minutes per release. GitHub Actions handles validation, image builds, versioning and production deploys to ECS from ECR. They are also frequent, because I ship and iterate quickly on what the business needs.

What did the GitHub Actions setup replace?

Jenkins-based deployments to EC2.

How do you find out when something breaks?

Prometheus, Grafana and CloudWatch monitor system health, with Slack alerts for faster incident detection.

Who owns cloud billing and cost tracking?

I do, alongside cloud hosting, deployments and infrastructure operations.

Why dedicated EC2 servers for some workloads?

Where ECS would not make sense cost-wise, dedicated EC2 servers do. They are locked down with IAM, NACLs and security groups, with Elastic IPs routed and attached to a domain.

Are you hands-on, or leading?

Both. I set product direction with the founder, build the first version myself, then delegate with access I grant and stay on the escalation path. I oversee releases, test on staging and push to production.

Do you build applications as well?

Yes. I built and shipped internal applications and business-facing software, from research through hosting, domains and routing. For Symbl’s mobile apps, the developers built them and I managed the build and releases through the App Store and Play Store until they were live in production.

At a glance