Leading financing

• JobNimbus is the CRM and project-management platform that contractors — roofers, exteriors, home-services businesses — run their operations on. Financing is the product that lets those contractors offer their homeowner customers a way to pay for the work over time. I head it up on the Fintech team as the technical lead.
• The product spans a .NET service layer and a React application, and reaches thousands of contractor locations and tens of thousands of homeowners. My scope is the whole surface: the financing flow homeowners move through, the services behind it, and the infrastructure it all runs on.

Lender & payment integrations

• Financing means moving real money on behalf of contractors and their customers, which means integrating with outside financing providers and payment systems. This is the part of the product where correctness matters most — funding, settlement, and the state machine that tracks a financing agreement from application to payout.

AWS & Terraform

• The financing platform runs on AWS, with the infrastructure defined in Terraform. I own that layer alongside the application code — the same end-to-end ownership model I brought from building greenfield platforms at Rebuy, now applied to a fintech product operating at scale.

Payouts

• End-to-end financial feature I built at Rebuy.app. Spans the admin console, the merchant store UI, and the Stripe integration for actual money movement — plus a full financial safety layer: idempotency keys so retries don't double-pay, reconciliation against Stripe's own ledger to catch drift, exactly-once guarantees, pre-transfer guards that block a payout when invariants don't hold, and an append-only audit log of every action.
• Designed for cross-company use on the wider Rebuy platform.

Carl CLI

• Carl is the unified development CLI I authored for rebuy.app. It started as individual scripts I didn't want to lose and grew into the tool every engineer on the platform uses every day. `carl dev` orchestrates roughly 18 containers across 5 Docker Compose stacks — each service (bod-api, bod-shopify-connector, bod-accounts) has its own dedicated Postgres instance and migrator, plus workers, a Cloudflare Tunnel, a Caddy reverse proxy, a Stripe listener, a data seeder, and a test runner — plus three bare-metal Node dev servers and live kubectl contexts pointing at staging and prod.
• One command. Onboarding a new engineer is three commands: `git clone`, `carl init`, `carl dev`. Init handles Homebrew, direnv, 1Password CLI, version-manager detection, all five repo clones, and shell configuration. Beyond local dev, Carl owns vulnerability scanning, Helm-based GKE deploys, cluster access, integration and E2E test runners, and an OpenAPI validation pipeline. Ten command categories, ~25 scripts.

@rebuy/tributary

• Tributary is an OpenAPI/GraphQL → TypeScript code generator I authored. It takes a spec and produces the entire consumer-side call stack — typed fetchers, Zod schemas, React Query hooks, and a Next.js-aware proxy that lets the same typed function run on either side of the server/client boundary without manual `use server`/`use client` plumbing.
• One change to the API, one command, and three separate client repos receive a fully-typed, runtime-validated update. It's the reason our four services don't drift. Private npm package on GCP Artifact Registry.

Shopify-embeddable widget system

• Rebuy.app shipped the same customer checkout in two places: first-party on Rebuy.app, and embedded inside merchants' own Shopify storefronts. I authored the embeddable side — a React/Vite app that installs into merchant themes via Liquid and interacts with the API as if it were hosted on Rebuy's own domain.
• Same-origin proxy eliminates CORS; Shopify passthrough auth flows through bod-shopify-connector. Updates ship as semver-versioned artifacts to a Google Cloud Storage bucket — merchants pin the version they want in their theme config and update on their own schedule.

@rebuy/ice-age — schema visualizer

• I inherited ice-age, Rebuy's Kysely-based migration framework, and became a maintainer. I've added transaction guards, isolation-level support, Pino logging, and improved error handling.
• The piece I'm most proud of: an interactive schema visualizer authored end to end — a Preact client bundled with esbuild, invoked via `ice-age visualize`. It renders a pan/zoom diagram of the full DB schema with domain grouping, FK relationship mapping, drift detection, and multi-config federation so schemas from multiple services appear as tabs in one tool.

SHAFT — Self Help App FinTech

• SHAFT is an internal Next.js tool I authored at Pluralsight. It integrates Kafka streams, RabbitMQ streams, and Salesforce to surface provisioning discrepancies in real time — data mismatches between billing systems and customer records that would otherwise require an engineer to investigate and manually correct.
• SHAFT put that capability in the hands of ~20 non-technical stakeholders with specific financial permissions. I was the primary author and handed it to the team to iterate on.

A Cloud Guru migration

• Contributed to the A Cloud Guru (ACG) migration following Pluralsight's acquisition — capturing and moving thousands of customers from ACG's systems into Pluralsight's internal platform. This included payment method migration, bulk account creation (10k+ accounts), account settings, and billing data migration.

Billing system migrations

• Contributed to two major billing migrations: all Chargebee customers to Stripe + Salesforce, and all Zuora customers to Stripe. Batch migrations of customer billing records, payment methods, and subscription data at scale.

Entitlements API

• The Entitlements API was a NestJS service that sat as a middleware layer in the Salesforce → MuleSoft → Entitlements → platform chain for B2B provisioning. At peak it handled ~$9M/month in provisioning requests.

React on top of industrial infrastructure

• SKM Engineering is an industrial engineering consultancy. I built the software layer on top of the SCADA systems their engineers designed — working directly with multiple clients to understand what operators needed and translating that into working interfaces.
• The stack was polyglot by necessity: Ignition SCADA runs on the JVM, scripting is Python, and the frontend is HTML/CSS/JS with React components injected into the environment. Nothing was built for modern web tooling. Every development workflow I wanted required building it from scratch. I also built a compiled Kotlin SFTP plugin — installed directly into client Ignition systems — that became part of the standard deployment.

Logan Water Treatment Plant

• The most involved project was the Logan, Utah water treatment plant — a full SCADA front-end serving as the primary operator interface for the facility. Roughly 1,000 screens backed by tens of thousands of individual data points. Operators used it for everything: live sensor readouts, plant-wide alerting, UI animations that reflected actual physical state, and controls for the automation flows managing the treatment process itself.
• At that scale, the display layer has real operational weight. The right data needs to be visible at a glance, alerts need to surface without noise, and controls need to be trustworthy. I implemented across the full stack — from individual sensor readout panels up through the automation control interfaces. Systems went live and were handed off to the city's own engineering teams for ongoing operations.

Building tooling for an environment that had none

• Ignition wasn't designed for component-based development. Getting React components into the stack required building the injection pipeline myself. Getting any kind of consistent build and deploy workflow required learning and extending the Ignition plugin system — a process that ended with me shipping a Kotlin plugin with its own build toolchain.
• Each client integration was a fresh challenge — different hardware, different PLC configurations, different operational requirements. The job was as much infrastructure and tooling work as it was UI development.