When tasked with refreshing the brand website of Emergence, an iconic venture capital firm, we realized the framework on which it was built needed a makeover, too. We turned to the JAMstack, a modern methodology that matched the project’s technical goals. In this 3-part case study, we describe the JAMstack, explain what kind of sites it’s best suited for, and share our experience working in the tech stack we chose (including some snags we hit along the way).

They needed a snappy new site — stat.

Our client was in the midst of a growth spurt and their WordPress website was outdated. Hard-coded portions were tricky to update, SEO wasn’t a consideration in the build, performance lagged, and the CMS wasn’t intuitive enough for our client’s team.

As a venture capital firm specializing in future-forward enterprise software, they needed a marketing website that was slick, stable, SEO-friendly, and easy for non-techie editors to use right out of the box. They also wanted the ability for their time-strapped team to publish good-looking, fast-loading thought leadership posts. Simplicity was key.

Could the JAMstack be a viable approach?

Here at Upstatement, we’re tech-agnostic — which gives us the freedom to explore the best possible solution for a situation instead of forcing a fit with a particular tech stack. Our client had outgrown their existing setup, so we set out to look for better alternatives.

We turned to the JAMstack (JavaScript, APIs, and Markup), a modern web development architecture that offers faster performance, higher security, cheaper hosting options, and a better engineering experience.

Here’s how it’s different: With traditional CMSs, on page load, content is queried, generated server-side, and then sent to the user. With a JAMstack, the heavy lifting happens during the build process itself, so the page is already generated on load. Since there isn’t any back-and-forth with a server, sites are easier to deploy, their performance improves, and many of the security risks and maintenance tasks associated with dynamic sites are eliminated. A JAMstack also allows us to decouple our backend from our frontend, giving us more options to curate the correct architecture for our client.

The JAMstack isn’t a cure-all for every situation, though. Extremely large sites don’t benefit from static site generation; the build takes so long that it outweighs the improvement in load time. If your site has dynamic features like comments, search, e-commerce, and forms, a static site makes them harder to implement and adds an extra layer of complexity. In these cases, a traditional CMS is probably a better way to go.

Our conclusion: a JAMstack is best for flexible, static sites.

Based on our technical goals, the size of the client’s site, and their emphasis on simplicity, we decided to migrate our their old WordPress site into a JAMstack. With the new methodology, we’d be able to deliver a marketing site that feels as snappy as a native app — without the overhead of a traditional CMS. By taking away the server-side aspect of the application, we’d remove complexity and our site would become simpler to maintain in the long run.

In Part 2 of this series, we dive into the specific stack we chose for this project, along with its benefits and constraints.

PS: We’re hiring smart, thoughtful engineers at Upstatement. Come build delightful things with us.