Skills

What I bring

Nearly a decade of contract work across Node.js and Go and cloud infrastructure, with a focus on maintainable, long-lived systems.

Simplicity-first product thinking

I'm increasingly biased toward systems that stay boring: stable APIs, low churn dependencies, and the ability to ship features without a mandatory upgrade treadmill — TypeScript majors, framework rewrites, and all that.

Languages & runtimes

I started with Node.js and the JavaScript ecosystem, carrying both through years of production contract work. Go is now my primary language for server-side applications. I have some Android experience in Kotlin on the side.

SPA architecture & hypermedia

I understand how SPAs are built and maintained — and more importantly, when they're the wrong tool. I've migrated production apps away from heavy client-side frameworks toward hypermedia-driven approaches and haven't looked back.

Constraints as a design principle

I believe constraints make things better — tighter scope, fewer dependencies, clearer tradeoffs. I apply this to architecture decisions as much as to product ones.

Cloud infrastructure (AWS & GCP)

I reach for serverless containers over functions — stateful, long-running services that fit real production workloads. I've run things on both AWS and GCP and know where each shines.

Platform-resilient systems

I build for longevity. I avoid tight coupling to frameworks that change direction — the Next.js → RSC shift is a good example — so the systems I deliver stay maintainable regardless of ecosystem churn.

Managed PostgreSQL & migrations

I've run managed Postgres on AWS and GCP across multiple teams. I care about data integrity, multi-developer migration strategies, and modern workflows like database branching.

Reactive UIs without framework lock-in

I'm experimenting with signals-based frontends and event sourcing to build reactive UIs that don't depend on any particular JS framework. This site is a live example of that approach.

Pragmatic testing

I'm not a TDD practitioner, but I know which parts of a system actually need test coverage — integration points, data boundaries, invariants worth protecting. I write tests there, not to chase metrics.

Observability & production debugging

I treat production as something to be understood, not just deployed. Structured logs, meaningful error surfaces, and knowing what's happening without guessing are non-negotiables for me.

Independent & async collaboration

Most of my work has been contract-based, which means strong written communication, clear deliverables, and the discipline to make good decisions without constant back-and-forth.