Hey, I'm Andrew. I've spent 10+ years in software and worn a lot of hats along the way — I started out as a frontend engineer, got deep into accessibility, and over time grew into platform and data work. I write SDKs, infrastructure, and the data pipelines that everything else runs on.

These days I mostly build cloud-native data platforms and developer tooling in AWS. The work I like best is owning a problem end to end. Scoping it, shaping the architecture, shipping it, and watching people actually use it. That frontend background still sneaks in whenever I'm thinking about how a platform feels to the people building on it.

Fun fact: my degree is a BFA in Computer Game Design, so I came into all this from a pretty unusual angle.

Leaning further into platform and data engineering and building developer tools, internal platforms, and the AI/LLM infrastructure space. I'm also tinkering with open source on the side (see below).

A serverless, multi-tenant data workspace on AWS. Codebase walkthrough available upon request.

Live Site

A web portal where authenticated users bring their own data, manage it, and query it with SQL all in the browser, with no backend server. A React + TypeScript SPA talks directly to AWS using short-lived, scoped credentials. The entire stack auth, storage, static hosting, the analytics catalog, the async control planes, and every per-user IAM policy is provisioned with OpenTofu.

The mutation-heavy operations (creating shared spaces, building tables, sharing tables) run as fully declarative serverless pipelines — FIFO SQS → EventBridge Pipes → Step Functions orchestrating single-task Lambdas — all defined in OpenTofu alongside the rest of the stack.

Deployment is OIDC-based end to end. GitHub Actions assumes an AWS role via short-lived tokens, so there are no long-lived cloud keys stored anywhere. Three pipelines keep app, infra, and Lambda code independently deployable, and nothing reaches main without passing the gates.

On every pull request and push, the frontend CI must pass:

ESLint (lint) and Prettier (format:check) — style and correctness are enforced, not suggested. TypeScript strict build (tsc -b && vite build) — a type error is a failed build. Vitest integration-style tests with V8 coverage, mocking only the AWS service boundary so real hooks and components are exercised. Accessibility assertions via vitest-axe (axe-core) baked into the test suite.

The Python Lambdas have their own gates. Ruff lint plus pytest, with the real polars runtime installed in CI so schema-inference logic is tested for real rather than mocked away.

Infrastructure changes are gated too. OpenTofu fmt -check, validate, and plan run on every infra PR, and the plan is posted straight back to the PR as a comment for review before anything is applied. Merges to main trigger apply automatically for continuous deploymnent.

• Upload & manage files in their own private S3 space. Download, move, rename, copy, delete, and organize into folders, with a familiar filesystem-style UX.
• Define tables over their data. Register schemas in the Glue Data Catalog and create views directly from the app.
• Query with SQL through Amazon Athena. An in-app query workspace (Monaco editor, schema browser, multi-tab, multi-statement scripts) runs interactive, cross-database queries and saves results back to their own files.
• Share tables and workspaces. Push a table into another user's or a shared space's catalog, or collaborate in shared connections, all driven by serverless control planes rather than a server you have to run.

Every user is confined to their own data by AWS, not by application logic. A Cognito Identity Pool stamps a verified username principal tag server-side (ABAC), and a single shared IAM role scopes S3 prefixes, Glue databases/tables, and Athena results to ${aws:PrincipalTag/username} — so tenancy can't be spoofed by the client. Lake Formation registers the user-space bucket in hybrid mode to extend the exact same isolation model to the analytics catalog. Because isolation lives in the trust policy and IAM conditions, there's no application code path that can accidentally leak one tenant's data to another.

• React 18 + Vite + TypeScript
• TanStack Query
• AWS SDK v3
• Cognito / Amplify
• Athena + Glue + Lake Formation
• SQS + EventBridge Pipes + Step Functions + Lambda
• S3 + CloudFront
• OpenTofu

Log Forge Code

A Python library that turns every decorated function call into consistent, structured JSON logs. Key capabilities include:

• Tracing Decorator: @trace emits a span.start / span.end pair per call, with duration, status, and W3C-compatible trace/span IDs so nested calls form a queryable tree
• Structured Logging API: debug/info/warning/error/critical emitters and baggage that attach to the current span, so a whole call's logs flush together under one trace_id
• Non-Blocking Delivery: finished spans hand off to a background worker that batches by count or time, retries with backoff, and drains gracefully at exit — your code never waits on sink I/O
• 30+ Sinks: stdout, file, SQLite, and the stdlib logging bridge out of the box; SQS → ELK as the production path, plus Kafka, Redis, RabbitMQ, NATS, Pub/Sub, Event Hubs, Elasticsearch, Loki, Datadog, Splunk, Mongo, Postgres, ClickHouse and more
• Dependency Model: "Zero runtime dependencies in the core." Every sink needing a third-party client sits behind its own optional extra and is imported lazily, so installing the library pulls in nothing.
• Safety Posture: never captures arguments or return values (no accidental PII/secret leakage), and the decorator re-raises exceptions unchanged rather than swallowing them.

• Python 3.13
• Poetry

Spec Driven Development Template

A GitHub template repo that turns "vibe coding with Claude" into a repeatable, auditable method: specify → plan → build in phases → review in fresh context → land on green → record leanly.

Key capabilities include:

• Layered Docs: CLAUDE.md is the only always-loaded file; docs/architecture.md, docs/best-practices/, and per-spec files are pulled on demand so context stays lean as the project grows
• Spec Lifecycle: Numbered specs are the unit of work — an INDEX tracks status and build-order arcs, and a completion ritual writes a delivery doc and refreshes the component inventory
• Enforced Guardrails: scripts/spec-lint.sh fails CI on specs with open questions; the PR template and process docs enforce green format/lint/tests before a PR and a fresh-context review that isn't the session that wrote the code
• Two Delivery Paths: "Use this template" for new projects, or install the skill and say "Set this repo up for spec-driven development" to retrofit an existing one
• Design Stance: "Specs are fully resolved before building, and review happens in a fresh context." No open questions survive into a build, and the session that wrote the code never grades it.
• Two-Layer Architecture: A scaffold (CLAUDE.md, docs/, scripts/, .github/) that lives in every repo, plus a skill (.claude/skills/spec-driven/) holding the behavior rules Claude auto-discovers — the skill's copy is the source of truth, synced outward by script.

Find me on LinkedIn! The link is on my GitHub profile.

• AWS & infrastructure-as-code ☁️
• Developer tooling & observability 🔎
• Video Games 🎮
• Coffee ☕