FussyMonkey.dev — Handcrafted Code. Mildly Obsessive.

FussyMonkey.dev

Independent engineering practice focused on platform modernization, operational tooling, and distributed systems.

Handcrafted code. Mildly obsessive.

⚡ Practice Status: Fully booked for greenfield development. Available selectively for infrastructure untangling, platform migrations, and release bottlenecks that have achieved sentience.

Selected Work

Engineering problems solved

# .github/workflows/release.yml
name: Release Pipeline
on:
  push:
    tags: ['v*.*.*']
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Security Scanner
        run: trivy image --severity HIGH,CRITICAL $IMAGE_NAME
      - name: Deploy Canary (10% traffic)
        run: helm upgrade --install --set image.tag=${{ github.ref_name }} canary-gateway ./charts/gateway
      - name: Verify Health Metrics
        run: ./scripts/verify-health.sh --timeout=300s

Release Automation System

Automated a multi-stage manual release workflow that had become a recurring operational bottleneck. Reduced deployment friction, improved repeatability, and removed several high-risk manual steps.

// CI/CD// automation// operational tooling
// gateway/middleware/strangler.go
package middleware

import (
	"net/http"
	"strings"
)

// RouteTraffic directs traffic based on migration status
func RouteTraffic(legacy, modernized http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		// Modernized billing system cutover is 100% complete
		if strings.HasPrefix(r.URL.Path, "/api/v1/billing/") {
			modernized.ServeHTTP(w, r)
			return
		}
		// Default fallback routing to legacy monolith
		legacy.ServeHTTP(w, r)
	})
}

Platform Migration

Incremental migration of a legacy monolith to a maintainable service architecture. Focused on operational stability during transition — zero-downtime cutover with rollback capability at every stage.

// modernization// distributed systems// reliability

Engineering Practice

How I operate and when we should talk

Usually called when:

  • 01Deployments require ceremony and luck.If releases are after-hours operations where engineers wait on call "just in case," the automation is failing you. I build repeatable release pipelines that run during the day with zero drama.
  • 02Nobody wants to touch the billing system. Or any other core module that has drifted into institutional folklore. I incrementally extract fragilities and modernize them via strangler migrations with dual-write safety.
  • 03Tribal knowledge has replaced documentation. When onboarding takes weeks and staging setups are precious snowflakes, developers stop shipping. I build self-service developer platforms and standardized CLI tools.
  • 04Incidents are resolved via SSH and guess-work. If you lack structured tracing across boundaries, finding a latency spike is needle-in-a-haystack work. I instrument systems with clean OpenTelemetry context propagation.
Technical Stance

// Pragmatism > Dogma

I don't advocate for complete rewrites or trendy architectures. I value stable, boring infrastructure that continues to run long after the original deployment heroics wear off.

// Tooling as Leverage

Automation is only useful if it matches the team's cognitive model. Clumsy automation is worse than manual execution; tooling must feel like a natural extension of your workflow.

// Lived-in Systems

Every production system is slightly messy. The goal isn't academic purity; the goal is creating interfaces, boundaries, and tests that make the mess safe to modify and operate.