STORY
> THE PERSON BEHIND THE PROJECTS
I'm a data engineer at IBM. Before that, 18 years in the Army, most of it as a full-time officer in the New York Army National Guard. Retired as a Major. Live in Western NY with my wife and our daughters.
I build things. Professionally, militarily, on weekends with my kids, late at night when I can't sleep. This page is about why, and what I've learned from it.
I was 27, leading a Route Clearance Platoon in Afghanistan. Job was to find IEDs before they killed anyone — us, the infantry units we supported, or the civilians on the road.
Most people in that job relied on experience and gut feel, which is fine until it isn't. I read every intelligence report I could find. I started tracking patterns — what materials were showing up where, which terrain, which villages, what time of day. I built the kind of spreadsheets that would embarrass me now. But they worked.
At one point, an infantry battalion and two other route clearance platoons were stuck at a combat outpost at the end of a supply route, rendered non-mission capable due to multiple IED strikes. Nobody could get them out. The route was saturated with IEDs and the standard equipment wasn't picking most of them up.
I'd noticed the pattern: the pressure plates in our area were almost all carbon rod. There's a detector that's great at finding carbon rod, but you have to be on foot to use it — which means you're the one who finds the bomb first. So I called up a Navy EOD team I'd built a relationship with and asked if they'd come work the mission with us. They said yes.
We worked it together — my platoon on the ground and in security, detectors going, EOD doing most of the actual finds, our guys doing most of the BIPs (blow-in-place). We pulled around 30 IEDs off that route. Walked two infantry battalions out of the COP — one American, one Italian — along with a few hundred logistics trucks and the two other route clearance platoons that had been stuck there.
That mission doesn't succeed without the EOD team. I want that on the record. What the data did was get us to the right tactic and the right partners. The people with the skills did the work.
I'm not telling this story because it's a good war story. I'm telling it because it's when I figured out that paying attention to data wasn't some optional professional skill. It was the difference between going home and not going home. That's been the operating principle ever since.
Every staff job I had after Afghanistan was data work, even though nobody called it that.
The really serious version of it started as a Battalion Operations Officer and kept going through Battalion XO and Brigade Operations Officer. Three jobs, about five years, same underlying problem: take a 400-to-5,000-person organization running on four or five enterprise systems that don't talk to each other (logistics, personnel, training, maintenance, readiness) and build something that actually tells the commander what's true right now.
One of my senior raters put it this way: “unparalleled ability to create programs that track every metric the BN has, and then find ways to improve the efficiency in which the BN operates.” That's the work. I iterated on it across those three positions — every time I moved up, I got to take what worked from the last job and push it further at the next echelon. By the time I was in Brigade Ops, I was integrating three separate enterprise Army systems (logistics, personnel, training) into Power BI dashboards the commander actually used to make decisions instead of waiting on staff estimates.
Plans Officer before that was the same pattern at smaller scale — rewriting the Battalion Planning SOP, Training Management SOP, and Knowledge Management SOP, and building a Class V calculator that projected ammunition requirements for the year. Brigade Logistics before that meant running SAP ERP for a 3,000-person, $200M+ property footprint. Company Commander meant saving $1M+ in shipment costs through honest analysis of what we actually needed to move.
When people hear “18 years in the Army, now a data engineer,” they usually assume there's a pivot story. There isn't. The job always involved taking a lot of inputs, finding what mattered, and turning it into something someone could act on. The difference is the output format.
I write down what I believe, because believing things privately doesn't help the next engineer. My standards document is 500 lines of opinions about how systems should be built. The short version:
> Documentation you wouldn't use yourself isn't documentation.
I've inherited too many projects with README files that are basically apologies. If your docs can't get me from zero to running in a reasonable amount of time, write better docs or ship less code.
> Constrain your dependencies.
Pin versions. Monitor CVEs. Own what you import. This is boring engineering and it's how you ship things that don't rot.
> Segment before you scale.
Nine VLANs on my home network, three schemas in every data warehouse I build, cleanly separated crates in every Rust project. The architecture is what you don't have to rewrite when things get complicated.
> Build it for the next person.
This is the whole thing. If I get hit by a bus tomorrow, can someone pick up what I was doing? If the answer is no, I haven't finished.
Stand Up Lockport
I built and maintain the platform for a non-partisan civic advocacy organization in my hometown — real website, real backend, real users. Rust/Axum API with Keycloak auth, 10-role RBAC, JWT validation on every request, tamper-proof audit database, rate limiting with device fingerprinting, GeoIP and Tor detection, threat model with 13 documented threats and 25 tracked risks. React frontend with 530 tests, full admin console, member dashboard, embedded Streamlit data explorer for our Niagara County data. 410 backend tests. Deployed in production and running. I do it entirely for free because I care about the community I live in, and because the engineering problem is real — this is the security boundary for an organization that needs to protect its members' data and its own integrity. Working on something with actual consequences makes me a better engineer at my day job.
Nexus
github →A multi-vendor AI chat platform I built and run on my home server. Claude, GPT, and Gemini in the same conversation, or in a group chat talking to each other — turn ordering configurable, @mentions with aliases, AI moderator for context-aware turn-taking. Nine independent Rust crates, 450+ backend tests, field-level AES-256-GCM encryption, three OWASP audits. It also has a full token counting and cost-tracking system with split input/output pricing per model — not because I'm billing anyone, but because I wanted to know what each conversation actually costs, and to be cost-aware if I let friends use it. I built it because I wanted one chat interface for all the models I use daily, and because building it right was more interesting than finding one that kinda worked. My kids use it too — they have favorite personas the way other kids have favorite YouTubers.
ResumeForge
github →A privacy-first resume generator I built because I needed one. Maintains a career data vault — experiences, bullets, projects, education — and assembles tailored resumes and cover letters per application, with optional AI-assisted rewriting and composition. Hexagonal architecture in Rust with dual storage backends (Postgres or flat JSON files, same interface, swap at startup). Typst for PDF rendering, React 19 frontend, 228 backend tests and 146 frontend tests. The thing that actually matters: your PII never leaves your machine. AI features strip all personally identifiable information before any outbound call, and you see the exact payload in a consent dialog before it's sent. Zero telemetry. I built it because I wanted resume tailoring that didn't require me to upload my life story to someone else's server.
Signal-Lens
github →An interactive Signal Protocol simulator I built to teach myself how end-to-end encryption actually works — X3DH key agreement and Double Ratchet, step by step, with real cryptographic operations. Every hex value on screen is the actual output of the actual operation, not a mock. Three scenarios so far: the happy path, MITM detection when a signature is forged, and the OPK-exhaustion fallback to 3-DH. Private keys never leave the browser; the simulated Signal Server provably can't decrypt anything. TypeScript crypto core (@noble libraries for X25519, Ed25519, HKDF-SHA-256, AES-256-GCM), FastAPI server, React visualization frontend. 253 tests across the three packages, crypto-agile design so I can add post-quantum primitives and the protocol-agnostic step engine so I can add MLS or other protocols later. I built it because reading the Signal specs once doesn't actually teach you anything — stepping through the protocol with working code does.
CivicLens
A civic transparency platform I'm building to expose local government data that's usually buried in PDFs and siloed systems. Two-tier Rust architecture: a Sentinel ecosystem of reusable open-source crates underneath, CivicLens application layer on top — designed so the Sentinel crates can be independently published the way Tokio or Serde publish theirs. PostgreSQL with three schemas, self-hosted Nominatim for geocoding, Traefik v3, Docker for local dev. Requirements document is ~2,582 lines and counting. The anchor project for my consultancy, Muninn Systems, but also the work I wanted to do independent of whether it makes any money.
- > Home network. Nine VLANs, zero-trust segmentation, themed after Rod Serling's Twilight Zone because naming your infrastructure should at least be a little fun. Has its own ETL pipeline and better documentation than most production systems I've seen.
- > Car buying, automated. Twice now I've scraped dealer inventory data, built an emailer to negotiate in parallel with a dozen dealers, and picked the best offer. Takes about an evening to set up and saves a lot of money. The second time I did it was because I forgot how much the first time saved me.
- > RetroPi arcade with the kids. Plugs into the TV, every system on it, the whole catalog of what I grew up playing. They play Mario Kart on it. I get to explain what a Raspberry Pi is to a seven-year-old, which is the best way I know to understand what you actually know.
- > Magic Mirror in the hallway. Shows the weather, the calendar, what's happening that day. My daughters check it before school. The satisfaction of having built something your kids use every day is a kind of engineering feedback loop that nothing at work compares to.
- > Custom Suno songs for the kids. They describe what they want — “a song about a unicorn who loves pizza, sung like a country song” — and we make it together. I've learned more about prompting LLMs from this than from any professional training.
I don't separate “work projects” from “life projects” very cleanly. I use the same engineering values on a Magic Mirror that I use on a production Rust codebase. It's just that the Magic Mirror has a harder audience.
The projects and playbook pages are more useful than any resume. If you want to know how I work, read those.