A computer lab in Kathmandu. I typed <marquee> into Dreamweaver, hit preview, and watched my name scroll across the screen. Nobody told me it was bad practice. Nobody had to. I was hooked.
I didn't plan what came next. I just kept following what felt interesting, and the tools kept changing faster than I could keep up.
The Dreamweaver Days
HTML and CSS were my first real languages — not in the computer science sense, but in the I can make something appear on a screen sense. Tables inside tables. font tags everywhere. Files saved as index_FINAL_v3_REALLYFINAL.html.
What those years actually taught me was how to think about structure. How a page is laid out. How content flows.
I was also deep into Adobe Flash — 2D animations, interactive banners, motion graphics that played inside the browser. Timeline-based animation, ActionScript, frame-by-frame tweening. It felt like filmmaking and coding at the same time. Every website had a Flash intro back then, and I was one of the people making them.
The pattern was the same across all of it: take something complex, make it understandable, make it look good. The medium changed. The instinct didn't.
The CMS Deep Dive
Before frameworks took over, I spent a long stretch living inside CMS platforms — and I mean really inside them, not just installing themes.
Drupal was where I first got deep: custom theme development, module development, hooks, custom content types. Steep learning curve, but it taught me a lot about how a well-architected system exposes itself for extension. Then Joomla — component and plugin development, the MVC pattern baked into the CMS itself before I'd even heard the term properly.
And then WordPress. I was writing custom plugins, building theme frameworks, hooking into the action and filter system. The plugin architecture is deceptively elegant: drop in a file, hook into the right event, and you can change almost anything. It was my first real taste of event-driven thinking — years before I'd be doing the same thing at scale in Go.
WordPress democratized the web in a way Dreamweaver never could. A business owner in Sydney could update their own phone number without calling me. That shift in power was more significant than it seemed at the time.
I also got deep into Laravel around this period. PHP frameworks were maturing fast, and Laravel in particular felt elegant in a way the older ones didn't. Composer, Eloquent ORM, Artisan CLI. The craft was being taken seriously.
But I was starting to feel the ceiling. CMS platforms are powerful until they're not. The moment a client needs a complex pricing engine, a real-time data feed, a multi-tenant system, WordPress starts to feel like hammering a screw. You can do it. It just isn't right.
Frameworks Saved Me
Raw HTML and CSS wasn't enough for long. Clients wanted dynamic pages, databases, user logins, content they could update themselves.
I started with CMS platforms before discovering dedicated frameworks. Zend Framework, CodeIgniter, Laravel. Suddenly I wasn't writing the same authentication logic for every project. MVC architecture made me think about separation of concerns, something I'd keep returning to for the rest of my career.
One early project was a full travel advisory portal on Zend Framework and MySQL: thousands of monthly active users, payment gateway integrations, real data, real consequences when something broke.
Going Cloud-Native
Moving to Bangkok was a turning point.
For the first time, I wasn't maintaining websites. I was building systems. Marketing technology platforms. Customer Data Platforms. Integrations with Salesforce, Google Ads, Facebook, TikTok. Event-driven architectures processing tens of thousands of customer interactions every day.
The language changed too. PHP to Go. It felt like switching from a Swiss Army knife to a precision instrument: statically typed, compiled, opinionated in the right ways. Go forced me to be explicit about everything, which made me a better engineer.
The stack grew. gRPC, Kubernetes, Docker, GCP, Temporal, Zitadel, Elasticsearch. Where I used to FTP files to a server, I now had CI/CD pipelines, Helm charts, blue-green deployments. Where I used to think about a single database, I was thinking about distributed systems, eventual consistency, and query latency at scale.
Eventually I became Tech Lead: managing teams of engineers while still being the person who cared whether the gRPC handler was structured right and whether the Elasticsearch index mapping matched the query pattern. I never stopped writing code. I just wrote it at a different altitude.
Workflow Automation — The No-Code Middle Ground
Somewhere along the cloud-native journey, a different kind of tool entered the picture: Zapier, Make, and n8n.
These weren't replacements for engineering. They were force multipliers for integration work. Things that would have taken days of custom API work could be wired up in hours. Connecting marketing platforms, syncing data between CRMs, triggering workflows across third-party services without writing a full microservice for every handshake.
What struck me was how these tools exposed the same ideas I'd been applying in code — triggers, conditions, data transformation, error handling — but in a visual interface. Non-engineers could reason about workflows. That felt familiar: the same democratization story as WordPress, just for business logic instead of content.
n8n in particular became interesting when self-hosted deployments became serious. You could run it inside your own infrastructure, which mattered when data privacy was a concern. The overlap with AI automation today is direct — the same node-based thinking now chains LLM calls, webhook triggers, and vector searches into intelligent pipelines.
The AI Shift
Something has fundamentally changed in how software gets built.
Not the fundamentals — clean architecture still matters, good data models still matter, knowing your database still matters. But the pace has shifted.
The biggest change has been Claude Code. Not about replacing the engineer — about compressing the distance between idea and implementation. I can describe an architectural pattern in plain language and see idiomatic Go scaffolding appear. I can ask it to reason through a complex Elasticsearch query and it explains the tradeoffs. It's like pair programming with someone who has read every RFC and never gets tired.
Right now I'm building RAG architectures with Elasticsearch and pgvector: systems where AI can answer questions about a product catalog in natural language. The distance between "I want intelligent search" and "here is intelligent search" is shorter than it has ever been. Not because the hard problems went away. Because the scaffolding appears faster.
There's an irony here. The web started with HTML: declarative, tell the browser what you want. Then we went deep into how — imperative logic, algorithms, low-level control. With LLMs, we're swinging back toward what. Describe the outcome. The system figures out the how.
What I'd Tell My Younger Self
Don't worry about the right tool. Learn to think clearly about problems.
Dreamweaver, WordPress, Laravel, Zapier, Go, Claude Code: none of them were the point. The point was always the same question. Can you understand what someone needs, translate it into something a machine can do, and make it reliable enough that real people can depend on it?
That question is unchanged from the computer lab in Kathmandu to the distributed systems in Bangkok. The tools keep changing. The work doesn't.