A Stripe-style homepage, rebuilt as an Astro codebase

Ledgerline is a payments company that does not exist. Its homepage does, as ten Astro components and one stylesheet, and it was built so that the answer to what an enterprise site becomes in a codebase could be a page rather than a paragraph.

When a team describes the site they want, the description is usually a URL, and the URL is usually Stripe's. A skewed gradient under a headline, the product drawn into the hero, a wall of logos, a code sample in a dark band, a row of large numbers, one customer quote, three doors at the bottom. The pattern is so settled that most infrastructure companies now share it, which makes it a useful thing to rebuild: if a page in that shape can be shown as an Astro codebase, so can most of the sites that copy it.

So I built one. Ledgerline is an invented payments company with an invented customer list and invented numbers, and the note at the top of the page says so before anything else can be read. Nothing on it is a client of mine and nothing on it is a claim about anybody's product. It is the shape of the category, drawn once, so it can be pointed at.

What the pattern actually contains

Writing the inventory is the first thing to do with any page about to be rebuilt, and it is more useful than it looks. A Stripe-pattern homepage is nine sections, and each one has a job a reader can name.

1. The nav. Four items and two actions. Products, who it is for, developers, pricing; sign in, contact sales. Five items would be a menu.
2. The hero. The claim on the left, the product on the right. The product is drawn as a dashboard with a checkout standing in front of it, because the sell of a payments company is that the same money shows up in both.
3. The logo wall. Six marks, each set differently, so the row reads as six companies and not one name six times.
4. The product rows. One per product, alternating text and picture, so the eye is handed from one to the next.
5. The developer band. Dark ground, a code sample with language tabs, and the four things an engineer checks before agreeing to an integration.
6. The numbers. Four, each stated rather than compared.
7. The customer. One quote, full width, between the proof and the ask.
8. The ask, and three doors. Pricing, docs and sales are the three ways somebody leaves a page like this with intent, and all three sit within reach of the last headline.
9. The footer, which on a site in this category is the sitemap.

The reason to write this down before touching any code is that the inventory is the estimate. Nine sections with a known job each is a different project from "a homepage like Stripe's", and the second one is the brief most rebuilds start from.

What each section became

One component per section, in a folder of its own, and one stylesheet. The data for a section sits at the top of its file and the markup below, which is the convention that makes the page cheap to change: a fourth product is a fourth entry in a list, not a fourth copy of the row.

const PRODUCTS = [
  {
    num: '01',
    name: 'Payments',
    title: 'One checkout, every local method.',
    copy: 'Cards, wallets, bank debits and the regional methods …',
    art: 'methods',
  },
  // …
];

The page then maps over that list and draws a row for each, flipping every second one. The logo wall is an array of six strings. The three doors at the bottom are an array of three objects. The footer is four columns, each a heading and a list of names. Every part of the page that repeats is already a list in the file, which is worth noticing, because those lists are exactly what a CMS would hold if the site had one.

The language tabs on the code sample are the one thing on the page that behaves like an application, and they are three radio inputs and a sibling selector. The checked radio shows its pane. No script is involved, which matters because a tab strip is the first place a "no JavaScript" claim usually fails.

The gradient is the first concession. Stripe's is a WebGL program that animates; this one is four CSS gradients painted on an element skewed nine degrees, and it does not move. A team that wants the animated one is asking for a different kind of work, and it is better to know that at the inventory stage than at review.

What it weighs

The point of moving a site into a codebase is partly that the output can be measured, so here is the page measured, from the production build on the day this was published.

The built page

23 KB

of HTML 7 KB compressed, 1,195 words

17 KB

of its own CSS 4 KB compressed, one file

0 KB

of JavaScript the page adds the tabs are CSS

0

image requests every drawing is markup

The honest comparison is not with Stripe, whose homepage carries a product org's worth of experiments and tooling, but with the same nine sections on a site builder: the builder's runtime, its interaction library, and whatever the marketing team has added to the head over three years. Those are the numbers a performance check on your own site will show, and the performance page explains which of them a migration changes and which it does not.

What this page does not prove

It has no CMS behind it. A marketing team shipping forty pages a quarter needs one, and choosing it is the decision that shapes the rest of the build; the demonstration skips it because a homepage is one page. It has no localization, no A/B tooling and no consent layer, all of which a real enterprise site carries and all of which are their own work. The product drawings are CSS rather than screenshots, which is fine for a company that does not exist and would not be for one that does. And the numbers in the stats row were made up to fill the shape, which is the one thing a real page must never do.

What it does prove is narrower and, I think, more useful: that the pattern reduces to nine components and a list for each repeated thing, that the result is small, and that a reader can look at a page in the exact shape of their own and see what it turns into.

Doing it with a real site

The method does not change when the site is real. It is the one the demonstration followed.

1. Screenshot the live page at a desktop width and a phone width. The phone one is where the hero's layout gets decided, because the product picture that sits beside the headline on a desktop has to go somewhere underneath it.
2. Write the inventory. One line per section: what it is, what it is for. Anything that cannot be given a job is a section the rebuild can drop, and that conversation is easier before the build than after.
3. Build one component per section, data above the markup. Resist a shared "card" component until the third time the same card appears; the second time is usually a coincidence.
4. List what repeats. The logos, the products, the doors, the footer columns. That list is the first draft of the content model, and it is the thing to put in front of the people who will edit the site.
5. Measure the build. Bytes of HTML, CSS and JavaScript, and the number of requests, next to the same numbers from the live page. That is the comparison the rebuild is argued on.

The sections themselves are the smaller part of the work for a page like this. The decisions around them, the gradient, the mobile nav, which parts marketing edits and which parts engineering owns, are where the time goes, and they are also where a sample is worth more than an estimate.

If you run a site in this shape and want to see your own homepage done this way, send me the URL. A homepage rebuilt as a sample is the fastest way to find out whether the full move is worth scoping, and I would rather show it than describe it.