What I design and build with
The tools behind the work, and the reason each one is still here. Nothing on this list is a recommendation for anyone else — it is what happens to fit the way I work between a Figma file and a deployed front end.
Design
Figma does most of the work. The rest are here because a client or a project already lives in them.
- Figma
- Where essentially every project starts and ends. Components, variants and auto layout map closely enough to how a front end is actually built that the file stays useful after handoff instead of becoming a picture of the design.
- Framer
- For sites where the design and the published page should be the same artefact, and for motion that is easier to demonstrate than to describe in a spec.
- Webflow
- When a client needs to edit and publish content themselves afterwards without a developer in the loop. Chosen for who maintains the site, not for how it is built.
- Sketch
- Only when a project arrives in it. Plenty of long-running products still have their source of truth in a Sketch library, and converting one is rarely worth the disruption.
Front end
Enough to take a design all the way to production, and to know while designing which ideas are cheap and which are expensive.
- React
- The component model lines up with how a design system is structured, so the Figma component and the coded component stay the same unit rather than two parallel inventories.
- Next.js
- App Router and server components by default. Most of what I build is content-led and should ship as static HTML — this site included.
- Tailwind CSS
- Design tokens as the only way to write a value. It makes an off-system spacing or colour choice visible in review, which is a constraint worth more than the speed.
- TypeScript
- Mostly for the content layer. Typing the shape of a case study or a service means a missing field is a build error rather than a blank space someone notices in production.
- HTML & CSS
- Still the part that decides whether a build is any good. Semantics, focus order and contrast are design decisions that happen to be written in markup.
- PHP
- For projects on existing PHP stacks — usually a front end that has to slot into something already running rather than a greenfield build.
This site
Since a portfolio should be able to answer the question it invites.
- GSAP
- ScrollTrigger and SplitText for the heading reveals and scroll-driven sequences. Every motion primitive checks prefers-reduced-motion and degrades to a static, fully visible layout.
- Lenis
- Smooth scrolling, driven from the GSAP ticker rather than its own animation frame — on a separate loop, pinned and parallax elements lag the scroll position by a frame.
- three.js
- The particle background, kept to a single draw call. A portfolio that costs a phone its battery to look at has made the wrong trade.
Curious how these get used on a real project?
See all case studies