What Actually Builds a Landing Page? Ten Organisms, One Cut

A landing page is one page built to make a visitor take one action — sign up, book a demo, buy — and every design guide agrees it needs a clear headline, one call-to-action, and no distracting navigation away from the goal. What those guides don't show is what a real one is actually built from. This one audits our own home page's template file, plus the 66 landing-category products in this catalog, instead of describing the genre in the abstract.

What a real landing page is made of, read from the file that assembles it

src/components/templates/HomeTemplate.tsx is the single file that decides what appears on this site's own landing page, in order:

// src/components/templates/HomeTemplate.tsx
<Header />
<main id="main">
  <Hero />
  <FeaturedTemplates />
  <TechStack />
  <Features />
  <FeatureTabs />
  <UseCases />
  <Testimonials />
  <Blog />
</main>
<Footer />

Ten organisms, each one a full page section (its own <section>, its own data file, nothing shared between them beyond design tokens). That's the actual answer to "what goes on a landing page" for this specific one: a hero, a product showcase, a tech-credibility strip, a benefits section, a deeper features tour, a use-cases section, social proof, and a content teaser — bookended by the header and footer every page shares. Design galleries show you the finished screenshot; this file shows you the ten decisions that produced it, in the order a visitor actually scrolls through them.

The organism that isn't there, on purpose

The file's own comment explains a section that's missing:

/**
 * `Carousel` (marquee of product screenshots) is intentionally unmounted until
 * real screenshots exist — see docs/PRODUCTION-READINESS.md. Re-add it here
 * when its assets land.
 */

Carousel exists as a built component (src/components/organisms/Carousel.tsx) but isn't in the render list above — it was deliberately left out rather than shipped with placeholder content. That's a real editorial call most "landing page best practices" posts never mention: a section built and ready is not the same as a section worth shipping, and an empty or fake-content section actively hurts a landing page more than one fewer section does. The comment documents exactly why, and exactly what has to be true before it comes back.

What ten sections actually cost, measured

"Simplicity is key" is the design-guide version of this advice; the measured version is what those ten organisms cost against real Lighthouse categories, run against this exact page:

¹ The 96 is a local-server artifact (a Vercel-Analytics beacon that 404s off-platform when there's no real CDN to answer it) — it reads 100 on the deployed site. Accessibility and SEO land at a clean 100 on both form factors; the only real gap is mobile performance, and it's a deliberate one, not an oversight — closing it further would mean removing interactivity the page is built to have, which is a product decision this page has chosen not to make. Ten sections, in other words, is not automatically "too many" — it's compatible with a perfect accessibility and SEO score as long as each one earns its place, which is the same test that got Carousel left out.

What 66 landing pages have in common structurally

This catalog's landing category — 66 of its 111 products, the largest single category — spans wildly different businesses. Two of them, read straight from their whatsInside catalog entries, make the point without needing to be described:

Neither product shares a single content item with the other, and neither was written with the other in mind. What they share is the row structure itself: something to preview or browse first, a grid of what the business actually offers, a credibility beat, then content plus a conversion path. That's the same attention → credibility → detail → action sequence HomeTemplate.tsx's ten organisms demonstrate, arrived at independently by two products in unrelated industries — which is stronger evidence for the pattern than either one alone.

Why "good landing page examples" doesn't answer "how is one built"

Search "landing pages design" and the results are a page-builder product (Canva), a portfolio-inspiration gallery (Dribbble), and a definitional blog post. All three show you finished screenshots. None shows you the file that decided section order, or names the section that got cut and why. That's the actual gap between a gallery and an audit: a gallery answers "what does a good one look like," an audit answers "what decisions produced it" — the header comment above is one such decision, made visible only because it's sitting in the source file, not in a screenshot.

The hero image is where "simple design" meets a real performance bug

Design guides agree the hero needs "a visual" without saying which visual decisions actually matter. This page's own hero image comes with the comment that documents a real mistake it once made:

// src/components/organisms/Hero.tsx
{/*
  The LCP image, so it stays eager + high priority — but the
  frame is only ~330px wide on a phone, and shipping the
  1600px file there cost 43 KiB of the 46 KiB for nothing.
  `sizes` mirrors the max-w-[745px] frame the wrapper sets.
*/}
<img
  fetchPriority="high"
  loading="eager"
  src="/images/hero-desktop.webp"
  srcSet="/images/hero-desktop-800.webp 800w, /images/hero-desktop.webp 1600w"
  sizes="(max-width: 745px) 100vw, 745px"
  className="w-full"
/>

The hero image is this page's Largest Contentful Paint element, so it deliberately skips lazy-loading (loading="eager", fetchPriority="high") — the opposite of the lazy-by-default rule every other image on the page follows. But shipping the full 1600px file to every visitor meant a phone loading a ~330px-wide frame was downloading 43 of 46 KiB it would never render at that size. The fix is the srcSet/sizes pair: two file sizes, and sizes tells the browser which one a given viewport actually needs. "One clear visual" in a design guide and "the right file size for the viewport that's loading it" are two different problems, and only measuring the second one catches this class of bug.

Troubleshooting: common landing-page section mistakes

Frequently asked questions

How many sections should a landing page have? There's no fixed number — this site's own home page runs ten organisms, but a single-product landing page in this catalog might run five or six. The number that matters is how many sections sit between the hero and the first call-to-action, since that's the gap a visitor has to cross before converting.

Should I use a page builder (Canva, Wix) or a coded template? A builder gives you drag-and-drop control over a fixed set of blocks; a coded template gives you the exact organism-per-file structure shown above, editable at the component level. If you need a specific section removed cleanly (the way Carousel is unmounted here rather than left in with placeholder content), a coded template makes that a one-line change; a builder makes it a manual delete-and-hope.

Why do so many landing pages look structurally similar despite different industries? Because the underlying job — get a stranger to take one action — has the same shape regardless of what's being sold. This catalog's 66 landing products prove it: wildly different content, the same attention → credibility → detail → action sequence underneath.

What's the difference between this and a "best landing pages" roundup? A roundup shows finished pages and ranks them by appeal. This audits one specific file that assembles a real page, including the one decision (an unmounted section) a screenshot could never show you.

Templates in this post

ASoc Neuron (a neural-network AI platform site), ASoc Nexus (a SaaS app marketing site) and ASoc Nimbus (a cloud SaaS site) are three of the 66 landing-category products built on this same organism pattern.

Browse the full sets: Next.js landing page templates, Tailwind landing page templates. For the SaaS-specific build walkthrough, see Next.js SaaS Landing Page; for a gallery-style tour of finished examples, see Best SaaS Landing Pages.