How this site was made.

The team and the tools

One designer, one AI partner, many iterations.

Nicolae directs it: the art direction, the motion and every call on what to make, how it feels and when it’s done. Claude does the hands-on build: writing the code, testing in a real browser and reporting back with screenshots and measurements. Imagery no camera could capture came from Figma AI and Google Gemini, then cut, graded and composited to his direction.

• Claude, in Cowork

  Anthropic’s AI as engineering partner: writes the code, runs the build, tests in a real browser, commits and writes the docs.

• Figma AI

  Still imagery that couldn’t be photographed: the seven synthetic portraits on the deepfakes case study (no real people), the embryo’s growth stages in the home hero, the butterfly in the Ellie Cashman film and a set of illustrated scenes.

• Google Gemini

  Source video behind several heroes (CVS Health, CareAcademy, MIT, Georgetown), then trimmed, graded and composited.

• Cloudflare

  Hosting on a global network: pages served from the data center nearest each visitor, HTTPS and security headers on every response.

• Astro 5

  Static pages, server-rendered, enhanced after paint.

• GSAP + ScrollTrigger

  Reveals and scroll-timed motion, in the site’s own motion package.

• WebGL, canvas, SVG

  The live backgrounds: shaders, particle fields, wireframes.

• Python: OpenCV, NumPy, SciPy, MediaPipe

  Film compositing, face alignment and morphs, vignettes, halftones.

• ffmpeg

  Video encodes (AV1, HEVC, H.264, VP9), posters and the logo-film storyboard frames.

• Playwright + axe-core

  Real-browser testing at desktop and phone widths, and accessibility scans.

• Git + GitHub

  Every change committed, with what changed and why.

The workflow

Ask, build, measure, look, commit.

Every change, small or large, went through the same loop, often several times an hour. It works for any designer and AI pairing: the person keeps the judgment, the AI does the work, and nothing counts as done until it has been rendered and checked.

1. 01

   Ask

   A request in plain words, usually a cropped screenshot with the problem described, sometimes naming the CSS at fault (“line-height”). One change, or a short list.

2. 02

   Clarify

   If it could mean two things, Claude asks in one line, or makes the call and says which call it made. Never a silent guess.

3. 03

   Edit where the files live

   Changes go straight into the project on the designer’s computer, never into a copy that drifts.

4. 04

   Build

   A full production build after every change. A warning counts as a failure.

5. 05

   Test the whole page

   In a real browser from phone to laptop widths, once with reduced motion, then by Nicolae on a 24-inch monitor and a MacBook. The whole page, not just the change: nothing overflowing, no sideways scroll.

6. 06

   Measure, then look

   Sizes, contrast and timing are measured, and both sides of a comparison are reported. Then the screenshot is actually read.

7. 07

   Report

   What changed, the numbers and anything that went wrong, said plainly.

8. 08

   Commit and document

   A commit with what and why; the docs, the hidden-content log and the list of traps updated in the same pass.

Iteration

Most things took more than one try.

Version counts are kept on purpose: superseded versions are archived, not deleted, and the storyboards above show only the final ones.

• 32 versions

  CareAcademy logo film

• 11 versions

  The Georgetown film

• 3 passes

  CareAcademy: her smile, in dots

• 18 versions

  Ellie Cashman film

• 8 rounds

  The NASA wing

• 2 concepts

  The yarn bow

• 1 cinematic rule

  Timing and delivery

Film and animation

Crystal clear took a process.

The first films looked fine in an editor and fell apart on the page: banding in dark gradients, hard edges, blocks in Safari, stale cuts in the cache. This is the pipeline every film and background goes through now.

1. 01

   Start from the source

   Footage from Gemini or the client, stills from Figma AI. Every cut is rendered from the source frames, never from an earlier encode, so quality never drops version to version.

2. 02

   Composite in code

   Python grades, masks and composites each frame: vignettes, halftones, face alignment and morphs. Nothing is done by hand twice.

3. 03

   Feather into the page

   Edges fade into the page’s own black over a long, soft falloff, with a trace of noise so the fade has no steps. The film ends where the page begins, with no visible frame.

4. 04

   Storyboard it

   Frames pulled at fixed moments and judged side by side, every version numbered. Reviewing a strip is faster and more honest than scrubbing a video.

5. 05

   Encode four ways

   10-bit AV1 and HEVC first, so dark gradients stay smooth, then H.264 and VP9 for every other browser. Each browser plays the best one it can.

6. 06

   Check before it ships

   Scripts confirm the length, that the edges match the page and that every format loads on every page, in Safari’s engine as well as Chrome’s.

7. 07

   Stamp and ship

   Each file’s address carries a fingerprint of its contents, so a re-cut film is never served stale from a visitor’s cache.

Lessons learned

• Banding is an 8-bit problem

  Dark gradients in ordinary 8-bit video break into visible steps. 10-bit encodes and a little dither fixed what no amount of re-grading could.

• Safari draws fades differently

  Chrome smooths gradients over near-black; Safari doesn’t, in CSS or in canvas, and shows vertical blocks where Chrome is smooth. Those fades are now computed pixel by pixel with a little noise (dithered) and checked in Safari’s engine.

• Test where the problem shows

  A check in the wrong browser passes every time. Visual bugs are now reproduced first, then fixed, then checked in the browser that showed them.

• Edges belong to the film

  A mask added on the page reads as a hole; an oval vignette reads as a lens. Feathering inside the film itself lets it dissolve into the page.

• Endings need restraint

  A hold that feels right in an editor drags on a page. Several films were cut by half a second to a full second, and every ending now hands off: footage into dots, a film into its still.

• A veil can band on its own

  Even a fade in the page’s own color shows steps over an empty area, and masks over a dark print band in rings. Where a drawing has empty space, it now fades itself; where a mask fades an image, the mask carries a little noise.

• A new cut needs a new address

  Browsers keep a film for up to a year. When a film was re-cut but kept its old file name, anyone who had seen it kept getting the old version. Now each film’s address carries a short fingerprint of the file itself, so a new cut always loads fresh.

Core Web Vitals

Fast is measured, not felt.

Core Web Vitals are how Google measures what visitors feel: how soon the main content shows (Largest Contentful Paint, good under 2.5s), how quickly a tap answers (Interaction to Next Paint, under 200ms) and whether the page holds still (Cumulative Layout Shift, under 0.1). Every page was timed in Chrome on a Mac, on the live site, and in Lighthouse on a throttled phone, then fixed where it was slow. Each fix got a check that fails if it’s undone.

• 0.7s

  Slowest case study to its largest paint (LCP), desktop, on the live site

• 0

  Layout shift (CLS) on every page

• 56ms

  Slowest response to a click (INP)

• 30ms

  Time to first byte, from Cloudflare’s edge once a page is cached there

• 4.5×

  Shorter longest task on the NASA explorer, on a throttled phone

How pages are kept fast

• Content first

  Headlines and text are in the page itself and paint with it, never waiting on a script to appear.

• Media sized for the screen

  Images and films in modern formats, a lighter cut for phones and nothing below the fold loaded before it’s needed.

• Nothing jumps

  Space is held for every image, film and font, so the page holds still as it loads.

• Taps answer at once

  Heavy work is split into small pieces between frames, so the page responds while it’s still loading.

• Measured, not assumed

  Lighthouse on a throttled phone, Chrome’s own timings on real devices and before-and-after comparisons run side by side.

Lessons learned

• A title waiting on a script is a slow title

  Hero titles were split into words by JavaScript, so on a slow phone they appeared only after the scripts had run. They’re now split when the site is built and revealed in CSS from the first paint, with one copy of the text that screen readers read as a sentence.

• Chrome doesn’t count what starts invisible

  Text first painted fully transparent isn’t counted as shown until something repaints it, so the measure was random. Reveals now start at 1% opacity, which no one can see, and the measure matches what visitors see.

• Preloading can make it slower

  Fetching the MIT hero film early competed with the fonts and scripts and made the phone slightly slower. It was tried, measured and reverted.

• One long task stalls everything

  The NASA explorer built its grids in one block of over a second on a phone. It now builds them in small slices between frames, and its second zoom level only when it’s first used.

• Compare in the same run

  Lab scores drift by as much as the change being measured. Before and after now run side by side, on the same machine, several times.

• A pinch zoom can run a phone out of memory

  Pinch-zooming the home page on an iPhone 14 made Safari and Chrome reload it: every section kept its moving background ready to redraw at the zoomed size. The cause was found on the phone itself, by turning off one kind of layer at a time: backgrounds, animations, masks, films. Now a section far from view rests, and while the page is zoomed the section backgrounds step aside and return at normal size. The case studies never had the problem.

• The home page waits on purpose

  Its headline arrives with the film, because the choreography is the point. It now starts as the film’s first glide begins rather than after it ends, 3.6s sooner.

Rules that made it faster

Written down once, applied everywhere.

Every correction that could happen twice became a rule, kept in a working-notes file the AI reads before every session and in the project’s docs. That is what made the pace possible: the same feedback never had to be given twice.

More about this site