The Sales Pitch of Static Site Generation

I have recently developed a static site generator tool called Orison and for this reason among others I have been trying to “sell” people on static site generators; developers, architects, and non technical folks included. For many people the term “Static Site Generation” is synonymous with “small blog”, “personal site”, and “trivial use case” instead of phrases like “enterprise scale” and “unbeatable performance”.

I am very thankful for everything that Netlify has done to popularize static site generation. However I wander if the naming of the term turns some people away. In technical articles, presentations, blog posts, and in person discussion I often use the term “build tool”, “build process” or something of that sort to describe the role that the static site generator plays in the JAMstack architecture.

I am curious as to what you have found. Is there a better term that I am missing? Should we instead focus on rebranding the term “static site generator”? Does it even matter?

Thank you ahead of time for any responses. The subjective human experience is often an under realized blocker to technology and one that I think would be worth discussing.

1 Like

1.- show big customers using SSG
2.- display cool SSG sites. I saw Siteleaf has a gallery with some big agencies listed

1 Like

I suppose I may have been incomplete in my original statement. I think the term “static” itself is misleading. A JAMstack architecture that is dynamically integrated with a CMS is not “static”; it always has the latest content. The only difference being that it renders the HTML for that content ahead of time (when the content changes) instead of waiting for a user to ask for it (server and client side rendering). Despite this dynamism the tool that is used to build the HTML is often called a “static site generator”.

1 Like

Why not just sell it as a ‘JAMStack’ approach, after all that term better encapsulates the ecosystem being deployed, much like ‘LAMP stack’ does.

Taken directly from

A modern architecture - Create fast and secure sites and dynamic apps with JavaScript, APIs, and prerendered Markup, served without web servers.

It also sounds pretty cool when compared to ‘static site generation’.

1 Like

Totally agree that “static” sounds limiting, and doesn’t really describe all that’s possible. In fact, that’s exactly why we created the term “JAMstack”! Of course, the trouble with creating a new term is that lots of people still don’t know what it means. Depending on your audience, though, introducing it as a new concept can be an advantage at times, especially now that there’s lots of content out there to back you up, coming from really well-respected folks across the industry.

In terms of other ways to avoid saying “static,” here are a few strategies I’ve used or have seen:

  • dropping “static” and just saying “site generator” (less of a mouthful anyway :stuck_out_tongue: )
  • server-side rendering handled in advance rather than on the fly
  • “pre-baked” sites and apps (a term that’s been around a while)
  • “decoupled” architecture

Hopefully as we and others keep talking about these things, and as more and more high-profile enterprise projects start using these strategies, our job will get easier. I know that it has certainly gotten easier for me over the last few years. :slight_smile:


This is awesome thank you for the advice! I particularly like the idea of just saying “site generator” - leaving the context of how it is used up to “JAMstack” to explain. Plus server side rendering “in advance” also sounds like a strategic way to describe it - waiting until the users request comes in to render the HTML doesn’t make much sense anyway. It was interesting to read that 2002 article, the fact that 17 years later it is still the defacto standard (in many contexts) to render on the fly instead of in advance is mind boggling.

In any case this is exactly the type of information I was thinking that others may have already thought through, thanks so much!


Those are some great tips @verythorough. And thanks for asking such an interesting question @megazear7. This is a common discussion, particularly around agencies that are trying to sell “jamstack” to their clients.

You don’t need to sell the tools, you need to sell the outcomes and they are different for every actor.

You should emphasize on security, performance, and other meaningful KPI for stakeholders
For developers, they’re free to choose whatever templating they like for the frontend, also they are relieved of maintenance, ship with confidence with a git-based workflow, etc.

Editors can structure their content as they intend and make it evolve effortlessly, of course they need to team with developers.

Adapt your pitch to your target, @philhawksworth has been doing that many times for all kind of audience, but the same way I never sold PHP, I’m not gonna sell the JAMstack, it’s all about the benefits.

Decoupled architectures feel scary to many because they open to a lot of choices and possibilities in an ever growing ecosystem, and people in fact want to know what tool is “best”. The right answer is it really depends on your project and the JAMstack is great for that, far from all the one size fits all era, we’re now entering a carefully hand-picked services and tools to make the best job era.

Not to mention serverless and microservices (here you’ll really have to compare costs, because it’s really pay only for what you use vs rent a full server for life)

1 Like

Awesome, more good advice! Yeah I see what you mean. Focus on the benefits - and that with regards to the audience that you’re speaking to. I will definitely keep all of this in mind. Specifically I think what you said about decoupled architecture, “we’re now entering a carefully hand-picked services and tools to make the best job era” is a good sell for everyone. I don’t know how many iterations I’ve been through with enterprise level clients where it was “use all of these solutions” or switch and “use all of these other solutions”. Explaining the benefit of decoupled architecture might be specifically exciting for enterprise level clients.

IMHO, JAMStack is perfect because anyone who searches for that term will instantly find relevant information. Searching for “site generator” brings up about the least-helpful collect of links one could possibly imagine.

1 Like

I agree that JAMstack is a good term to use, especially in the context that you mention. However JAMstack refers to the whole stack and the question is more specifically what do you call the piece that generates the site, i.e. Jekyll, Hugo, Gatsby, etc. They themselves are not the JAMstack, but just the piece that generates the site. For this piece “static site generator” is often the term that is used and that I want to avoid because of the misconceptions that it carries over into JAMstack.