Case studies
Case studies that reflect how I work
These case studies were selected because they show the kind of engineering I do most often: building shared systems, clarifying product complexity, and creating tooling that helps teams move faster.
Internal developer tooling
KBRA AI Tooling CLI
An internal CLI that turned shared AI workflow assets from informal file-sharing into a governed, low-friction distribution model.
Context
As KBRA pushed for broader participation in internal AI tooling, I built and shipped a CLI in February 2026 that packaged and distributed shared skills and related workflow assets across technology.
Problem
Useful skills and workflow customizations existed, but the real problem was governed distribution rather than storage. Teams relied on ad hoc sharing and copied files, which made discovery hard and updates unreliable in real developer environments.
Approach / key decisions
- Modeled the workflow as a package-manager-style experience instead of a shared repository plus docs, because the missing layer was installation and discovery in local environments.
- Optimized v1 for zero-setup adoption via `npx` and editor-agnostic operation, ensuring engineers did not need to standardize on one editor or perform heavy setup before trying it.
- Used a progressive-disclosure model: guided prompts for newcomers to ensure first-run success, while exposing flags for power users who wanted to skip prompts.
- Published installable assets with the npm package source and ran them through working-group review before release, establishing a governed contribution model.
- Added explicit `update` and `remove` flows later as the product matured, after initially prioritizing broad availability and simple install behavior.
Outcome
- Standardized distribution for shared skills and related AI workflow assets instead of relying on informal person-to-person sharing.
- Created a governed contribution path that grew from a single maintainer into regular contributions from multiple engineers across the organization.
- Supported a broader push toward deeper AI-tooling use by making shared assets easier to discover, install, and reuse.
Scope and evidence
- Released to KBRA Technology in February 2026
- Regular contributions from 5 engineers across the org
- Goal: every technologist contributes something by end of 2026
Stack / scope notes
Platform architecture and delivery
KBRA Financial Intelligence
Platform ownership across KFI's application architecture, delivery model, and search/data systems that made a complex product easier to build and ship.
Context
KFI is a financial-intelligence platform used for benchmarking and counterparty-risk analysis across more than 10,000 U.S. banks and credit unions, with scope spanning web, APIs, search, and supporting delivery systems.
Problem
The product needed to keep shipping while an immature application and delivery platform was creating release friction. An aging Angular frontend (with a custom React adapter) and a legacy PHP GraphQL implementation increased the cost of building new product capabilities.
Approach / key decisions
- Modernized the application foundation from aging Angular to Next.js, while helping migrate the GraphQL layer from legacy PHP to Apollo.
- Pushed the team from code freezes and long-running branches toward trunk-based development, feature flags, and a delivery model where every push to `main` builds through UAT.
- Built key parts of the search and data platform for company and bank screening, including index definitions, custom tokenizers, and ingestion pipelines for a 5+ node Elasticsearch cluster.
- Designed screening patterns and modules that were later reused to accelerate the M&A screener, turning initial screening work into a reusable platform capability.
Outcome
- Reduced release time from ~8 hours of coordinated effort to about five minutes by a single developer.
- Lowered the cost of building new capabilities by improving the application and API foundation underneath the product.
- Enabled richer product behavior, including reusable screening infrastructure and newer capabilities like portfolio report building across multiple data sources.
Scope and evidence
- 10,000+ banks and credit unions in product scope
- 40M+ records loaded during off-hours
- ~8 hours to ~5 minutes release-time reduction
Stack / scope notes
Shared UI systems
Design System Infrastructure
A token-first design system that treated shared UI decisions as delivery infrastructure rather than visual polish.
Context
Across KBRA products, and even within KFI itself, I worked on shared tokens, reusable primitives, and the operating model needed to turn repeated UI decisions into durable infrastructure.
Problem
Frontend teams were repeatedly solving the same interface problems in slightly different ways across ~20 distinct stack combinations. Developers often copied values directly from Figma, which increased implementation cost and made maintenance harder to sustain.
Approach / key decisions
- Led the engineering side of a token-first shared system, using a 4-layered model (base, concept, element, theme) to translate raw definitions into semantic UI applications.
- Used tokens as the adoption wedge because they were lower-friction and framework-agnostic, then layered a library of 26+ reusable components on top to standardize complex behavior.
- Established a volunteer-driven operating model, scheduling weekly sessions with design and engineering to codify repeated decisions and produce shared artifacts.
- Treated the system as delivery infrastructure, ensuring the Style Dictionary pipeline could emit multiple targets including CSS, JavaScript, and Tailwind CSS.
Outcome
- Roughly halved average frontend complexity across the organization by reducing one-off design decisions and bespoke implementation work.
- Created a more reusable, accessible base for frontend delivery across 10 teams without forcing immediate convergence on one component library.
- Improved design-engineering collaboration by replacing ad hoc Figma-to-code translation with codified shared decisions.
Scope and evidence
- 10 teams onboarded and ~30 projects adopted at the token level
- 220+ releases shipped over 3 years with 2 major version bumps
- 26 top-level components (38 including sub-components)
Stack / scope notes
Sole frontend ownership
Klezma MVP
End-to-end Next.js architecture and "Grandma-proof" onboarding for a Web3 creator platform.
Context
Klezma was a Web3 music launchpad that required a high-polish, low-friction investment experience for non-crypto native fans on the Polygon blockchain.
Problem
Early Web3 onboarding was notoriously difficult for mainstream users. The product needed to bridge the gap between complex blockchain mechanics and the expectations of a premium music discovery platform.
Approach / key decisions
- Built a custom design system and component library from scratch during a hackathon to ensure an exceptionally polished first-run experience.
- Engineered a hybrid settlement model using Auth0 for social login and a custom managed relayer to abstract gas fees and wallet management.
- Implemented a 'Virtual Ownership' state where the frontend reflected asset ownership immediately via Stripe/DB state while on-chain settlement happened in the background.
- Developed a custom in-browser video and music editor to enable social-reward features, later pivoting based on platform-legal constraints.
Outcome
- Winner of NFTHack 2022, specifically recognized for frontend polish and product execution.
- Successfully launched the MVP with a 'Grandma-proof' checkout flow that required zero crypto knowledge from the end-user.
- Established a scalable frontend architecture that supported both traditional Web2 flows and complex Web3 state management.
Scope and evidence
- Sole frontend engineer from concept through MVP launch
- NFTHack 2022 Winner
- Zero crypto-knowledge required for fan investments