I build Next.js apps that move with intent - fast, accessible, and full of considered detail. App Router, Server Components, and the rest of the modern React stack are my default base. I work across the seam between design and engineering - building tools, design systems, and the occasional shader.
Three or four problems a year, gone deep. The shape of the work matters more than the headcount.
I’m a generalist by curiosity, a specialist by focus. The list below is what I’ve actually shipped - production, in front of users - not just dabbled with on a weekend.
My default base - Next.js with the App Router, Server Components, and a typed data layer. Architectures that scale from a marketing site to a logged-in product, tuned for Core Web Vitals.
Tokens, primitives, docs. I treat a system like an API: stable contracts, sensible defaults, and the freedom to break out when the product needs it.
Physics-based transitions, scroll choreography, micro-interactions. Motion that signals state instead of decorating it.
Shaders, generative visuals, custom canvas. Comfortable shipping a hero scene that runs at 60fps on a five-year-old laptop.
CLIs, devtools panels, internal IDE plugins. The kind of tools that make the rest of engineering 10% faster - every day.
Rapid clickable proofs, often within a day. I treat prototypes as the cheapest way to find out what's actually true about an idea.
Each one of these started as someone saying “I don’t think this is possible in the browser.” They were wrong, mostly. A few are open-source; a few are quietly running inside larger products you’ve used.
A browser-native motion editor for product teams. Built a custom timeline, ECS-based scene graph, and a rendering pipeline that hits 60fps on 4K canvases.
Open-source component primitives used across 14 products. 240+ components, full a11y compliance, and a docs site that loads in under 200ms.
The page above is the highlight reel. The full archive includes process notes, architecture diagrams, and the trade-offs behind every decision.
See all experiencesI started as a print designer in Hanoi, switched to product design when I moved to New York, and accidentally became an engineer because I kept opening the inspector to fix things myself. None of that is on the résumé, but it’s why I work the way I do.
The most useful thing I bring to a team is taste calibrated by what’s actually shippable. I can tell you in the room why a shadow is making the page feel cheap, and I can also tell you what the perf cost will be to fix it.
When I’m not in a tab, I’m running long, reading slow, and trying to convince anyone who’ll listen that cartography is the most interesting design problem of the next ten years.
“HAL ships at the velocity of a prototyper but with the rigor of a staff engineer. That combo is rare.”
“I've worked with a lot of front-end folks. He's the only one who has consistently made our product feel inevitable.”
“He took our motion language from 'we should do something here' to a system. Designers and engineers both leveled up.”
“Quietly the best technical hire we've made in three years. He raised the bar without ever raising his voice.”
Most projects start with the same five questions. Here are honest answers. If yours isn’t here, the email below works.
I'm full-time at Loom. I take on one outside project per quarter - usually 2–6 weeks, scoped tight. If yours is a fit, the worst-case is a kind no within 48 hours.
Both. I'm comfortable carrying design-engineering through to production solo, and I'm equally comfortable embedding inside a design team and amplifying what's already there.
Crypto, gambling, anything ad-tech adjacent. Greenfield projects without a clear thesis. Roles where the only ask is 'pixel-push our Figma.'
Yes - for hiring conversations I share a private repo with three real PRs and a short Loom of me reasoning through one of them. Email me and I'll send the link.
Independent front-end developer building tools, systems, and the web’s quieter corners. Available for select work.