The brief for the hypershot homepage was one sentence: show the product, don’t describe it.

Reasonable. Restrained, even. What followed was a 3D room, a Blender file, a stack of shader ports, a pile of hand-built demos, and a profiling session in real Safari, driven over WebDriver. Here’s how a screenshot tool’s homepage got a little out of hand (in the best way possible).

We built a desk

Scroll the top of the page and you’re in a room: a desk, a monitor, a laptop, a keyboard, a chair, some plants. It was modelled and lit in Blender, and the lighting is baked into the textures, so your browser shows a properly lit room without having to light it. A bake takes about a quarter of an hour. We did a lot of bakes.

The camera started out animated in Blender too. Then iterating on a shot meant a round trip through Blender and an export every time, so the cameras moved into code: each shot is computed from the scene itself, aimed at the screens and the keyboard, so if a prop moves in Blender, its shot moves with it.

The scroll is the timeline

Nothing on the desk plays on its own. Your scroll drives everything, forward and back: the camera closes in on the keyboard as the capture keys go down, tilts up to the monitor, and hypershot takes a shot on screen.

There’s one rule, and it took a few tries to get right: going forward, the scene may never run the app’s UI faster than the app really runs it. Scroll as hard as you like; the capture plays at its true speed and the page catches up after. Going backward, anything goes. A homepage that fakes the product’s speed is lying about the one thing it’s there to show.

We ported the app to the web (a little)

The reticle that drags across the monitor isn’t a lookalike. It’s hypershot’s own Intelligence reticle shader, ported to WebGL nearly line for line. Same for the warp that flings the capture into the preview folder in the corner. When the page shows you what hypershot looks like, it’s running hypershot’s own code for it.

Further down, the feature demos went the same way. They aren’t videos. Each one is a live replica of the editor, built in HTML and SVG with the app’s own icons and its own theme colours. “Make it yours” runs the editor through every accent colour, in light and dark, using the same theme values the app does. If the app changes, the demos can change with it.

Not a video: the editor itself, running through the accent colours in light and dark.DOCSAppearance

The art came straight out of the designer’s Illustrator file, lifted by a script into SVGs placed where the artboard has them, so the page and the design can’t drift apart.

Performance was key

Motion like this lives or dies on pacing, and “feels faster” isn’t a measurement. Scroll speed got measured in a real Chrome at 60 frames a second, stretch by stretch, before any “it’s faster now” claim survived. More than once, it wasn’t.

Safari got its own investigation. We drove the real thing over WebDriver, timed every frame along the scroll, and found where WebKit spends its time: drawing the on-screen editors to a canvas and uploading them as textures is far more expensive there than in Chrome. The laptop and monitor screens were reworked around that.

Was it too much? Hell yeah. Do we regret it? Hell no.

A screenshot tool lives or dies on how it feels in your hands, and a page that only describes that feel would be selling it short.