Things I have built, in pictures.
Products I ship through BEhive Tech, the architecture behind them, and screens from earlier roles. Scroll sideways in a set to see more, and select any image to open it full size.
Work gallery
Open source
Component registry
The registry behind every BEhive Tech product: one npm package per component, docs and props tables generated from the source, live editable examples and a version history per component. It is a static site with no database.
AI-native delivery
AI agent team pipeline
How a feature moves from a GitHub issue to a release with my agent team. Agents do the steps, and a person approves the design, the contract and the merge. High-risk pull requests get a security review and a second model, and a QA agent checks staging before anything reaches production.
Architecture
Micro-frontends on a shared design system
The shape I use when several products share one frontend platform: product modules that deploy on their own schedule, on top of shared, versioned foundations. The component library is hand-built from tokens up and published through a registry, so one fix lands in one place and every product picks it up.
Experience at Crisis24
Cross-platform desktop alerting client
An Electron tray app I built for Crisis24 and CodeRED customers, replacing an outdated legacy client. It holds a persistent WebSocket connection, surfaces alerts in the foreground and sends the recipient's response back on the same connection.
See more...Show less
I chose an MVC structure for the app. The models are stores in the main process that hold the app's state: user preferences, notifications, window states and the socket server. Controllers take each message from the bus, then update a store or carry out the action on the main side. The view is the React renderer, which shows whatever data it is passed.
The two sides talk through a custom messaging bus I built, used in place of direct IPC calls, so new features reuse one shared channel instead of repeating the same code.
Settings live in config files in the user's system folders, and edits show up in the running app, in most cases without a restart. IT admins can roll the app out company-wide with their own configs using the device-management tools they already have, such as Jamf on Mac and Microsoft Intune or Group Policy on Windows, then change those configs on the fly.
I also built most of its CI/CD and installer packaging, shipping signed, certified Windows and macOS releases with DevOps.
Experience at PipelineRx
Clinical pharmacy web app
As principal engineer I led the frontend architecture for a React single-page app that replaced a legacy Java application, on a GraphQL API with role-based permissions. It showed far more information per screen, used PubNub as a messaging bus to push real-time updates to every open screen, and added in-app video chat, on a platform used by 500+ hospitals in a HIPAA-regulated environment.
The screens show demo data, not patient records.
Experience at Southwest Airlines
southwest.com
I engineered features for southwest.com at 12M+ daily page views, and helped convert the site from Java-based pages to React, an early enterprise React adoption. Page performance was monitored through the conversion so no change regressed load times against the legacy pages.
BEhive Tech product
The BEhive guest site
A production CMS-style site for an art-filled rental house, on the Next.js 16 App Router. Guests get a house guide that the QR cards around the house open, a gallery, and art they can buy with a checkout that holds the piece while they pay. It was built by my AI agent team from an epic of about 30 issues, with Clerk auth, per-environment database branches, Vercel staging and QA sign-off before production.
See more...Show less
Checkout connects to the payment processor through a single adapter, so the processor can be swapped without touching the rest of the checkout. The processor reports back through a signed webhook, and every event is recorded in a ledger so it is applied exactly once, even if it arrives twice. Test environments use a stand-in provider that production refuses, so no test payment can ever be mistaken for a real one.
Behind The BEhive
A release flow that protects the database
The BEhive runs on Neon Postgres with Prisma, and no schema change reaches production unrehearsed. Pull request tests run on throwaway databases, the dev environment has its own Neon branch, and each release resets staging to a fresh copy of production and runs the migrations there first. Migrations always run before the deploy. Production moves only when I merge, and that merge is blocked until the release tests and the QA agent report are green.
Side project
Farkle score keeper
A fun one. I built this so we could keep score on game night without pen and paper. It is made for a phone: the phone keyboard took up too much of the screen, so I built a number keypad into the page instead. I kept it simple and skipped the database. Players and scores are saved in the browser with localStorage, so if the connection drops or the page reloads, the game comes back exactly where it was.
Need something like this built?
This is the kind of work I take on for teams: product builds, shared component libraries and the architecture underneath them. A short call is the quickest way to find out what that would look like for you.