The platform my team built from scratch, which designs and simulates a lunar lander for ~300 systems engineers, plus the Claude agents that answer questions straight from its source of truth.
The hard part
Engineers were working from scattered spreadsheet copies with no source of truth, and the copies were causing design errors. The replacement holds data classified as CUI, so every row needs access control, every change needs a permanent history, and NASA's penetration testers need a sandbox of their own, all without that bookkeeping becoming the bottleneck.
The decision
One governed source of truth in AWS GovCloud, approved by Security and Export Control to manage CUI, on an event-driven architecture on Kubernetes so interdependent simulation jobs fan out instead of queueing behind each other. End-to-end simulation time fell by 40%.
Python
TypeScript
React
AWS GovCloud
Terraform
Kubernetes
DynamoDB
PostgreSQL
SQS/SNS
Datadog
Bedrock
MCP
~300 systems engineers · approved for CUI in GovCloud · 40% faster simulations · 2 production agents at 100% factual accuracy
Lead engineer, five-person team, 2024–present
AmigoWeGo
Status: RELEASED
Group trip planning that survives contact with a group chat.
The hard part
Several people edit one shared plan from a phone and a browser at the same time. Four questions have to stay answerable and consistent across both clients: what is the plan, who is where, what was decided, and who owes what.
The decision
Contract first. A single OpenAPI document generates both clients, so the Rust backend and the SwiftUI app cannot drift apart — the compiler catches a mismatch that would otherwise surface as a bug on somebody's holiday.
When a group uses this app, they should always know:
What's the plan? - Today's activities and what's coming next
Who's where? - Where everyone is during the trip
What's decided? - Clear record of group decisions
Who owes what? - Expenses tracked and settled without awkward chasing
Product overview
Home Claw
Status: RUNNING
A family assistant that answers from any room and never leaves the house.
The hard part
A useful home assistant needs the family's schedules, preferences and medical information. Every product that does this well sends that data to someone else's servers.
The decision
Privacy as an architectural constraint rather than a feature. The Mac Mini M4 Pro is the only machine that runs inference, and it and both Raspberry Pi voice stations are running; the Jetson arm bridge is planned, not built. No cloud dependency, no subscription, nothing crossing the LAN boundary — which rules out the easy answer and makes model size a hardware problem.
MLX
FastAPI
pgvector
Raspberry Pi
Jetson Orin Nano
Scroll the diagram sideways →
The LAN boundary is the design: every component that touches family data is meant to sit inside it.
Architecture — dashed boxes are planned
The Observer
Status: TRIALS
A camera that keeps only the good photographs of the dogs.
The hard part
An all-day camera produces thousands of frames and almost no keepers. Detecting a dog is the easy half; deciding which frames are worth keeping is the actual product, and it is a judgement call.
The decision
A phased proof of concept where each phase has to pass a gate before the next one earns any time: frame in, dog detection, keeper scoring, portrait crop out. The ladder stops early if a rung fails, instead of arriving at a finished pipeline that produces nothing worth looking at.
YOLO
OpenCV
Pi Camera 3
Python
Cards The Observer has made from real keepers — Pokémon-style for Luna, baseball-style for Max.
This repo is the proof-of-concept ladder; each phase has a pass/fail gate before the next one earns any time.
Project plan
Quadruped
Status: PHASE 0
Four legs from nothing: hardware, control software, CAD, simulation, and eventually reinforcement learning.
The hard part
A legged robot fails where mechanical design, power delivery and control meet, and each of those can quietly destroy the others — a servo that browns out the controller looks exactly like a bug in the gait.
The decision
Classic control first and reinforcement learning later, across eight phases that each end in an observable exit test. The power maths and the battery safety rules were written down before anything was energised.
Fusion 360
Jetson
MuJoCo
Raspberry Pi
PCA9685
…the robot stands in a neutral pose holding its own weight for several minutes without servo overheating or brownout; full-system current stays within BEC/battery limits.
Project plan, Phase 3 exit test
The Sentry
Status: SEASONAL
An animatronic that tracks people up the driveway every October.
The hard part
Computer vision is soft real-time and servo control is hard real-time. Run both on one processor and the vision work steals the timing the servos need, so the head moves in visible jerks.
The decision
Split the two across processors. A Raspberry Pi is the brain and does the image processing; a Pico or Nano is the muscle and does nothing but precise servo and LED timing. The interface between them is deliberately narrow: the Pi sends simple commands over a serial link, and the Pico executes them.
OpenCV
Raspberry Pi
Pi Pico
Arduino Nano
Adafruit PWM driver
Scroll the diagram sideways →
A Raspberry Pi will act as the "brain," handling all the complex image processing for object tracking. An Arduino Nano or Raspberry Pi Pico will act as the "muscle," receiving simple commands from the Pi and executing the precise, real-time control of the servos and LEDs.
Project plan, §1
How I work
Phases with exit tests
Every build gets a plan where each phase ends in a concrete, observable result. Nothing advances on the strength of feeling nearly done.
Constraints before code
The power budget before a battery is connected. The access and export rules before controlled data touches a server.
Honest status
Unfinished work is labelled unfinished, in the repository and on this page. A project that says Phase 0 is worth more than five that claim to be done.
Experience
Blue Origin
Lunar Data, AI & Applications
2024 – PresentNow
Lead Engineer
Built the platform from scratch after engineers said scattered Excel copies were causing design errors. It turns design parameters derived from requirements into technical performance measures for ~300 systems engineers across all lunar subsystems.
Lead a 5-person team owning product direction, architecture, and delivery, and turn requirements from Systems Engineering, Program Leadership, and Mission Planning into the roadmap.
Worked with Security and Export Control to get the system approved to manage CUI in AWS GovCloud under ITAR/EAR and NIST 800-171: row-level access control, full change history, and encryption across every event's lifecycle.
Defined penetration-testing infrastructure with NASA counterparts, giving NASA pentesters a sandboxed deployment on AWS WorkSpaces, and work with Blue Origin's NASA representative, who presents data from the system to NASA.
Put two agents into production on Claude (currently Opus 5.5) via AWS Bedrock. They answer design questions through MCP and purpose-built APIs, not model memory.
Held both agents to 100% factual accuracy with automated tests that check answers against known facts from the source of truth.
Led the team's adoption of agentic workflows and shared repository context, cutting the human effort spent debugging failed simulation and analysis jobs.
Designed the CI/CD and job pipeline (Python, Kubernetes, Terraform, Datadog) for interdependent simulation jobs, cutting end-to-end simulation time by 40%.
Promoted from Software Engineer III to Lead Engineer on the same program.
AWS GovCloud
CUI / ITAR
Claude on Bedrock
MCP
LLM Evaluation
Python
TypeScript
React
Terraform
Kubernetes
AWS
DynamoDB
PostgreSQL
SQS/SNS
Datadog
Data Visualization
Blue Origin
Platform Engineering
2022 – 2024
Software Engineer II/III
Built and operated core platform services used by all 10,000+ Blue Origin employees, including the user, file, and notification services, in Java and Python at 99.999% availability.
Built manufacturing services that track parts and every change to them, with event-driven search (AWS SQS/SNS, OpenSearch) and role-based access control across REST and GraphQL APIs.
Automated infrastructure with Terraform and Kubernetes and added Datadog monitoring across the services.
Java
Python
AWS
SQS/SNS
OpenSearch
Terraform
Kubernetes
Datadog
GraphQL
REST
Alteryx
Data Science R&D
2019 – 2022
Sr. Full Stack Software Engineer
Architected and deployed ETL orchestration pipelines (Apache Airflow/Prefect) to manage terabytes of data flows for model training and serving, supporting multiple internal ML applications.
Engineered scalable backend services using Rust and Python for data-intensive applications, including the development of full-stack applications with interactive D3.js/SVG visualizations.
Rust
Python
Apache Airflow
Prefect
D3.js
SVG
ETL
ML Pipelines
Giskard Labs LLC
Independent products
2026 – Present
Founder & Engineer
Took AmigoWeGo, a group trip-planner, from zero to the App Store as a solo engineer (about 20 users): Rust and PostGIS backend, React and SwiftUI clients generated from one OpenAPI contract.
Built sqllm, natural-language questions over SQL tables, with a 40-question evaluation comparing local models against Claude on a pass bar set before any run.
Rust
PostGIS
React
SwiftUI
OpenAPI
LLM Evaluation
Education
MS Computer Science — University of Colorado (In Progress)
Full Stack Immersive — Galvanize
BS Kinesiology/Physiology — University of Louisville
