EngineeringLive2026
This Portfolio Site
A WebGL S/H cube with no 3D library, a no-backend CMS and a fully static build.
The site is the case study: hand-written WebGL, no database, fully static.
TL;DR
01 / What it is
This site: a hand-written WebGL cube and background, a CMS with no database, and a fully static build.
02 / Why it existed
A portfolio for Design Engineer roles should prove engineering judgement in how it is built, not just show design taste.
03 / What I achieved
The cube and background run at 60fps with no 3D library, content lives in the repo with no backend, and every page is static.
- 3D libraries used (custom animations)
- 0
- back-end databases (Keystatic, MDX in-repo)
- 0
Overview
This site is its own case study. The home page opens on my name, then hands over to one sentence: I make software where DESIGN meets ENGINEERING. Next to it is a cube carrying my initials, with a face for each discipline. Hover a word and its face lights up; hover a face and its word fills in. Click either and the page dives into that section. Behind every page runs one WebGL canvas of falling light, coloured per section and tied to scroll. There is no 3D library; the cube and the field are shaders I wrote. The CMS is Keystatic: each project is a file in the repo, the site is fully static, and there is no database.
Why it existed
I needed a portfolio for Design Engineer and creative-technologist roles, and I wanted the site itself to make the case. A heavy framework, a 3D library and a hosted CMS would have undermined it. So the constraints were set up front: no 3D library, no backend, fully static, with performance budgets.
My role
I designed and built it: the cube, the field, the dive, the case-study system and the CMS. I studied designers I admire (Eduard Bodak, Vlad Savruk, Lorenzo de Lijser, Pixels Studio) and defined the project schema that maps typed fields to case-study blocks.
Approach
Engineering
Engineering
The cube and the field are hand-written WebGL: no three.js, no react-three-fiber. Interactions are tested in a headless browser against real animation frames, and reduced motion is honoured with no intro and a near-instant crossfade. Scroll drives the field's clock, so scrolling down slows the light and scrolling up speeds it, with no layout work on the main thread.
The CMS is Keystatic. Each project is an MDX file in the repo; editing forms sit on top in development and never ship. The site stays fully static, with no database and no hosting fee. TinaCMS and Sanity were rejected because they hold content in their cloud; Payload and Strapi because they need a database.
A JavaScript budget is tracked per route, and the home page is the one that has to earn its weight.
Design
Design
The cube is the hero interaction, and the design challenge was making the hover feel natural in both directions: word to face, face to word. The dive had to feel like a transition, not a page load, so the page goes to black before the route changes and fades back in once the new page has painted. Every child page sits in a framed column with hatched gutters, so a case study reads like a document while the field keeps moving behind it.
The project schema maps typed fields to case-study blocks: metrics, decisions, callouts, media. The schema is the bridge between the editing forms and the rendered page.
Key decisions
Decision
Custom 3D vs three.js
- Why
- A Design Engineer portfolio that pulls in a 3D library for a cube is making the wrong trade-off. The cube is simple enough to build by hand, and building it by hand demonstrates the engineering judgement the portfolio is selling.
- What it cost
- More work; no library safety net.
Decision
Keystatic vs TinaCMS vs Sanity
- Why
- The site is static-only. TinaCMS and Sanity put content in their cloud. Keystatic keeps the content in the repo as MDX, gives editing forms on top, and needs no database. Optional GitHub mode adds remote editing via commits.
- What it cost
- No real-time collaboration; editing is commit-based.
Highlights
Outcome
- 3D libraries used
- 0
- back-end databases
- 0
The cube and the field run at 60fps on one canvas. Hover works in both directions, the dive feels like a transition rather than a page load, and the CMS works with no database. The site does what I say I do.
Learnings and what's next
A portfolio for engineering roles is an engineering artefact. The decisions, no 3D library, no backend, static only, budgets, are the evidence. The portfolio is not what you show, it is what you build.
Next: finish the remaining case studies and keep the site honest as the work changes.