Is a static HTML site a real option for a business landing page in 2026?

Yes, and often the right one for the first version. Zero-config hosting, instant deploys, nothing to patch, nothing to go down. The moment you need content someone else can edit, or user accounts, or payments, you need a backend — but that moment is a real requirement, not a default.

What's wrong with loading fonts and libraries from a CDN?

Nothing is wrong with it exactly, but every CDN request is a dependency on someone else's uptime, a third-party origin your Content-Security-Policy has to trust, and a request the browser makes before it can finish rendering. Self-hosting the same files removes all three for the cost of one deploy step.

When should a static site actually become a framework with a database?

When the constraint is content, not code. If updating the site means writing markup, or adding a page means writing HTML by hand, that's the signal — not a fixed timeline. Migrate for a concrete need (self-service editing, per-page URLs for SEO, user accounts), not because a framework is the default choice.

← Guides

Static first: Kodekid site shipped with zero backend for a week

9 September 2026

The order things actually happened in

This site went live as a single index.html file with no build step, no framework, and no database — a temporary holding page with a mailto link. Days later it had a scroll-driven hero animation, a case study with a video slideshow, and enough visitors that the next request was "I want to edit this myself and I want it to show up in search." That request is what actually justifies a framework and a backend — not doing it upfront because it's the modern default.

What "static first" bought in the meantime

Zero-config deploys. No build step means no build to break. Every push either works or the diff is obviously wrong.
No third-party requests at runtime. GSAP and both webfonts are vendored into the repo — downloaded once, committed, served from the same origin as everything else. No CDN outage can take a font down; no Content-Security-Policy has to trust an external host.
A page that works with nothing turned on. Every animation on this site is additive: strip the JavaScript, and the content is still there, still readable, still linking to the right places. That's not an accessibility footnote — it's what falls out naturally when the default state has to render correctly before you write the enhancement.

Where static actually stops being enough

A static file has no login page. It can't have one — there's nothing to authenticate to, no session to hold, no database row to check permissions against. The instant the ask becomes "let me edit this without asking for a commit," the answer isn't a bigger static file, it's a real backend: a database for the content, auth for the one person allowed to change it, and a build step that can regenerate pages from that data. That's a different architecture, deliberately adopted for a concrete reason — not a static site failing, but a static site having done its job until the job changed.

The migration itself doesn't need to be risky

The riskiest part of moving from hand-written HTML to a framework isn't the framework — it's silently losing the specific, hard-won correctness that accumulated in the old version while nobody was looking. A mobile performance fix, a fallback for JavaScript being disabled, an animation that reverses cleanly when scrolled backward — none of that shows up in a screenshot. Porting it means carrying the same logic over deliberately and re-running the same tests against the new version, not rewriting from memory and hoping nothing was forgotten.

Written by Lars Sohl

Frequently asked questions

Is a static HTML site a real option for a business landing page in 2026?: Yes, and often the right one for the first version. Zero-config hosting, instant deploys, nothing to patch, nothing to go down. The moment you need content someone else can edit, or user accounts, or payments, you need a backend — but that moment is a real requirement, not a default.
What's wrong with loading fonts and libraries from a CDN?: Nothing is wrong with it exactly, but every CDN request is a dependency on someone else's uptime, a third-party origin your Content-Security-Policy has to trust, and a request the browser makes before it can finish rendering. Self-hosting the same files removes all three for the cost of one deploy step.
When should a static site actually become a framework with a database?: When the constraint is content, not code. If updating the site means writing markup, or adding a page means writing HTML by hand, that's the signal — not a fixed timeline. Migrate for a concrete need (self-service editing, per-page URLs for SEO, user accounts), not because a framework is the default choice.

ENDA