Skills & Technologies
I take pride in building clean and usable interfaces on the web for all screen sizes. I've worked on small projects to large scalable consumer and enterprise applications with millions of monthly users.
NextJS
App Router, server components, SSR, and static generation across six years of NextJS apps.
React
Expert in React components, hooks, state, and performance optimization.
Typescript
Strongly typed applications end to end, from shared domain models to API boundaries.
TailwindCSS
20+ years of CSS, SASS, and Less. Now build design systems on TailwindCSS.
Postgres
Schema design, versioned migrations, and query tuning through Prisma on Postgres.
React Native
Shipped an Expo / React Native app to both the App Store and Google Play.
Work ExperienceDownload Resume
In 1998, I started teaching myself to code by building a Miami Dolphins fan site using Angelfire in unformatted HTML <textarea /> blocks. I crashed that Windows '95 desktop a ton and had to rewrite a lot of code. After graduating from college with a Business degree when the market crashed in 2009, I went back to school to refine my web design skills. I landed an internship, and then full-time position at Blue Acorn and have worked there and at 7 other companies since.
Frontend Architecture
GitHub RepoMost of the frontend problems I have been given to fix turned out to be structural. These are the rules I build by now, and what each one bought me. The code for this site is public, and the single source rule and the commit history are both easy to check in it.
One source, every surface
One list should drive everything derived from it. On this site a single companies file feeds the work grid, the detail pages, the sitemap, and the static params, so adding a job is a one-line edit. At Eider the same rule puts about 290 paired web and native components and 3,700 localized strings behind one definition, which means a change cannot land on half the product.
No loaders, no layout shift
Speed is something I design for on day one, not a pass I make at the end. Eider paints its final layout on the first frame from a warm cache, writes apply immediately and roll back if the server disagrees, and balances push to every signed-in device over an event bus. Loading placeholders match the real layout, so nothing jumps when the data arrives.
The gate is the guardrail
I would rather a machine catch a mistake than a reviewer. Eider runs format, lint, typecheck, unit tests, and Postgres integration tests before a push can leave my machine, and work moves from development to staging to production behind nightly end-to-end runs. A failing gate is the signal to stop and fix the problem, never to route around it.
Reasoning belongs in history
Source files carry what the code does. The reasoning goes in the commit message and the code review, where it is dated, attributable, and cannot rot next to code that moved on without it. Anyone who wants the why has git blame, and anyone who wants the what has the code in front of them.
Portable core, thin adapters
Domain logic should not know which framework it is running under. Eider keeps its 144 API routes as thin adapters over portable functions, and those same functions serve the web app, the iOS and Android apps, and the realtime service. When a framework changes I rewrite an adapter instead of a product.
My Approach
Understand the Problem
I start with the workflow and the people stuck inside it, not the framework. At Sphere I designed an internal operations platform where teams like banking, crypto vaults, and liquidity management create their own org and build dashboard pages out of configurable components wired to their own APIs. That shape only became obvious once I understood the bottleneck was engineering time rather than missing features. Those teams now ship their own pages without me in the loop.
Structure for Change
Structure decides whether a project stays cheap to work in after the first month. I created and own @sphere/ui, the company design system built on shadcn and Tailwind, published through GitHub Packages with an automated release workflow and used by every production frontend we run. I also replaced Storybook with a custom Vite component explorer that renders each story inside the system's own layout components, so the documentation matches how the product really looks. One accessibility fix in the library now lands in every app at once.
Fast and Accessible
Performance and accessibility cost far less built in than bolted on, and most of the time they are the same work. I architected and led the Employee Service Catalog Builder at Salesforce, a web-component application with a custom drag-and-drop library and async data loading to meet page-time SLAs, built accessible from the ground up instead of audited later. Before that, on Employee Services Search, I used a custom state manager, debouncing, and stencils to make filtering feel instant across a large record set. Neither one needed a cleanup project afterward.
Ship, Then Keep Shipping
Getting to production is part of the engineering, not something that happens after it. I founded Loftery LLC and took Eider from an empty repository to public listings on the App Store and Google Play in under five months as the only engineer, clearing Apple App Review and Google Play's closed testing gate myself. It runs on a promotion pipeline with nightly end-to-end tests, 160 Playwright specs, 69 Maestro flows, and over-the-air updates. That is why I can still ship it weekly alongside a full-time job.
A cat's work is never done.



