Tools like Astro, Eleventy, and Hugo build that folder for you from Markdown files and templates. Hosts like Netlify, Vercel, and Cloudflare Pages then serve the result from a CDN, often for free.

Then your site needs to actually do something. A reader wants to leave a comment, or someone wants to email you. Maybe you want to show live prices, hide a page behind a login, or collect email addresses before a launch.

Most developers reach for a backend at this point. They spin up an Express app, add a database, and pick a hosting plan. Now they own a server, and servers need care forever.

The good news is that you often don't need one. Most dynamic features on a small site work fine without a server of your own, so here's how to think about the problem.

Table of Contents

• Static Does Not Mean Frozen

• Start With What the Browser Already Does

• Handling Form Submissions

• Serverless Functions for the Rest

• Databases and Logins You Can Rent

• Comments, Search, and Payments

• Know When You Have Outgrown It

Static Does Not Mean Frozen

The word "static" describes how your HTML reaches the browser, not what happens after it lands. A static site can still run all the JavaScript you want. It can fetch data, rewrite the page, listen for clicks, and talk to any public API.

There's only one thing it can't do, which is run your code before the page is sent. That means it can't keep a secret, query a private database, or make a decision based on who is asking.

That single limit is the whole design problem. Once you see it clearly, the rest is just sorting. Some work belongs in the browser, some belongs in a service you rent, and a small slice needs to run somewhere private.

Start With What the Browser Already Does

Check the platform before you add anything to your stack, because browsers ship with more power than most of us use.

The fetch API pulls JSON from any public endpoint. The <dialog> element gives you an accessible modal with no library, and <details> gives you an accordion. CSS now handles sticky headers, scroll-driven animation, and container queries, all of which used to need JavaScript.

A lot of features that seem to need a backend are really just a fetch call and a template string. A weather widget, a GitHub activity feed, a currency converter, a live score, or a Mastodon timeline: every one of those runs happily from the browser, because the data is public and the endpoint needs no key. Write the fetch, handle the loading and error states properly, and move on.

Handling Form Submissions

Forms are where most static sites hit their first real wall, because a submission has to go somewhere your visitors can't see. You can't put a database password in client-side code, and you can't send email straight from a browser.

Luckily this problem has been solved many times over, and most static hosts will handle forms for you. Netlify Forms needs one extra attribute on your form tag. After that, Netlify catches each submission at the edge, stores it in a dashboard, and either emails you or pings a webhook.

Sometimes you need more than that. Spam filters, file uploads, conditional logic, multi-step flows, payments inside the form, or rows that land in a spreadsheet with no glue code all point toward a dedicated tool. This roundup of the best form builders is a good way to compare your options, since the real differences come down to logic, integrations, and how much control you keep over the markup.

Either way, the choice is about ownership. Write your own form endpoint and you own the validation, the rate limits, the spam defense, the storage, the alerts, and the deletion requests that arrive under GDPR. That's a lot of work for a contact form. Build it yourself when the form is part of your product, and rent it when the form is just a way for people to reach you.

Serverless Functions for the Rest

Sooner or later you will need to run a few lines of code in private, whether to sign a request, hide an API key, or reshape a response before the browser sees it. That is exactly what serverless functions are for, and they're the smallest possible step away from a purely static site.

You drop a file into a folder, and your host turns it into a URL on the next deploy. That's the entire setup, and it works the same way in Netlify Functions, Vercel Functions, and Cloudflare Pages Functions. The code stays short:

export default async function handler(request) {
  const res = await fetch("https://api.example.com/data", {
    headers: { Authorization: `Bearer ${process.env.API_KEY}` },
  });
  const data = await res.json();
  return Response.json({ total: data.items.length });
}

Your key lives in an environment variable on the host, so the browser calls /api/handler and never sees it. There's no server to keep alive, no operating system to patch, and no bill on a quiet day.

This is the right home for anything that needs a credential. Use it to send email through Resend or Postmark, call an AI model, check a webhook signature, or proxy a paid API whose key would otherwise leak within a day.

Databases and Logins You Can Rent

State is the last piece people assume needs a server, but it does not. Supabase puts Postgres behind a REST API with row-level security. Those rules live in the database itself, so you can query it from the browser and still be safe. Firebase does much the same with a different data model, while Cloudflare D1 and Turso give you SQLite at the edge.

Logins follow the same pattern. Clerk, Auth0, and Supabase Auth all handle sessions, password resets, social logins, and two-factor codes behind a client SDK. Authentication is genuinely hard to get right, so leaning on an audited service here isn't laziness. It's sensible risk management.

Comments, Search, and Payments

The last few common features have drop-in answers too. Giscus turns GitHub Discussions into a comment box with a script tag and no database at all. Pagefind builds a search index while your site builds and ships it as static files, so full-text search costs you nothing at runtime.

Stripe covers money. Payment Links and Checkout let you sell something with a plain link, and Stripe handles the card, the tax, and the receipt. Your own site never touches card data.

Know When You Have Outgrown It

This model has a real ceiling, and you should be aware of it rather than fight it. Watch for a few signs: your logic is now spread across six services, your monthly SaaS bill beats the cost of a small server, cold starts are hurting real users, or you need long jobs, a queue, or a socket that stays open for hours. When that day comes, a regular application server is the simpler tool, so move.

Until then, this setup buys you things that matter. Your site stays fast by default, your attack surface stays small, and your time goes into the product instead of the plumbing. Start with the browser, add a function when you need a secret, and rent the hard parts.

Hope you enjoyed this article. You can connect with me on LinkedIn.