Architecture 6 min read

Your Static Site Doesn't Need a Build Pipeline

Build pipelines were designed for complex JavaScript applications and got applied to everything by default — including simple content sites that don't need them. Here's the case for skipping the pipeline.

April 17, 2026
Open laptop displaying code on desk in bright, modern office setting. Ideal for tech and remote work context.

Setting up a 10-page marketing site

Count the tools. You reach for Next.js or Astro. You run npm init. There's a bundler config. PostCSS for Tailwind. A Netlify account. A GitHub repository. Environment variables for the CMS token. A build hook URL from Netlify, pasted into the CMS webhook settings so content publishes trigger a rebuild. Maybe a CI configuration file.

For a 10-page marketing site.

The honest question: does a 10-page marketing site need any of this? For most content-focused sites, the answer is no.

How we got here

The JAMstack movement was right about the fundamentals. Pre-generated static HTML served from a CDN is faster, cheaper, and more secure than server-side rendering at request time. Netlify and Vercel made this genuinely accessible. The developer tooling that emerged around it was designed well.

The problem is that the tooling was designed for applications — large JavaScript codebases with complex component trees, client-side routing, and sophisticated build requirements. It's good tooling for that use case. It became the default for everything, including content sites that have no more complexity than a Markdown file and a CSS stylesheet.

When the tool doesn't fit the problem, you inherit the cost of the tool without the benefit.

What the build pipeline actually costs

Setup time. Getting a new project from blank to deployed with a modern build pipeline takes a few hours if you know the stack, longer if you're making decisions. Framework version, bundler config, PostCSS, Tailwind setup, environment variable management, deploy configuration. That's before you've written a single line of page-specific code.

Maintenance surface. Every dependency is something that can break. Node version compatibility, framework major version upgrades, bundler updates, plugin compatibility matrices. A project set up in 2022 may require non-trivial work to update in 2026. For a client site, that maintenance either falls on your agency or accumulates as technical debt.

Knowledge transfer. When someone takes over the project — a new developer, an agency handoff, a client who hired a different maintainer — the build pipeline is the first thing they have to understand. For a content site, this is overhead with no corresponding upside.

Build failures. Build-time failures are a category of problem that doesn't exist if there's no build. A content editor publishes a page update. The build fails because a dependency was updated. The content doesn't go live. Now someone has to debug a build system to publish a headline change.

The cognitive tax. Even when everything is working, the build pipeline occupies mental space. "Did the last deploy succeed?" is a question that content sites shouldn't need to ask.

What a content site actually needs

Strip it back. What does a content site need that a build pipeline provides?

  1. HTML generated from content and templates
  2. CSS applied to those templates
  3. JavaScript for any interactive elements
  4. Image optimization
  5. A CDN to serve the output
  6. A mechanism to rebuild when content changes

A build pipeline is one way to get all of these. It is not the only way — and for a content site, it is often the most complex way.

SleekCMS's answer

The SleekCMS site builder generates static HTML from EJS templates and your content models. The output is standard static HTML, CSS, and JS — compatible with any hosting provider.

What you don't configure:

  • No package.json or dependency management
  • No bundler configuration
  • No PostCSS config
  • No CI/CD pipeline
  • No build hooks or webhook plumbing
  • No deploy configuration

What's handled automatically:

Tailwind CSS. Create /css/tailwind.css in your workspace. It compiles automatically on every save. No tailwind.config.js, no PostCSS, no @tailwind directives to remember.

Image optimization. Every uploaded image gets a transform URL. Append ?w=800&fmt=webp&q=85 and you get a resized, converted, optimised image. No separate image CDN, no <Image> component, no next.config.js entry.

Forms. Add data-sleekcms="contact" to any form element. Submissions are captured, stored, and trigger email notifications. No backend, no Formspree account, no serverless function to maintain.

Preview. Page and full-site preview run in the cloud. No local dev server, no port to remember.

Deploy. To SleekCMS hosting, Netlify, Vercel, or download as a ZIP. No repository required.

Local workflow for developers

The developer who will immediately ask: "but what about local development?"

The cms-cli provides local editing — real files, your editor, AI assistance — without a local build tooling stack:

npx @sleekcms/cli --token YOUR_AUTH_TOKEN

File saved in VS Code → watcher → SleekCMS API → rebuilt in the cloud → preview updated. You get the local development experience without running a local build.

This is the key distinction from a traditional pipeline: the sync is to the SleekCMS API. The build happens on their infrastructure. Your machine doesn't need Node, Vite, or a dev server running.

When you do need a build pipeline

This argument is not that build pipelines are never the right choice. They are, in specific contexts.

You probably do need a build pipeline if:

  • You're building a React or Vue SPA where client-side interactivity is the core product — not the delivery mechanism for content, but the product itself
  • You have a large team with PR-based review workflows where per-PR preview environments are valuable
  • You need complex custom build steps: code splitting, service workers, advanced asset optimization, custom Webpack plugins
  • You're integrating with a deployment platform that has a required CI/CD workflow

These are real cases. They're not the 80% of content sites that have a build pipeline by default because that's what developers reach for.

The build pipeline is a great tool for the problems it was designed to solve. A 10-page marketing site is usually not one of those problems. If the site is going to be updated by a content editor and serve static pages to visitors, the overhead of a build pipeline is a cost with no corresponding benefit.

SleekCMS's site builder is the alternative: the same structured content, the same static output, without the pipeline between them.

Back to all posts