What I do

I help teams ship software that is easier to run and easier to evolve.

The work usually sits at the overlap of infrastructure, application engineering, and practical architecture. I like systems that are clear to extend, reasonable to support, and grounded in how the product actually gets used.

Core areas

These are the main buckets the work tends to fall into, along with the tools that often support each one.

DevOps

Infrastructure and delivery

A lot of my recent work has centered on infrastructure, deployment pipelines, monitoring, and operational reliability, with AWS at the center of that stack.

  • AWSAWS
  • JenkinsJenkins
  • DockerDocker
  • TerraformTerraform
  • KubernetesKubernetes
  • CloudflareCloudflare
  • New RelicNew Relic
  • PagerDutyPagerDuty

Software engineering

Applications, APIs, and product systems

I build web applications, REST APIs, CMS platforms, and iOS applications with an emphasis on maintainable structure and sensible abstractions.

  • Recent application work includes shipping on Vercel and building with Supabase.
  • I also set up GitHub Actions workflows for CI/CD and ongoing delivery.
  • LAMPLAMP
  • Dependency injectionDI
  • iOSiOS
  • RESTREST
  • CMSCMS
  • Unit testingUnit Tests

Languages

The languages I reach for most

These are the languages I use most often or feel most comfortable working in when the project calls for them.

  • PHPPHP
  • SwiftSwift
  • SwiftUISwiftUI
  • BashBash
  • JavaScriptJavaScript
  • HTMLHTML
  • CSSCSS

Supporting tools

Frameworks and platforms that keep work moving

The supporting tools matter too. Good delivery depends on version control, release tooling, frameworks, and the systems that help teams stay productive.

  • XcodeXcode
  • GitGit
  • TestFlightTestFlight
  • LaravelLaravel
  • CakePHPCakePHP
  • YiiYii
  • WordPressWordPress

Principles I keep reaching for

I am not rigid about methodology, but these principles consistently lead to code that is easier to change and easier to reason about.

S

Single Responsibility

Keep classes and modules focused so they are easier to understand, change, and debug.

O

Open / Closed Principle

Extend behavior when needed, but avoid rewriting stable code just to add something new.

L

Liskov Substitution Principle

Derived types should behave in ways that do not break the code using the shared abstraction.

I

Interface Segregation Principle

Smaller, more specific interfaces usually produce cleaner designs than broad ones that do too much.

D

Dependency Inversion

Depend on abstractions instead of concrete implementations so systems stay easier to test, swap, and evolve.