The JAM Stack and Pitching it for Ecommerce

Adam Battenburg
Aug 28, 2017 · 4 min read

The Pitch

Imagine a world where there are no servers to be hacked, no wordpress/ magento plugins to deal with, and that your site loads 5 times faster and at a fraction of the cost. Now imagine that all it takes to enjoy this reality is a simple little porting process (it’s been automated for you), but at the end of the day you will be required to abandon a few of those old plugins and the bloat from your past system.

Now those of you that have ever dealt with Ecommerce or large companies will immediately realize that this is a bad idea as those plugins and the bloat are extremely important. I however thought that the benefits might outweigh the cost, and I was determined to see if there was some kind of business (large or small) that could really benefit from the technology.

The Background

As alluded to in the intro, I was pushing the JAM stack for Ecommerce and it was/is going to be amazing. The JAM stack essentially gets rid of the need for a server, and uses API’s to do all the work of providing relevant information to the site via microservices. This has a few advantages, primarily being significantly faster and more secure websites. Furthermore, there are few if any downsides as a number of headless CMS systems have popped up (Dato, NetlifyCMS, Contentful) to allow users to put in whatever information they need — just like wordpress. You no longer have to be a developer using static site generators (ie Jekel, Gatsby, Hugo), but can be just a regular person as long as it was set up for you previously.

My goal was to take all these new technologies, and glue together an Ecommerce API (Snipcart or Moltin) + Headless CMS (NetlifyCMS) + hosting (netlify/ Zeit/ AWS). By heavily customizing a CMS, offering superior design / animations, and keeping costs down I was hoping to convince companies that the significantly faster site would be worth the minimal effort to switch to.

The Market

Initially when starting this project I wanted to target small businesses. Unfortunately, this field is heavily saturated with Shopify and Squarespace already offering really good value and a large ecosystem. Still, I felt I could offer a better product for certain customers, but with Snipcart (ecommerce API) taking 2% percent of all purchases on top of processing fees, it became too difficult of a sell to the average user. Maybe I could convince some that I was the best place to create their business, but no amount of advertising could get me noticed in comparison to these two giants.

Having determined that my Snipcart prototype just wasn’t compelling enough outside of speed (2% in cost is just too much of a deal breaker) I switched to using Moltin. Both Snipcart and Moltin offer a full experience for an ecommerce store, but Moltin has higher ambitions of being a Magento competitor rather than just a checkout cart like Snipcart. This is reflected both in the pricing structure and the backend tools. The goal was to convince average sized companies that my faster, cheaper, and custom designed site could replace whatever they were currently using. I wanted to be a freelance ecommerce store creator, with a compelling reason to switch to my technology.

The Problem

After taking the time to wire everything together and make sure that it would work and have a good Lighthouse score (google tool for site performance), I began seeking out people in the community to see if they would actually want it. I talked to enough people in larger businesses to see that no one was going to take a chance on new tech — especially if they lost all the custom work they had done. While the speed performance and pitch concerning bounce rates really did reel people in, the fact that I would need to support each and every person’s custom requests showed how unruly the project would become. While I probably would have still gone for it, my time working for a property management goliath had taught me that people really do not like to change their custom tools and reports. The SQL scripts/ reports that I would write in an hour, would become central to an entire property management companies workflow and nothing would get customers to use any of the new and better reports that the company was continuously pushing. I wasn’t going to make that same mistake with ecommerce.

Defeat, and the path Forward

After accepting that my 3 and 1/2 weeks of sunk time were a waste, I abandoned my project determining that the tools are just not quite there to offer a convincing solution to large or small companies. I still haven’t given up on the idea of a static ecommerce site, but I’m afraid the tools I mentioned before will never be up to the task for anything complex. Snipcart works best for a site trying to add ecommerce functionality, while Moltin just doesn’t seem to have enough activity in general.

However, Shopify does support both Webooks and have a GraphQL API, so I’m experimenting with using Shopify as a decoupled backend. Using this setup, I could use all the power of Shopify but not have to deal with the Liquid frontend or servers. Look forward to another blog soon if I’m able to get this implemented!

)

    Adam Battenburg

    Written by