Jamstack's community sharing helps developers find the best tools. But changing tools too often will leave clients and other team members frustrated.
Originally posted on www.ample.co.
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...
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.
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 Hygraph (formerly GraphCMS).
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.
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:
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.
The Jamstack approach will help you onboard developers more quickly, and increase your overall efficiency. Ample's Sean Davis will tell you how.
It's hard to choose the right headless CMS when there are so many options. There's one decision you can make before comparing CMS products.
The Jamstack combines the best parts of Web 1.0 and Web 2.0, resulting in secure sites that are easily scalable, well-performing, and lower cost.