Explaining a Complex Product on a Simple Page

The hardest homepage to write belongs to a genuinely complex product. If you sell socks, your page writes itself. But suppose you sell infrastructure software that sits between other pieces of infrastructure software, doing something that took you two years to build and takes ten minutes to explain properly. Now the page is a real problem. Everything true about the product is complicated, and everything simple you could say about it feels false.

Most companies resolve this tension in one of two bad ways. The first is to explain everything, which produces a homepage that reads like documentation: accurate, exhaustive, and abandoned by the visitor around paragraph two. The second is to explain nothing, which produces the fog headline — “Infrastructure for the modern enterprise” — that’s technically true of the product and also of ten thousand other products. Both failures come from the same misunderstanding: treating the homepage as the place where the visitor must come to understand the product. It isn’t. It’s the place where the visitor decides whether understanding the product is worth their time.

That reframing changes what the page needs to do. A stranger doesn’t need the full picture in five seconds. They need one true, plain sentence that lets them file you correctly. Filing is the key word. When people encounter something new, the first thing they do is fit it into a category they already have: it’s like X but for Y, it replaces Z, it sits between A and B. Your first sentence should hand them the file folder. “We back up your database automatically” is a filing sentence. It’s not the whole truth — maybe the interesting part is how the backups work, or what they cost, or the recovery guarantees — but a stranger who reads it knows what shelf you go on, and once you’re on a shelf, they can absorb detail. Detail without a shelf is just noise.

The objection I hear from technical founders is that the simple sentence undersells the product. They spent years on subtleties, and “we back up your database” flattens all of it. This objection confuses the first sentence with the last one. Nobody is proposing that the page stop there. The structure that works is a gradient: the simplest true statement at the top, then progressively more precision as you move down, with the reader deciding at each step whether to continue. The physicist explaining their work at a dinner party does this instinctively. They don’t open with the field equations. They open with “I study why some materials conduct electricity with no resistance,” and if your eyes stay lit, they go a level deeper. The homepage is a dinner party where the guest can leave without excusing themselves. Every level of the gradient has to earn the next one.

What makes this genuinely hard is ordering the details. Once you’ve earned a second paragraph, which subtlety goes first? The rule I’ve come to trust is: answer objections in the order a skeptic would raise them. After “we back up your database automatically,” a skeptic thinks: which databases? Then: how fast can I restore? Then: what does it cost? The page should answer in that order, because that’s the order in which the reader is generating reasons to leave. Most complex-product pages instead order details by how proud the team is of them, which is why you see architecture diagrams before pricing and design-philosophy essays before a list of supported platforms. Pride ordering serves the writer. Objection ordering serves the reader.

There’s also a trap specific to smart teams: mistaking vocabulary for explanation. A page can be full of correct technical terms and still explain nothing, because terms only communicate to people who already know them — and the people who already know them are the people who least need your homepage. When I scan sites at GazeSite, the clarity checks flag pages where the density of jargon crowds out plain statements of what the thing does, and it’s remarkable how often the most sophisticated products have the least comprehensible pages. It’s not because the writers can’t write plainly. It’s because plain writing feels like a demotion. Saying “we make your tests run faster” after building an elaborate distributed system feels like describing a cathedral as a big room. But the visitor is standing outside the cathedral. Get them through the door first.

The consolation, if you sell something complex, is that complexity done right becomes an advantage on the page. A simple product can only be described; a complex one can be unfolded, and unfolding is interesting to read when each layer answers the question the previous one raised. The companies that do this well end up with homepages that feel like good teaching. The ones that don’t end up choosing between a page that says nothing and a page nobody finishes. The choice was never between simple and complete. It was about sequence: one plain sentence first, and everything else in the order a stranger would ask for it.