Our first case study is the page you're on.

A studio site has an awkward job: it has to prove capability in the first five seconds to an audience that has already skimmed several competitors. Claiming to build fast, impressive websites is worthless — the site itself either demonstrates it or it does not.

So the hero is a real 3D dream catcher, rendered live in your browser. Not a video, not an image sequence, not a pre-rendered turntable. You can see it full-screen and uncropped, where it runs at higher fidelity with depth of field and bloom.

That creates the central tension of the project. Real-time 3D is the most convincing proof available and also the fastest way to build a slow website. Everything below exists to resolve that.

• Framework: Next.js App Router with React and TypeScript. Every public page is prerendered as static HTML at build time.
• 3D: React Three Fiber and Three.js, with the web and feathers generated in code rather than loaded as a model file.
• Styling: Tailwind CSS, with the hero animations written as plain CSS keyframes.
• Infrastructure: a dedicated VPS behind nginx, with the app supervised by a process manager and TLS renewed automatically.

Most of the engineering effort went into four choices that a visitor never sees directly but would immediately feel the absence of.

• The headline does not wait for JavaScript. The hero copy was originally animated with a JavaScript motion library, which meant it started at zero opacity and only became visible once scripts had loaded and hydration had run. On a slow connection that delays the largest element on the page. It now animates with CSS keyframes instead, so the text is painted and readable immediately.
• The woven web is one object, not hundreds. Drawing each thread of the lattice separately would mean hundreds of draw calls every frame. The entire web is generated procedurally and merged into a single geometry, so the whole lattice costs the graphics card one pass.
• Lighting is self-hosted. The scene is lit by an HDRI environment map served from our own server rather than a public CDN, compressed and cached for a year. No third-party outage can stall the page, and nothing about your visitors is disclosed to another company to render a light source.
• Weak devices get a different scene. Rather than hoping phones cope, low-powered hardware is detected and served a reduced scene with the expensive effects switched off. Visitors who have asked their operating system to reduce motion get a calm version regardless of their hardware.

The standalone 3D experience is a deliberately different build to the homepage. It uses a higher-resolution environment map, tube geometry instead of lines, individually generated feather barbs, and post processing for depth of field, bloom, and film grain. The camera dollies in on load and drifts with the pointer.

It also renders with no header and no footer, which is a structural decision rather than a styling one: the shared site chrome lives in a nested layout, so a route placed outside that group gets the whole viewport to itself.

It is deliberately excluded from search indexing. A page that is essentially one WebGL canvas has almost no text for a search engine to evaluate, and letting it compete with the pages that should rank would be a self-inflicted wound.

A build is not finished when it looks right on a laptop. This site runs on infrastructure we configure and maintain ourselves, which is the same arrangement client projects get.

• Delivery: nginx in front of the application, with compression on and long immutable caching for versioned assets.
• Security headers: strict transport security, a content security policy, frame and MIME-type protections, and a restrictive permissions policy.
• One canonical address: the www hostname and plain HTTP both redirect to a single HTTPS origin, so search engines never see duplicates.
• Measurement: analytics with conversion tracking on form submissions, email clicks, and phone clicks — the actions that represent revenue.
• Enquiries cannot be lost: the contact form writes every submission to storage before it attempts to send the notification email, so a mail outage delays a reply instead of destroying a lead.

Client case studies are being written up and will appear here as they clear review. They will follow the same shape as the breakdown above — the problem, the constraints, the decisions, and what it took to run — because that is more useful to someone evaluating a studio than a grid of screenshots.

If you want to see relevant examples before then, ask on a call and we will walk you through them directly, including the parts that were difficult.

Every project runs through the same design and development process, whether or not it includes 3D.