Selected work

Systems work, without the confidential bits.

These are compact accounts of the kinds of platform work I have owned: delivery systems, reliability, security, and the operational habits that make changes safer. Details are deliberately sanitized.

Multi-country platform · Griya Mitra Digital

Making a growing platform easier to run across countries

I helped shape the cloud, security, deployment, and solution architecture for a high-throughput system serving Indonesia, Vietnam, Thailand, and the Philippines.

Constraint: Multiple markets, peak traffic, regulatory needs, and a platform that had to keep moving.
Work: Architecture, deployment patterns, observability, platform documentation, and cost-aware capacity decisions.
Evidence: More than 100 production deployments; GitOps adopted across 10+ services; monitoring designed around a 99.99% availability target.

I cannot publish internals, traffic figures, or customer details. The useful lesson is that the operational model matters as much as the cloud diagram: ownership, rollback paths, and signals need to be obvious before the next incident.

Delivery systems · Pintek

Turning deployments into a repeatable platform capability

The job was not simply to run CI/CD. It was to make a growing set of services easier to deploy, inspect, and roll back without relying on one operator’s memory.

Constraint: A mix of application workloads, changing cloud environments, and teams with different levels of operational maturity.
Work: Cloud-native service patterns, Kubernetes enablement, CI/CD, monitoring, logging, and operational documentation.
Outcome: A more consistent delivery path and shared operating knowledge instead of deployment work living in isolated runbooks or chat history.

The interesting part was the team interface: safe defaults, training, and a path back when a release did not behave as expected.

Security & regulated operations · Pintek / Erudifi

Building delivery and security controls that can survive an audit

In regulated environments, security controls cannot be a slide deck after the infrastructure is already built. They need to show up in access, delivery, evidence, and routine operations.

Constraint: ISO/IEC 27001:2013 requirements, OJK-related technical readiness, and teams that still needed to ship.
Work: Cloud and security architecture, least-privilege access, documentation, audit preparation, and deployment controls.
Outcome: Infrastructure and documentation prepared for ISO/IEC 27001:2013 audit work while platform requirements remained part of normal engineering delivery.

The practical takeaway: an audit is easier when the system already leaves evidence behind. GitOps, explicit access boundaries, and useful documentation do more work than a last-minute compliance sprint.

Open source

Security impact, explained before the sync

Go · Kubernetes · GitOps · Kustomize · Helm

kube-blast-radius

Compare rendered Kubernetes manifests before and after a change, then surface the new security capability, external exposure, or workload-hardening regression that deserves review before a GitOps sync.

It works from raw YAML, Kustomize, or Helm renders without cluster access or Secret values. Its output is deliberately a review signal—not a claim of complete cluster security coverage.

View source v0.1.0 release

Go · Docker Compose · CI

probe-contract

A small CLI that compares a declared liveness/readiness contract with Docker Compose healthchecks. It catches a common failure mode: a rollout claims to gate on readiness while the configured probe only checks whether the process is alive.

It is deliberately narrow. It does not call live endpoints or claim to understand business health; it makes deployment assumptions explicit and checks them for disagreement.

View source v0.1.0 release

Selected writing

Notes from the same operating mindset

July 21, 2026 · Security engineering build note

Need someone who thinks about the path after deployment?

I am open to conversations about platform engineering, reliability, cloud security, and infrastructure leadership.

Get in touch LinkedIn

Systems work, without the confidential bits.

Making a growing platform easier to run across countries

Turning deployments into a repeatable platform capability

Building delivery and security controls that can survive an audit

Security impact, explained before the sync

kube-blast-radius

probe-contract

Notes from the same operating mindset

I built a security-impact diff for GitOps

I built a small linter for health checks that disagree with rollouts

I made a healthy service page on purpose

A rollout needs a return address

I tried code-review-graph in Docker. Useful, but don’t swallow the 528x number whole.

Need someone who thinks about the path after deployment?