Helloworld.

I'm Robert Henderson

Accomplished Senior

Full-StackEngineer

16 years of experience in big tech and startups

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.

Maestro
Serverless Functions
Datadog
Git
PHP
Enterprise Software
PostHog
CSS
Web Components
Cloudflare Workers
AWS
GraphQL
Java
Turborepo
UX
Redux
Salesforce
Neon
NextJS
Fintech
Plaid
Storybook
E-Commerce
TailwindCSS
TanStack Query
Web3
Responsive Web Design
SEO
Figma
Prisma
Open Graph
Stripe
Chakra UI
shadcn/ui
Typescript
CI/CD
Crypto
Design Systems
React
Durable Objects
Expo
ZSH
Firebase
HTML
SASS
Javascript
Postgres
Playwright
REST API
Vercel
Sentry
Accessibility
Monorepos
Recoil
React Native
Zustand
Supabase

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.

Learn More

Frontend Architecture

GitHub Repo

Most 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

Every project I start answers the same four questions before I write a component. Who is blocked and why, what the tenth change will cost, what the product needs to feel like, and how it gets to production every week. 16 years of shipping taught me they get answered either way, and answering them first is cheaper.

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.

Kitties

Let's get in touch

Please send information on your job opening or project. I'll respond promptly, thank you.