LFH Lab Start a project
Lab Notes/Building
BUILDINGAPR 2026

Most marketing sites don't need a framework

Nearly every domain linked from this site is a folder of HTML. That's a decision, and it's the cheapest one I make.

Nearly every domain linked from this site is a folder of HTML files.

Eleventy builds them. Nginx serves them. There's no React, no Next, no Node process waiting for a request. When a visitor loads the page, a web server hands them a file. That's the whole stack, and it's the cheapest decision I make on every product.

What a marketing site actually does

It shows what the product is. It has a pricing page. It has a contact form, maybe a signup form, maybe a blog. It needs to load fast, look good on a phone, and not go down.

None of that requires state. Nobody logs into a marketing site. Nobody's data lives there. The one thing that looks dynamic, the form, posts to labcomms, which is a separate service and the only server-side code in the picture. Everything else can be decided at build time and written to disk.

When the content changes, I change a Markdown file and rebuild. Eleventy turns templates and content into HTML in a few seconds. The output gets copied to the server. Done.

What a framework would cost

Not money, mostly. Attention.

A marketing site on Next needs a Node process running, which means a process manager, memory to watch, and something to restart it when it dies. It needs a build pipeline that can break when a dependency updates, and dependencies update weekly. It needs a hosting arrangement that understands server-side rendering. And it needs someone to keep all of that current for a site whose content changes twice a quarter.

Multiply that by thirteen products. Static sites have a maintenance cost of roughly zero. Framework sites have a maintenance cost that starts small and never reaches zero. Over a portfolio, that difference is the difference between a weekend of upkeep a year and a weekend a month.

When I break the rule

Some products aren't marketing sites; they're apps with a marketing page attached, and those get a real framework. Leader Ethos has accounts, assessments, a hiring dashboard, and PDF generation. That's state, and it's built on Next. FairwayNation processes registrations and payments. State. The mobile apps are Expo, which is its own conversation.

The test is simple. Does the site have state? Does anyone log in? Does the page differ per person? If yes, it's an app, and it gets app tools. If no, it's a folder, and it gets Eleventy.

The mistake I see most often is the reverse: a marketing site built with app tools because that's what the developer knew, or because the product might need state someday. Someday is when you rebuild it. Until then, it's a folder.

If you're hiring me

The first question I ask about any web project is whether it has state, and the answer decides half the architecture. Plenty of "we need a web app" requests turn out to be a static site plus one form, and the client is happier hearing that than being sold a Node process they'll have to babysit.

Before you run npm create anything, ask whether the site has state. If it doesn't, it's a folder.

More notes, or the work itself.
Everything here comes from products that are live right now. Read the rest of the notes or go look at the shelf.
All notes The work →