Full-stack and infrastructure engineer in Thailand. Six years, self-taught.

A multi-tenant inbox took 14.4 seconds to load for its busiest users, and 0.09 after the row-level-security policy was replaced — checked against the old figures for both rows lost and rows leaked, because a query that got faster by showing the wrong tenant's data is not a fix.

Languages

Application

Data & messaging

Integrations & automation

Testing

Orchestration & runtime

Platform & operations

I like problems that start out vague — a page that just "feels slow", a job that quietly stopped running — and end with a number anyone can check.

I also like software that is orderly and easy to use; Kubernetes and NestJS are two I enjoy working with for exactly that reason. But structure on demand: a pattern earns its place when the problem asks for it, not because it is on a list.

Now — a multi-tenant webhook ingestion platform in production, and the infrastructure under it: Terraform, and a seven-node k0s cluster. I also run a smaller k3s cluster of my own, spanning on-prem and cloud over a WireGuard mesh, which is where I try things before they touch anyone else's work.

I have also moved a production service off one cloud onto another — Cloud Run to a self-hosted registry and static host — which taught me more about what a platform actually gives you than building on it did.

Cross-cutting rules, domain skills with explicit routing, versioned agent definitions that separate implementation from acceptance review, and an evaluation harness that indexes my own session transcripts.

I built it for my own work, then measured whether it actually changed how I work — corrective turns dropped between 25% and 42% depending on how you define a correction, at flat input effort.

→ How I measured it, and what I would still verify  ·  Where the rules came from