Settling down in a Jamstack world

When I talk about the ample benefits that come from using the Jamstack, I tend to focus on cost, performance, scale, and security. Those things are important, after all. That’s why the Jamstack is compelling to our clients.

Because the Jamstack is a methodology, not a prescriptive set of tooling, its foundation is an open community of people who want to build really good, scalable, stable, and performant websites. At a digital agency, we spend much of our time analyzing our clients’ problems. And the Jamstack provides a massive array of tools we can use to solve each problem directly. However...

The grass is always greener on the other side 

While having a community of people working together to better the whole is fantastic, it’s also exhausting. It means there are new tools to check out almost weekly. And don’t get me wrong, I absolutely love tinkering with new toys. I get to do that as part of my job, and I love that part!

But I have two problems with solving problems using the newest, best tool every time a problem arises.

1. It’s simply not productive. Introducing new processes and tools takes time. Mastery and efficiency are built over time. If we’re trying to run a profitable business, we shouldn’t start from scratch every time.‍
2. We can’t know everything, all the time. With the rapidity at which we’re seeing new tools, there’s simply no way of knowing the best tool for the job because there’s no way to know all the tools available.

Ample’s development team began standardizing on the Jamstack approach for new projects in 2018. We spent the next year or so experimenting with what was available, right around the time the community was starting to explode. 

We tried something new on every project. And not just something little. On one project we’d use Contentful as the CMS. But then an abrupt pricing tier change rubbed us the wrong way, so we tried Dato on the next project. Dato was affordable — Yay! — but came with a clunky UI, and it presented challenges with its associated front-end tooling. Later, on another project, we couldn’t use AWS (because that’s a good idea… can you sense the sarcasm?) so we tried GraphCMS (don’t even get me started).

The same could be said for the front-end. We tried Gatsby, and we’ve also used Jekyll and Middleman.

In that process, we managed to annoy the content team, the design team, the sales team, and the project management team. That’s because we were asking them to learn something new, sell something new, or explain something new on almost every project. It was new new new. The other teams couldn’t find their groove because we kept looking for the best tool to solve every problem.

So it came time to stop. Or rather, to settle down.

But that presents another problem.  If we stop experimenting with new tools completely, we run the risk of falling behind the competition.

To be successful, we knew we had to make some changes. 

How do you settle down in a Jamstack world without becoming obsolete?

Of course, the answer to this question is anything but simple. And while it’s an ongoing exploration, here’s what we’ve done to smooth over the process, all of which are working well for us:

Materials we’ve built:

• A standard set of tools and processes. We have a starting point for all projects — a recommended CMS and static site generator, along with other tooling and third-party services. That gives us a base from which we can pivot as each client presents us with their unique set of challenges.
• A shared library and starter kit. This contains the foundation from which we can build custom solutions for our clients.
• A dev playbook for our team. All of our developers have access to this and are encouraged to contribute to it regularly.

Process changes we’ve made: 

• Questioning our choices. We purposefully poke holes in the decisions we’ve made, which help inform which experiments to run next.
• Carving out time for research and experimentation. For devs who want to contribute and play around with new processes, tools, etc., we only schedule them for 80% capacity. That usually leaves about a half day every week to experiment with something new. 
• Having a recurring team meeting. We call ours Dev Lab. It’s the place we go to discuss what we found out from that experimentation time. It’s also a time for the project leads to come together to share knowledge and solve problems consistently across the team.

The combination of these practices has helped provide a means of settling down in a Jamstack world. They have enabled us to build a foundation on which we can be productive without pulling us away from the cutting edge of the community. We’ve found a way to strike a balance between finding the best tools for our clients while still sticking to the stuff that’s already working.

Does your site need a little developer magic? Or just want to chat about the Jamstack? Let's do it.