If I describe our old homepage, you'd picture your own. A hero line, a product shot at a three-quarter angle, a logo strip, a row of feature cards underneath. This is the standard for most SaaS companies.

Until our CEO Hamzah asked for a homepage that would turn heads and split opinion. One that was built to polarise.

So, we built it. Live now at lightdash.com.

Just a few weeks ago, I'd never built a 3D asset or even animated one. Now, I’ve built our whole homepage onto a Game Boy. So, these are the lessons that got me from zero to shipped.

Lesson 1: Know what risks you’re willing to take before you start building

Building a divisive homepage means some traffic will bounce. Users will land on your website and may get confused and log off quickly. So, we had to decide upfront whether or not that was an acceptable cost for us. 

The reason this is so important is because half-committing is worse. If you compromise on some of your design to make it less polarising, you’ll get an odd website with no upside: it’s too weird to convert the skeptics and too safe to be talked about. 

We agreed early on that losing some visitors would be the price of building this traffic, and we made this decision with the team member who owns website metrics so everyone’s in the loop. This meant that every discussion afterwards was about idea execution instead of whether we’d lose traffic.

Lesson 2: You don't need to model 3D hardware, you can generate it in code

The new Lightdash homepage is a single file of 6,112 lines running three.js. The console shell, cartridge, buttons, and navigation planets aren't modeled in a 3D tool; they're generated at runtime, along with the dithered shadows, glows, and pixel sprites baked onto canvases while the page loads.

Using code was the easiest way for me to build the website because it meant that every part of the 3D hardware was a function. I could tweak and re-run it as many times as I wanted, rather than build a mesh I didn't know how to sculpt.

It's also what made the details tunable: my favourite moment on the page is when the cartridge slides in and the console boots with a click. And because this is built in code, I could replay it on a loop until it felt right. 

Lesson 3: The hardest problem is deciding what to cut

Unfortunately, a console screen is tiny. And we had to try and fit our whole product inside it. That's a content problem wearing a design costume, and it's why you should get your marketer involved from day 1 rather than at review.

We knew there was no way we could get everything on here, and in a format that’s already overwhelming you want the content to be as simple and easily digestible as possible. That problem turned out to be harder to solve than we thought. 

Luckily, Shanzé was able to filter our whole offering down to 6 sections that could survive those confines. We cut things I would have defended on a typical homepage, and the page is better for it.

Lesson 4: Design the exit before you design the experience

Like I said earlier, an unfamiliar interface has a cost, and we didn’t want returning visitors to pay it. Someone arriving on our website for the fourth time to re-check pricing shouldn’t have to play a game to get there.

So, what we protected was the top nav. It stays visible throughout the Game Boy experience as the escape hatch. If the console isn't for you, the ordinary website is one click away at all times. 

We built this way out first, because it's the part you can't retrofit once the rest of the experience has been built.

Lesson 5: Done is better than perfect

This lesson showed up twice. 

First, we realised the console wasn’t working for mobile view. At phone width, the screen inside the hardware was too small to be legible. After trying multiple things to make the console work on mobile view, we decided to make the console drop away and have the screen fill the viewport after the Game Boy boots. This way, you keep the pixel-art navigation and lose the plastic shell. Every section fits one screen with no scrolling, and the type snaps to a 4px scale measured at 390×844.

The second problem occurred when we found out the entire homepage doesn’t work on older browsers. 

I found out that Gecko treats pixelate filters, rounded-corner clipping, and 3D matrix transforms differently enough that parts of the interface visibly tore. Three of those I fixed, each fix gated to Gecko so Chrome and Safari render exactly as before. The fourth I couldn't: Gecko rasterizes a perspective transform in a way that shredded the overlay, so on Firefox the tilt had to go. Now, the console locks dead-on and the dot-matrix dissolve becomes a clean fade.

So on both occasions, we decided a homepage that renders wrong is worse than one that moves less.

Lesson 6: Break your build into parts other people can steal from

Because the how is more useful than the what, I pulled the whole build apart into an asset lab.

Every 3D part, screen, and product visual sits isolated running its real animation, next to the runtime-generated textures and the style guide. It's sliced out of the live source rather than copied, so it can't drift from the site.

Doing this changed the build itself. Going into this build knowing that each piece would stand alone on a white page forced me to keep the parts honest.

The distance between v1 and shipped

Here's the first working version next to what went live:

v1 already had the idea: a screen in space, pixel buttons, a little UFO. Everything that makes the final version feel like an object came from iterating on the thing that was going to ship. I'd have learned far less building a practice version first, and it would have taken longer.

Whether or not this needed a bigger team is up for debate. I'd say there's always room for more to do.  What I do know is that the question now isn't whether you can build something like this, it's whether you're allowed to try.

Have a look at lightdash.com and let me know what you think. Best on desktop, with the arrow keys or your mouse.

Or pull it apart at the asset lab if you want to build one yourself.