Runware, rendered

The brief

Runware posted for a contractor to redesign their website: a conversion-focused site for developers, built in production code. We answered with the site instead of a cover letter. It is a concept nobody commissioned, and it is not affiliated with Runware.

We set the rules before drawing anything. The headline, the value line and both buttons work in the first screen, before any animation runs. Every scroll moment makes one Runware claim visible. Get API key never leaves the screen, on a desktop or a phone.

What we made

• A homepage in eight chapters: Request, Models, Engine, Cost, Compute, Scale, Agents and Ship
• A first screen where scrolling drives a real four-step denoise of one image, with the request on screen
• A model chapter where one prompt runs on six models and only the model string changes
• A long case study page that walks through the research, the build and the testing

How it works

It is built in the client's own stack: Next.js 16 with the App Router as a static export, React 19, Tailwind v4 and shadcn/ui, with GSAP ScrollTrigger and Lenis for motion and React Three Fiber for 3D.

Every image on the page went through the Runware API: 25 requests across 12 models, each tagged with its real model id and measured latency. Before the first commit we studied 62 recent Awwwards Sites of the Day and benchmarked seven peers, from fal and Replicate to Vercel and Linear.

One build contract set the stack, tokens, copy rules and file ownership, then seven builders worked at once, each owning its own files. Every chapter was screenshotted across its scroll range and sent back with specific defects until it held.

What we would fix first on runware.ai

The live homepage sells cost but shows no product above the fold, so the redesign puts a real request and its result in the first screen. Their proof numbers sit far down the page, so they moved next to the claims they support. And the model count reads differently from page to page, so the concept uses one number everywhere.