DEV Community: Francois Lanthier Nadeau

18 Hand-Picked JavaScript Podcasts in 2021

Francois Lanthier Nadeau — Thu, 01 Apr 2021 18:34:12 +0000

If you're a frontend developer, you're always looking to learn and stay updated with web dev news.

The fast-paced industry makes it essential, especially when it comes to JavaScript.

Spending all day (and/or night) in front of a screen sometimes calls for a break. But stepping away from your computer doesn’t mean you can’t keep learning - if you're in a learning mood!

It’s 2021, and top-notch podcasts are always a few taps or a shout to voice assistant away!

The medium has probably reached peak mainstream appeal, thus multiplying listening options in the last few years. Even Barack Obama launched his own podcast.

Plus, podcast audio format lets you optimize time spent exercising, commuting, or cleaning up.

Now the tricky part is, you guessed it, finding the right ones.

This article was first published in 2020, and the good news is that I made a brand new curated list of the best JavaScript podcasts for 2021.

Not much has changed since last year, except maybe that Spotify is arguably becoming the biggest player in the podcasting world.

So, I discarded all of the dead or sunsetted ones, then hand-picked and sorted through the rest.

The result? A fresh list of JavaScript-related podcasts you’ll draw value from.

Let’s get to it.

How these podcasts were selected

You’ll find all our best JavaScript podcasts for 2021 below. But first, here's how I built this list.

Podcast selection

Podcast must be still running (at least one new episode in 2021).
Podcast doesn’t have to be strictly JS-related but should cover JavaScript regularly.
Podcast must have social proof (Google/Apple Podcasts rankings, featured in publications, personally recommended by seasoned developers).

List methodology

Ratings and stars are fetched from Apple Podcasts directly.
Description is fetched either from Apple Podcasts or the official site.
Featured episode must talk about JavaScript and be relevant to web development.
Podcast platforms linked to, when available, are Spotify, Apple Podcasts, and Google Podcasts.

Contribution: The more the merrier! We are happy to take requests to add new relevant shows or podcast platforms. Just add a comment below.

JavaScript podcasts for web developers

1. Full Stack Radio 5.0⭐️ - 30 ratings

A podcast for developers interested in building great software products. Every episode, Adam Wathan is joined by a guest to talk about everything from product design and user experience to unit testing and system administration.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

2. Front End Happy Hour 5.0⭐️ - 20 ratings

A podcast featuring panelists of engineers from Netflix, Twitch, & Atlassian talking over drinks about all things Front End development.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

3. Ladybug Podcast. 5.0⭐️ - 16 ratings

We're Emma Bostian, Sidney Buckner, Kelly Vaughn, and Ali Spittel - four seasoned software developers working in different sectors. Since there's a major lack of technical podcasts out there, we've decided to start one. Just kidding -- there's already a ton! But, we wanted to add our voices to the space and share our experiences and advice. We'll have great discussions around how to start coding, the hot technologies right now, how to get your first developer job, and more!

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

4. HTTP 203 5.0⭐️ - 1 rating

Surma and Jake talk about whatever's going on in the world of web development.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

5. Purrfect.dev 5.0⭐️ - 1 rating

Purrfect.dev is a development podcast made by developers for developers. Learning how to be a developer is hard, Purrfect.dev will show you how to grow as a developer bit by bit.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

6. That's my JAMstac‪k 5.0⭐️ - 1 rating

That's My JAMstack! is an interview podcast outlining various developers' methods of utilizing the JAMstack.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

7. The Vanilla JS Podcast 5.0⭐️ - 1 rating

A show about JavaScript for people who hate the complexity of modern front‑end web development.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

8. ShopTalk 4.9⭐️ - 478 ratings

A live podcast about front end web design and UX.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

9. Web Rush 4.9⭐️ - 37 ratings

Dive into JavaScript and Web development stories with hosts John Papa, Ward Bell, Craig Shoemaker, and Dan Wahlin.

A weekly podcast where we tackle the challenges facing Web developers today and invite expert guests on the show to share their experience solving concrete problems while building real Web applications. Listen for practical insights and honest talk about the topics you are facing today, with Web Rush. Sponsored by AG Grid and Nrwl.io

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

10. iteration 4.9⭐️ - 15 ratings

A podcast about development and design. We do our best to be code-agnostic but we talk a lot about Rails, JavaScript, React, React Native, design, business and startups.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

11. JavaScript Jabber 4.9⭐️ - 7 ratings

Weekly podcast discussion about Javascript on the front and back ends. Also discuss programming practices, coding environments, and the communities related to the technology.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

12. Syntax - Tasty Web Development Treats 4.8⭐️ - 107 ratings

Full Stack Developers Wes Bos and Scott Tolinski dive deep into web development topics, explaining how they work and talking about their own experiences. They cover from JavaScript frameworks like React, to the latest advancements in CSS to simplifying web tooling.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

13. Jamstack Radio 4.8⭐️ - 13 ratings

A show all about the JAMstack, a new way to build fast & secure apps or websites.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

14. CodeNewbie 4.5⭐️ - 27 ratings

Stories and interviews from people on their coding journey.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

15. JS Party: JavaScript & Web Dev 4.5⭐️ - 6 ratings

Your weekly celebration of JavaScript and the web. This show records LIVE on Thursdays at 1pm US/Eastern time. Panelists include Jerod Santo, Feross Aboukhadijeh, Kevin Ball, Emma Bostian, Nick Nisi, Divya Sasidharan, Mikeal Rogers, Chris Hiller, and Amal Hussein.

Topics discussed include the web platform (Chrome, Safari, Edge, Firefox, Brave, etc), front-end frameworks (React, Ember, Angular, Vue, etc), Node.js, web animation, SVG, robotics, IoT, and much more. If JavaScript and/or the web touch your life, this show’s for you.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

16. Software Engineering Dail‪y 4.5⭐️ - 2 ratings

Technical interviews about software topics.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

*Note: Currated list of JavaScript related episodes in Apple Podcasts, and Google Podcasts

17. Modern Web ⭐️ - No ratings

Modern Web is a podcast that covers the latest news on topics such as EmberJS, ReactJS, AngularJS, ES2015, RxJS, Functional Reactive Programming, and more.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

18. JavaScript Talks ⭐️ - No ratings

JavaScript Talks / Conferences as Podcasts.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

Bonus: Framework specific podcasts

React Round Up 5.0⭐️ - 6 ratings

A weekly discussion among React developers.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

Views on Vue 4.8⭐️ - 23 ratings

A weekly discussion among Vue developers about Vue and its ecosystem.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

The Official Vue New‪s 4.0⭐️ - 4 ratings

We cover the latest Vue news and tutorials in about 5 minutes. Our goal is to give you the information you need to stay on top of your game as a Vue developer.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

Honorable mentions

Let's finish this list with a few honorable mentions.

The first one has not been active since September 2020 (and probably sunsetted). Hence it didn't make the above list, but it's still valuable.

My JavaScript Story ⭐️ - No ratings

A weekly exploration into the people who make JavaScript what it is.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

The second one is a new show from 2021. Might be too early to say it makes the cut as one of the best JavaScript podcast, but it doesn't make that not worthy of a listen.

JavaScript Jam ⭐️ - No ratings

Ishan Anand and Mark Brocato host JavaScript Jam, a podcast for frontend and full-stack developers. Tune in for conversations about site speed, web performance, Jamstack and the future of the Web.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

The last one on this honorable mentions list is a podcast from the Stack Overflow team. Not focused on Javascript, but it's a great resource for everything dev-oriented.

NO. The Stack Overflow Podcast 5.0⭐️ - 1 rating

The Stack Overflow podcast is a weekly conversation about working in software development, learning to code, and the art and culture of computer programming. Hosted by Sara Chipps, Paul Ford, and Ben Popper, the series will feature questions from our community, interviews with fascinating guests, and hot takes on what’s happening in tech.

→ Listen on Spotify
→ Listen on Apple Podcasts
→ Listen on Google Podcasts

Closing thoughts

I hope you find both value and entertainment in the JavaScript podcasts listed above.

Maybe it will even make your next commute (with this world pandemic, probably from your desk to you kitchen) more enjoyable, and educative.

Oh, and if you’re new to the JavaScript world, I highly recommend you check out the following posts:

→ JavaScript Beginner? Start Here (Exercises Included)

→ Reasons Why JavaScript is Omnipresent in Modern Development

→ You SHOULD Learn Vanilla JavaScript Before JS Frameworks

→ Open source list of resources to learn vanilla JavaScript - GitHub

Happy listening/reading/coding! ✌️

If you've enjoyed this post, please take a second to share it on Twitter.

The Bootstrap Jamstack: How Indie Players Compete

Francois Lanthier Nadeau — Thu, 17 Dec 2020 15:06:14 +0000

Jump to video version of this post. 🎥

Hey, I’m Franck. 👋

I run a developer-first e-commerce solution, and I try my best to grow a healthy bootstrapped company. It’s called Snipcart, and we’re based in beautiful Québec.

Our product is part of the Jamstack ecosystem. If you don’t know what that is, no worries. There’s a cool intro here.

In a nutshell, “Jamstack” is a modern, frontend-centric way to develop sites and apps. It focuses on decoupling backend from frontend, lowering maintenance and hosting costs, pushing static assets through CDNs, edge computing, and using JavaScript and APIs for everything dynamic. Big players include Netlify, Vercel, Contentful, and many others.

Some indie companies I look up to in the space are DatoCMS, Fathom analytics and Statamic.

I’m seeing lots of VC-funded businesses shining, but I’d love to see more bootstrappers alongside us.

In this piece, I’ll show how independent players can build, compete, and grow in the Jamstack ecosystem. I’ll include real-life examples from the Snipcart team and other cool products.

Industry funding overview

When building businesses, there are often two commons paths for your success model:

Bootstrapped companies focus on lifestyle and profitability.
VC-backed companies focus on growth and valuation.

Things aren’t so black and white anymore. Alternative funding solutions like TinySeed, Indie.vc, and Earnest Capital are making noise. Their nuanced approach deserves a post in itself.

Let’s take two categories: e-commerce and headless CMS. I had wondered what the ratio of bootstrapped vs. funded was for these. So I took a look:

Funding abounds in this Jamstack category. Snipcart is one of the only e-commerce players that made it past five years without funding.

Here, the ratio appears more balanced. Why? I think e-commerce, as a product category, involves more inherent complexity.

Headless CMS must handle APIs, data storage and retrieval, plugins, permissions, integrations, previews, etc. That’s a lot.

But e-commerce solutions must handle most of the above plus tax management, shipping and fulfillment, emails, payment processing, refunds, security, discounts, multi-currencies, etc.

E-commerce is also closer to the money. The complexity it addresses touches more critical parts of a user’s life than a CMS: security, identity, revenue, etc.

Trying to solve for e-commerce might be harder, pushing teams to untie some knots through funding. What do you think?

I quickly put together this Google Sheet. If you want me to update it, drop a comment, or send me an email. I might spin this into a cuter microsite—not sure yet!

A word on venture capital

Most of us have seen the loud Basecamp/37signals vs. VCs battle unfold over the past decade. It has, for better or worse, painted a very adversarial picture of the startup ecosystem.

The boring reality is that venture capitalists aren’t as evil as some factions of the bootstrapped community claim. They are agents inside a flawed system with weird incentives and dynamics.

Some companies require wide, horizontal adoption across multiple markets—think infrastructure. The more you’re in that position, the more likely you’ll need VC money to succeed. Netlify couldn’t have worked out the way it did without that kind of funding.

The vital distinction peers helped me realize is that the notion of “winning” differs drastically on the VC and bootstrap path. An entrepreneur’s values and ambition will dictate which kind of success they want to achieve. And that’s fine. Here, I’ll just be spreading the gospel that resonates best with me.

Why bring Jamstack & bootstrapping together?

We see indie communities in SaaS popping up all the time: Startups for the rest of us, Indie Hackers, etc. There's a reason for that: some people don't want to build companies inside the VC model's incentive and pressure structure.

Raising money is a rollercoaster of emotions and intensity. It ultimately offers two paths of success: get acquired or go public. Before that, "success" is exiting a round for investors. You have people putting in money just to leave the company as soon as they can. When you put it like that, it does feel odd, right?

The Jamstack ethos is filled with values we also see in the bootstrapped community:

Independence 💃

In Jamstack: freedom from monoliths, giants, incumbents, tools with poor DX.
In bootstrap: freedom from corporate lifestyle, 9-5, boredom, location.

Keeping things small 🌱

In Jamstack: no need for big architectures, hefty installs, heavy downloads.
In bootstrap: no need for hundreds of millions in revenue, hundreds of employees, tens of thousands of customers. No need for excessive spending on vanity marketing.

Price consciousness 💸

In Jamstack: no need to pay for a bunch of plugins, extravagant hosting, and maintenance. You can also rely on many free open source tools.
In bootstrap: you gotta eat! Budget is limited, so spending wisely is extra essential.

Performance sensibility 🏎

In Jamstack: focus on critical user-centric metrics (FCP, TTI, etc.).
In bootstrap: focus on critical business-centric metrics (profitability, churn, LTV) and human-centric metrics (happiness, sleep, financial comfort, free time, etc.).

How can independent Jamstack players compete?

Cool cool, but I can’t compete with the Netlify, Contentful, Shopify in the space. They raised many millions! Hundreds of people work for them!

Yes, you can. Others have done it. We have done it.

The trick is in how you go about it!

Taming long-tails

When you’re bootstrapped, your economic incentives are drastically different from VC-funded businesses. They need market shares, steep growth, PR attention, multiple acquisition channels. You only need a small community, one sustainable acquisition channel, and enough customers to breakeven.

Big players will often go after broad problems: Shopify wants to empower the whole world to sell online. Snipcart only wants to help a few hundred devs build better e-commerce stores.

You see, the pains you solve with your product can be much more specific than bigger companies.

I've got a parallel for you. If you're familiar with SEO (Search Engine Optimization), the term "long-tails" will ring a bell. When trying to drive organic traffic to their site, people often target very high volume keywords right away. Think "headless CMS". But the competition is super strong for such head terms. Big sites with high authority are battling on these SERPs (Search Engine Results Page).

On the other hand, countless keywords are embodying narrower search intents out there. They have lower search volumes, true. But they are much easier to rank for, PLUS they come with more precise needs to solve—"how to read JSON files inside my Svelte app".

Leveraging radical transparency

Bootstrappers can’t hide behind corporate structures and policies. They are the business.

It may feel scary at first, but you can turn this into an advantage using transparency and humility. People like to do business with people! That fact hasn’t changed in centuries.

So embrace your smallness and personality inside your brand. Tell us your life story on your about page. Share the struggles of building your business publicly. Be warm and kind when dealing with customers. Tell jokes. Sometimes, being the only is better than being the best.

All of that will foster proximity with your customers, which in turn will increase loyalty and word-of-mouth.

Building an audience first

If you’re intent on creating a business to solve a problem, chances are you know a thing or two about said problem. You can share that knowledge and experience before you even start building.

Adam Wathan and Steve Schoger have done similar things throughout different projects. They shared design tips on Twitter years before publishing paid projects like Refactoring UI or Tailwind UI.

Or take developer Shawn Wang, who has been learning in public and sharing lessons for many months before launching his Coding Career Handbook.

Many bootstrappers also share their early journey through podcasts, like Jon and Justin with Transistor, or Ben and Derrick with Tuple and SavvyCal.

Cushioning initial risks by launching inside an agency

If you’re already working inside a web dev/design agency, there are cool opportunities to consider.

One I like: leveraging a client case to build—and pay for—your MVP. That's how we got started with Snipcart. We were upfront with the client about it: we'd make them a custom solution to circumvent their e-commerce challenges but would also re-use some of that code to build something ourselves. We gave them a discount and free usage + priority support for life.

TakeShape, the headless CMS, followed a similar path early on.

Doing initial product work inside the agency also lets you move faster, without administrative red tape. Once traction kicks in and product-market fit is on the horizon, you can slowly branch out. Your “side product” can then become its own company.

Picking a fight (if you’re a fighter)

Ugh, fights. Feels like they’re all over the Internet these days. We’ve sure had our fair share of it with the recent WordPress vs. Jamstack one, hehe.

Still, if you feel like you’ve got that kind of energy, it’s a good way to help grow a bootstrapped business.

First step is often choosing a nemesis: legacy solutions, category giants, specific competitors, or industry trends. You pick your Goliath, put on your David shoes, and start slingin’!

The recent Basecamp/Hey vs. Apple fight is a good example here.

Folks at Fathom analytics have also done a great job at fighting for a cause: privacy. It appeals to potential customers’ strong values, enabling the creation of more solid bonds between business and audience.

When you target the bigger guy, you can use their clout and traction (and their known pains) to fuel your growth:

X is great but s*cks at THIS. We do THIS much better—try us!

Open-sourcing first

That’s another popular one in the Jamstack space.

You’ll see many CMS offering a free, open-source version of their software. They build community and traction around this, then offer a paid, hosted version, for instance. Ghost has done that.

Other things you can sell around your free offering: support, integrations, plugins, related products.

You can also invite the community to support you with sponsorships and donations. It can, for sure, absorb some of the early expenses you'll face when building your bootstrapped product!

Going first

Many tools and frameworks aren’t “Jamstack-ready” yet.

There's an opportunity to go first here. You can build Jamstack-specific products (plugins, APIs, integrations, frameworks, etc.) around or on top of existing tools:

Gridsome lets you create better Jamstack sites with Vue.js
JungleJS helps you build static sites with Svelte
Udesly lets you convert your Webflow site to Jamstack
Strattic enables static generation of WordPress sites

Betting on integrations

I’ve been diving into the Jobs-to-be-done framework recently. A useful concept that stuck with me is knowing where your product ends and another one begins.

That mental model is useful when bootstrapping. Ask yourself: what platform do people love except for X, or but they don’t do Y. These are opportunities for you to broadcast to an existing user base that your product can start there.

On the flip side, you can also ask yourself: what tools do X better than my product? If you find compelling answers to this question, you might want to start integrating more tightly with these! Integrations let you profit from overlaps in audiences, plus they augment your feature set.

In many cases, they also let you offload customer acquisition to existing marketplaces (think themes or plugin repos).

Meet successful independent Jamstack players

I hope that profiling these awesome companies will inspire many others. Something these businesses all share:

They’re all players in the Jamstack space (and others)
They’re all profitable
They’re all bootstrapped

Let’s see which ways they chose to compete.

DatoCMS

Cool facts:

5 people team—comparable products hire 100+ people.
over 1M ARR
over 1500 paid customers worldwide
Vercel chose DatoCMS to manage content for Next.js conf.

Competing using:

Radical transparency: product journey retrospectives and proximity w/ agency clients.
Agency launch: LeanPanda in Italy birthed what became DatoCMS.
Betting on integrations: impressive marketplace of integrations.

While researching this post, I spoke with founder Stefano Verna. Interesting tidbits from our conversation:

For us, going bootstrap means being able to give your own definition of success, enjoy the journey, guarantee your customers a long life for your product and focus on a minimal and self-sustaining lifestyle and business.

Today DatoCMS is made up of 5 people. We are a perfectly oiled machine that produces an absurd amount of value. It is literally impossible for us to believe that products that are absolutely comparable to ours have teams of +100 people. All I can think of is "there must be some inefficiency somewhere" :)

[…] for those who have a technical team like us, I would suggest working hard on third-party integrations, so that you can lean on the shoulders of the giants and let them do marketing and customer acquisition for you.

We have 1,600 customers all over the world, big names using us, stable and regular growth of 6% month-over-month, $1M ARR, we release a new, big feature per month. Just a few weeks ago Vercel chose us instead of the other 65 VC-based competitors for its 60,000 registrants Next.js Conf.

Fathom

Cool facts:

2 people team
580.8% revenue growth in last year
over 1,000,000,000 page views tracked

Competing using:

Radical transparency: the founders (Paul and Jack) are ultra-transparent on their blog, podcast, social media, and customer support.
Audience first: Paul Jarvis had already written Company of One. Jack Ellis had already been teaching Laravel.
Pick a fight: they arguably have The Big G has a nemesis, and wave the flag of privacy and open web super high.

Interesting tidbits from my email exchanges with the founders:

We built it slowly and iteratively, so at the start we spent less time as it was making less money. Now, we are full-time because it makes ample revenue (enough to pay us both a salary and more) - so if we got, say a few million bucks investment, we'd have no use for it.

[…] we have to consider everything from new features to pricing to infrastructure and ensure the maintenance costs of our growth doesn't make it harder to manage in the way we like.

And, we are careful/thoughtful with new features so we don't overwhelm our support channel.

Statamic

Competing using:

Radical transparency: one of the founders shares their journey on this podcast. Definitely embracing the “not the best but the only” w/ brand and positioning!
Open source: The core product is free and open source. The Pro version is paid.
Going first: Statamic was a flat-file pioneer.
Betting on integrations: Huge marketplace.

Interesting tidbits from my email exchanges with Jack McDade:

Bootstrapping let us build the product I wanted, solve the pain points I (and others) had, and do it organically. It certainly is a slower way to grow, but that’s not a bad thing.

Everything simply took longer. But it also gave us the ability to use the product differently and grow it more organically than if we hired a big team and fired up a few sprints. We could do things that didn’t scale, get to know customers closely, and build something that would last a long time.

Statamic is used by Der Spiegel, one of the largest media and online publishing companies in Germany. It runs their largest sites. That’s a pretty big win for a small and scrappy bootstrapped company. Also in similar company: OpenTable, Asana, and Freshbooks.

Snipcart

Cool facts:

9 people team
1M ARR
over 2300 paid customers

Competing using:

Long-tails: focus on smaller audience (devs, no enterprise). Only solving parts of e-commerce problem—not all of it.
Radical transparency: blog posts, honest, no-BS customer support, interviews
Agency launch: client project for MVP. We used à la carte agency resources that we later refunded.
Going first: we were arguably the firsts to market stack-agnostic e-commerce directly to developers.

☝️ Tooting our own horn here, but I believe there are things to be learned from our journey to 1M ARR. The one lesson that hits home, especially as we scale a bit, is this:

Saying no—and yes—to the right things is hard.

All of the above are examples, not models. You need to scan your reality and come up with growth models that resonate with it. Occasionally, I mentor startups. I often advise leveraging their constraints. If you’re not a fighter, don’t pick a fight. If you don’t have an agency close to you, don’t go out of your way to find one. You get the idea.

The Bootstrap Jamstack - Video

Closing

The Jamstack community is one of the more dynamic and positive ones I’ve seen. I’m thankful to be a part of it.

If you, too, want to join in the fun, I urge you to. You can start by entering a Slack, a group, or by learning more. If you, too, fall in love with the ecosystem, then come back to this post and maybe start to build a new independent product. I’ll be there to help in any way I can.

I’d like to offer fellow bootstrappers some heuristics I have come to embrace:

Most markets aren’t winner-take-all. Solve a problem differently, or different parts, and you’ll generate real value.
Success models are inspiration, not recipes. Lean on your strengths and into your constraints. You’ll create your own authentic growth model.
Millions in funding aren’t a pre-requisite to succeed in the Jamstack. Sustainable businesses can be built slowly, grown organically.

If any of you are interested in creating a community for the bootstrap Jamstack, let me know. I have ideas (and domain names 😅).

EDIT: I put together this site real quick, using this DatoCMS/Hugo starter. Needs improvements, but what do you think?

I’d love to hear your thoughts in the comments or on Twitter.

Cheers! 🙇‍♂️

A Developer's Guide to Headless E-Commerce

Francois Lanthier Nadeau — Thu, 24 Sep 2020 19:00:37 +0000

Let’s talk about modern e-commerce.

Many call it Jamstack or headless commerce. They’re umbrella terms—helpful yet confusing.

I try my best not to indulge in cynicism, so I won’t label them buzzwords.

This post will unpack these concepts. It will also contrast traditional approaches with modern ones.

My goal is to help you better navigate e-commerce as a developer in 2020.

By the end of this post, you’ll be able to make better decisions when it comes to picking an e-commerce stack.

Full disclaimer: I’m the CEO at Snipcart, an e-commerce solution for developers. I’ll talk about all platforms, including ours. If your next online store ends up being powered by Snipcart, great. If not, no biggie. We’re independent and profitable, so we have the luxury of recommending other solutions. I do it all the time. ✌️

What is headless e-commerce?

The classic definition:

Headless e-commerce is the separation between the frontend and backend of an e-commerce application.

Yet I’ve seen some pretty weird definitions on the Internet, like:

One hallmark of headless [e-commerce] is the use of APIs, experience managers, and tools such as Heroku and Mulesoft as well as the importance of IT partners.

I’m appalled at Google for ranking such un-sexy, inaccurate definitions at the top of the search results.

The adopters of headless commerce are typically bigger enterprises with larger development and IT teams along with a DIY attitude.

DIY attitude, maybe. The rest? Not necessarily.

This makes sense, as the custom programming needed to produce and build a separate front end and back end reliably can take a major investment of development hours. These businesses often have months-long development queues and ambitious creative and marketing teams that are eager to rapidly test new designs, copy, and templates on the front end.

For larger enterprises with legacy codebases, of course, this can be time-consuming. But it’s important not to “gate” headless commerce platforms for the enterprise. Resources to get started quickly with a decoupled e-commerce approach abound.

On a side note, let’s recognize that e-commerce needs a head: product views, shopping cart, checkout experience. And a good-looking one at that! When we say “headless e-commerce,” we really mean:

Separating the product and order management from any customer-facing frontend.

But, granted, “headless” has become an umbrella term (like Jamstack), where we try to separate concerns, focus on fast frontends, and make e-commerce data “portable.”

In other words, making sure your key e-commerce data is decoupled from a single frontend touchpoint so that it can be displayed on any frontend touchpoint. An ambitious headless e-commerce project could be pushing product data anywhere: social, mobile, IoT, POS, smart screens, etc. Cue the omnichannel concept, yadda yadda yadda.

For now, JSON seems to be the most universal format to send information over the web, regardless of the arrival point. So you’ll see a lot of it in the space.

Definitions aside, “Am I doing headless e-commerce or not?” is the wrong question.

The right question to ask:

“What are my business and technical requirements for this e-commerce project, and which solution answers them best?”

For instance, maybe you won’t need to push your e-commerce data on all of these customer-facing touchpoints. A later section of this post, titled, “How to choose an e-commerce solution?” will help you answer that question.

And why go headless?

Because SPEED, my friends. Jokes aside, separating your backend from your frontend gives you control. Control over web perf, yes. But there’s more. Let's see why the headless path can be better than some traditional e-commerce routes:

High degree of customization & flexibility for developers.

You can create custom experiences to match your brand, not generic, template-ish ones. Is it impossible to customize your Shopify/Magento/BigCommerce store? Absolutely not. But you'll never get the same freedom to build thoughtful UX as with modern frontend frameworks. And I'm guessing you want your store to stand out in this dense digital jungle, heh?

Portable backends, data, and data structure.

No dependence on massive, restricting infrastructures. This allows you to stay competitive with your frontend without being locked inside turnkey or coupled solutions.

Better multi-platform shopping experiences.

Mobile, desktop apps, IoT, web, name it. Using a headless CMS allows you to pick the best frontend tooling for every platform/device. Adapting and scaling your business is much easier when your backend can output whatever you want, wherever you want.

Develop with the Jamstack.

Faster, more secure, and cheaper websites & apps are the central promises of the Jamstack. But in reality, the Jamstack’s sexiest offering is this: a deliberate, creative, and strategic development experience for modern developers.

Okay, so… what did people do before headless? They developed with traditional, monolithic architecture. Monoliths. Giants. All-in-one. You get it.

Here, a single solution handles everything: not only the e-commerce side but the site-building too. From backend (product & order management, customer accounts, etc.) to frontend features (store templating, mobile development, etc.), everything you do is dictated by what the software allows. It can still be a powerful tool—no debate here—providing merchants a complete, end-to-end e-commerce experience.

We’ll get into some examples a bit further down.

E-commerce in 2020

It’s a beautiful mess. There are a lot of solutions and use cases.

I’ve left out “payment processing” on purpose, as all e-commerce solutions depend on external payment gateways to do so. Yes, even Shopify.

If you’re not dwelling in this space on the regular, it can get real confusing.

What can modern e-commerce solutions do for you?

There are roughly five types of feature set when it comes to e-commerce tools. I’ve listed them from general to specific. Further down, I’ll map all feature sets to types of solutions. We built a simple web app with filters to do so.

Website design
- Picking a website theme
- Choosing its colors
- Injecting branding
- Drag and dropping sections
- Customizing CSS
Content management
- Creating and managing a blog
- Publishing some pages
- Uploading and editing media (images, video)
- Updating content across the site
Product management
- Creating products (physical, digital, recurring)
- Defining product options
- Managing SKUs and inventory
Cart & checkout
- Adding items to cart
- Selecting quantities and options
- Applying discounts to orders
- Defining order custom fields
- Collecting billing, shipping, payment info
- Processing orders online
- Confirming orders and follow-ups
- Designing cart & checkout
Store management
- Managing and tracking orders
- Analyzing and updating customers
- Setting up shipping rates
- Setting up tax rates
- Creating discounts and promotions
- Retrieving abandoned carts

What types of e-commerce solutions exist today?

I tried to put some names on “categories” of solutions. I think it helps frame them inside a project’s narrative. If you don’t like the terms, leave a comment below, or tell me about it on Twitter.

Let’s see what your main options are here. I’ll also throw in some headless e-commerce examples. If you want actionable tutorials, we have dozens.

The Monolith (all in one)

→ All-in-one, turnkey solutions to build and run online stores.

Content management
Product management
Store management
Cart & checkout experience
Website design
- Example: Shopify (coupled)
- Example: BigCommerce (coupled)
- Example: Magento (coupled)

Your grandma could spin up a store with these platforms. And I mean that as a compliment to both the tools and your grandma. They’re very quick to get started, but somewhat limited when it comes to customization or fine-tuning. They often come with a gazillion ready-made integrations, which is nice.

The Add-On

→ Cart and checkout layer to enable sales on existing sites. Includes back-office for store management.

Product management
Store management
Cart & checkout experience
- Example: WooCommerce + WordPress (coupled)
- Example: Snipcart + Nuxt.js + Sanity (headless)
- Example: Shopify buy button + Gatsby + Strapi (headless)

If you’re a big WP fan, the first example might be all you need. Simple + “free” (paid addons). Resisting the urge to comment on WordPress.

I’ve added a headless CMS to the stack examples for the other two. Useful if you have e-commerce managers who are not coders working on the site. Snipcart has a standalone JS SDK coming soon that could earn it a dual spot in the “API” category. Will update the post later I guess, hehe (I hope our product owner is reading this).

FWIW, Snipcart and others are also often used in coupled sites. Say a classic Craft CMS site, for instance.

The Storefront

→ Frontend-centric tooling to design fast & performant storefronts. Often PWA-centric.

Cart & checkout experience
Website design
- Example: Shogun + BigCommerce backend (headless)
- Example: Vue Storefront + Shopify backend (headless)
- Example: Front Commerce + Magento backend (headless)

These fine folks have decided to focus on the whole frontend, customer-facing part of your e-commerce projects. If, say, you already have a complete Shopify setup but your storefront s*cks when it comes to web perf, well, you might consider hooking it up to one of these bad boys.

The API

→ Headless commerce API building blocks to create custom online stores. More code involved, more data portability.

Product management
Order/customer management
- Example: Commerce.js + Next.js + Sanity (headless)
- Example: Commerce Layer + Nuxt.js + Contentful (headless)
- Example: Nacelle + Vue.js + Strapi + Shopify backend (headless)

These are the more developer-first solutions. They enable more textbook “headless e-commerce,” according to our initial definitions. Let it be known that many of them offer pre-made “heads” in the forms of starters and whatnot. Also, someone in Australia really wanted me to say Saleor is a cool product in this category too.

The Custom

→ For adventurous developers with unlimited budget. You’re building everything.

N/A
- Example: Next.js e-commerce app connected to Stripe.

I can’t imagine the freaking headaches you’re going to go through, building all of this on your own. But more power to you, you crazy artisan of the web.

There’s an app for [headless & coupled e-commerce solutions]

My friend Max and I created a small web app to filter modern e-commerce solutions by type and features. It’s available here:

→ https://headlesscommerce.netlify.app/

If you’re interested, here is how we built it, using Vue 3 and Tailwind CSS.

Note: you can submit edits or other solutions by cloning the repo and opening a PR.

I kept logos out of it on purpose. I want this to be an agnostic filtering system. There’s no hierarchy in the tiles - order shuffles at every page load. If you feel like it could be improved, please tell me in the comments or via the repo.

I have a raw file where I try to keep track of pricing for different sales levels per solution. If that’s a factor you’d like to see presented in the app, again, let me know. We’ll consider adding it!

How to choose a modern e-commerce solution?

With a thoughtful reflection. Sure, execution is critical. Still, a bit of planning will go a long way here.

Here's what developers should keep in mind when choosing a headless (or not) e-commerce stack.

Which touchpoints do you really need to sell on?
- Selling on many customer touchpoints (IoT, voice, smarts screens, mobile native, social, chat) is very cool. It can add a load of complexity to your project, but some modern API solutions will help you manage it just fine.
- However, you need to think about your audience and your business more than about technology here. How familiar and active are they on a given channel?
How many e-commerce parts are you willing to offload to a third party?
- AKA “what I DON’T want to code.”
- All of it? Don't even bother with headless—use Shopify, coupled.
- Only the frontend store design? Use something like Vue Storefront or Front Commerce.
- Only the cart and checkout? Use something like Snipcart, Commerce.js, or Stripe checkout.
- Most e-commerce back-office "operations"? Add-ons and APIs like Snipcart and Commerce Layer can take care of that.
- None? Let's hope your client has a big budget. Stop reading this and get coding!
How much time and money will you save offloading logic to X solution?
- Of course, you should consider the solution’s price. However, remember that a custom e-commerce store costs zero dollars in solution, but thousands in development. Find the right balance for your budget.
What are the content/store management needs?
- Does the headless CMS or e-commerce solution picked answer them?
  - Think roles, permissions, blog post creation/editing, manual SEO optimization, product management, product variants.
How important is SEO for the merchant?
- Make sure your frontend is easy to index, optimize, and crawl. Consider pre-rendering and server-side rendering if using JS frameworks.
Who's going to work on the project after you?
- Are the tools you're choosing going to scale well and be easily used by other developers?
  - How risky or well-documented is this tech?

It’s okay to take the time needed to answer these questions.

Once you've done so, you should be good to go and start your headless (or not) e-commerce project. If you've only worked with traditional e-commerce platforms up until now, it might look scary, but in the long run, you'll find that the freedom is worth it.

As for your clients? Here's how to sell the Jamstack and headless e-commerce to non-technical merchants.

We also discuss picking tech stacks further in this post.

100 words on Snipcart

I will allow myself precisely 100 words to talk about us:

Snipcart is a low-footprint e-commerce solution for developers. It is made by a friendly bunch of (8) nerds in Québec City.

It provides a small part of the head: cart and checkout. They live in your frontend; cart via JS, products in the HTML. The rest of your frontend? Up to you.

First, you integrate Snipcart into your site. Next, you hand it off to merchants via a hosted dashboard to manage: orders, shipping, taxes, discounts, abandoned carts, inventory, emails, multi-currency, etc.

We offer APIs & webhooks to extend functionality.

Details in this ⚡️ talk (when/when NOT to use Snipcart). /100

Closing thoughts

The key takeaway here?

Headless e-commerce lets you separate concerns better. It increases your responsibility in that it forces you to choose the right tools to bundle together.

It can make your e-commerce data portable and thus your online store more future-proof.

Very similar to the Jamstack.

I will reiterate the invitation:

If you’re confused as to which solution you should pick, reach out. I’m on Twitter, and my email is francois@snipcart.com. We’ll chat, and I promise not to sell you on Snipcart if I think it isn’t a great fit for your project.

Here’s hoping this guide helped you in one way or another.

If it did, could you please share it on Twitter? I’m told that’s where the cool kids hang out these days.

🙇‍♂️

A Nuxt PWA to Improve Québec Citizens' Lives

Francois Lanthier Nadeau — Thu, 16 Jul 2020 20:55:30 +0000

One of the best feelings working in tech?

Using new tools to solve old problems.

When my colleague Gabriel told me how he built a city-wide application with Nuxt.js, I knew I had to write this up.

311 is Québec City’s official communication channel between over 530K citizens and city officials.

Need garbagemen to pick up oversized trash? Hit 311.

Flagging broken street lights and potholes? 311.

You get the idea.

311 receives north of 400K citizen requests per year, and only a small percentage of those are transmitted over the Internet.

Historically available via dedicated phone numbers, the platform has slowly made its way to the web. But like many other public instances, it’s been plagued with inefficiencies.

“Recent” advances in web development opened heaps of new possibilities, which eventually exacerbated said inefficiencies on the current platform:

For citizen users

No mobile version
Lack of mobile-first functionalities—camera + geolocalization
Painful latency on mobile connexions
Difficulty uploading files (images, videos)
Tiring user experience—click fest
No offline capabilities—distant areas, intermittent connexions

For city officials

Lack of cross-platform support
Tech stack lock-in
Difficulty maintaining current solution
Overhead for multi-lingual content management
No push notifications for warnings & follow-ups

Spektrum (Snipcart’s mother agency) was tasked with improving the 311 experience of both citizens and city officials.

Why Nuxt?

Good question.

Well, why the need for statically generated content in the first place?

Cross-platform support.

Here’s Gab with details:

To limit client costs and offer a solid mobile UX, I needed to be able to embed 100% of this app in Cordova. Traditional web apps in .NET, Ruby, or Python require a server to deliver their content. But a static website lives on its own.
I must admit, though, that picking the right static generator was a bit… stressful? I mean, there are literally hundreds of them.

That moment when you need to pick a tech stack for your whole city.

At Snipcart, our team has tried dozens of static site generators. I remember Gab playing around with Gatsby in early 2016, before the cool kids got into it.

For 311, he experimented with VuePress, Jekyll, and Hugo. When I asked him why any of these didn’t make the cut, he told me:

Most of these SSGs (Static Site Generators) are kick*ss programs. But I needed dynamic and SEO-friendly features they were lacking. As a more extensive “framework”, Nuxt had everything I wanted.

So why Nuxt over Next, you ask? Simple: both Spektrum and Snipcart are now working with Vue, a lot.

It was only natural for Gab to keep using the tools he loved.

Vue is also a grassroots, independent initiative we prefer supporting.

If you want more info, Gregg Pollack breaks down the why of Nuxt wonderfully here.

For now let’s have a closer look at how Nuxt specifically helped for this project.

We’ll cycle through project goals and past-pains to do so:

Supporting cross-platform

Pains to solve:

Lack of cross-platform support

Cross-platform development can be (too) expensive. To limit tech and $ overhead, Gab worked with Cordova.

By allowing us to generate the app statically, Nuxt makes it easy to use simple HTML/JS/CSS files and push them through Cordova. The latter then allows us to easily push native-like versions of the mobile browsers to both app stores (Android/Apple).

That way, we avoid making the City (and let’s be frank: its citizens) pay for one whole web app and two native mobile apps.

Building the two mobile apps with Cordova is rather simple. All of the app data is located inside a config.xml file. It contains all configurations the native app projects will be re-using. At its core, the file looks like this:

<?xml version='1.0' encoding='utf-8'?>
<widget android-versionCode="30000" 
    id="ca.qc.quebec.ville.espacecitoyen" 
    ios-CFBundleVersion="0.3.0" 
    version="0.3.0"
    xmlns="http://www.w3.org/ns/widgets"
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:cdv="http://cordova.apache.org/ns/1.0">

    <name short="311">
        311 Ville de Quebec
    </name>

    <author email="311@ville.quebec.qc.ca" href="https://www.ville.quebec.qc.ca">
        Ville de Québec
    </author>

    <content  src="https://311.ville.quebec.qc.ca/" />

    <allow-intent  href="tel:*"  />
    <allow-intent href="sms:*"  />
    <allow-intent  href="mailto:*"  />
    <allow-intent  href="geo:*"  />

    <preference  name="Orientation"  value="default" />
    <preference  name="Fullscreen"  value="true"  />
</widget>

The most interesting properties here are:

id="ca.qc.quebec.ville.espacecitoyen"—unique identifier on Google Play and App Store.
ios-CFBundleVersion="0.3.0" / version="0.3.0" / android-versionCode="30000"—the app’s current versions.
<content src="https://311.ville.quebec.qc.ca/" />—the real PWA & Nuxt magic. Here we order loading of this page’s files, and then make them available offline. Without this line, we’d have an empty app & white page when offline. When the app is online, it re-fetch files on the server only when they’re needed. When the app is offline, it loads cached files.

Finally, apps that can be compiled by Android Studio & XCode must be generated. For Android, these terminal lines do the trick:

$ cordova platform add android
$ cordova build android
$ cordova prepare android

Very similar for iOS:

$ npm install -g ios-deploy --unsafe-perm=true
$ cordova platform add ios
$ cordova build ios
$ cordova prepare ios

And the City now has two mobile applications to submit to Google/Apple app stores!

Creating a mobile-friendly experience

Pains to solve:

No mobile or responsive versions
Lack of mobile-first functionalities—camera + geolocalization
Painful latency on mobile connections
Difficulty to upload files (images, videos)
No offline capabilities—distant areas, intermittent connexions
No push notifications for warnings & follow-ups

Lack of mobile-first functionalities—camera + geolocalization

<div class="youtube-embed" data-video="https://youtu.be/7kHJ4ytnxyI"></div>
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "Nuxt PWA mobile experience (311)",
  "description": "A quick video showing off some of the available functionalities on this Nuxt Progressive Web App (PWA).",
  "thumbnailUrl": [
    "http://i3.ytimg.com/vi/7kHJ4ytnxyI/maxresdefault.jpg",
    "http://i3.ytimg.com/vi/7kHJ4ytnxyI/hqdefault.jpg"
   ],
  "uploadDate": "2020-07-13",
  "duration": "PT0M52S",
  "embedUrl": "https://www.youtube.com/embed/7kHJ4ytnxyI"
}
</script>

With JavaScript powering it, Nuxt makes it easy to access camera functionalities through Cordova’s wrapping. After detecting a native mobile usage of the app, we send a direct call to the device camera, bypassing browser prompts.

navigator.camera.getPicture(
  function cameraSuccess(imageUri) {
    // send image to server
  },
  function cameraError(error) {
    // notifiy error....
  },
  {
    quality: 75,
    destinationType: Camera.DestinationType.DATA_URL,
    sourceType: Camera.PictureSourceType.CAMERA,
    encodingType: Camera.EncodingType.PNG,
    mediaType: Camera.MediaType.ALLMEDIA,
    allowEdit: false,
    correctOrientation: true,
  }
);

These native functionalities enable a better photo taking experience. You get more settings to improve photo quality for example. Such parameters aren’t available when using cameras through browsers like Chrome and Firefox.

No offline capabilities—distant areas, intermittent connexions

A dedicated PWA module for Nuxt makes managing browser caching really effective. Leveraged smartly, these configurations make way for performant offline applications. Here we use Nuxt PWA to create service workers and manifest.json. Basic configs are as simple as:

 manifest: {
    name: '311 - Ville de Québec',
    lang: 'fr'
 }

No push notifications for warnings & follow-ups
Note: this feature is in the codebase, but isn’t publicly available yet.

We handle push notifications with a library injected in the Cordova wrapper. Notifications are thus unavailable to citizens using the app on browsers.

// Library initialization

pushRegistration = PushNotification.init({
  android: { senderID: "---HIDDEN---" },

  ios: { alert: "true", badge: "true", sound: "true" },
});

pushRegistration.on("registration", function (data) {
  // Trigger event to store device identifier

  window.dispatchEvent(
    new CustomEvent("store-device", {
      detail: {
        id: data.registrationId,

        type: device.platform === "iOS" ? "Apple" : "Google",
      },
    })
  );

  PushNotification.hasPermission(function (result) {
    if (result.isEnabled) {
      // Trigger device registration

      window.dispatchEvent(new CustomEvent("register-device"));
    }
  });
});

pushRegistration.on("notification", function (data, d2) {
  // Notify user using alert function.

  // If the application is closed, it will send native notification.

  alert(data.message);
});

Creating an easily portable & maintainable app

Pains to solve:

Tech stack lock-in
Difficulty maintaining current solution
Overhead for multi-lingual content management

The City handles tech projects like many other public organizations: it publishes a call for tenders with specs & parameters. Providers craft and submit quotes including costs, tech stacks, and timeline estimates. City officials, after evaluating and debating, settle on one provider.

From the average provider’s POV, maintainability isn’t mandatory. They build quotes around technologies they master—not ones they know to be scalable and maintainable. From the City’s POV, though, the latter are key: projects often go through a round 2 of development, i.e. a new call for tenders.

So what happens if the former provider is the only one fluent in the City’s project stack? Lock-in. With a technology, but also with a provider. Not good—if said provider jacks up prices, the City has its hands tied, and citizens get the bill.

Now the new Nuxt app stack is quite simple: JavaScript (TypeScript), HTML, and SCSS.

These allow the 311 team to improve and maintain the solution without having to learn new languages. And since these are only used for the app’s frontend, changing the backend later on will be easy. The only remaining link between the app and the City’s backend infrastructure is a REST API. Keeping its resources interface will enable simple stack modifications.

Nuxt effectively decouples your files from any type of server-side logic and apps, making it easy to take these statically generated files, and migrate them to another solution later on. So, for the City, hosting the application sources becomes way simpler: they can move all of their static files to any server they’d like (IIS, nginx, Apache, etc.).

Bonjour/Hi! Welcome to Québec

Québec is a bilingual city in a bilingual country.

Hence the need for multilingual support inside the app—in its content management layer, more specifically.

To make sure the Nuxt-driven app could eventually support this, Gab used POEditor.

POEditor is a developer-friendly translation tool.

It works with any type of localization file (JSON,RESX, PO, XML, etc.).

It also uses a language file as source code (JSON, RESX, PO, XML, etc.). Such files are located in a Git repo—hence its appeal here.

Once a translation is ready for deployment, the user hits a button, which triggers a commit to the Git repo. The latter sets off a hook starting a build to the CI (Appveyor, GitLab CI, Travis, etc.). Unit, integration, and acceptation tests roll to make sure translation changes haven’t affected the product’s quality. After that thorough, automated process, translations are deployed live on the platform.

POEditor specifics are out of scope here, but I’ll still leave you with these gorgeous UI screenshots:

Closing thoughts

Jamstack

Public organizations like governments, cities, and NGOs operate under logistical constraints when picking service providers: successive call for tenders, rigid decisional guidelines around specs, budgets, deadlines, etc.

The Jamstack, with its focus on API-driven modularity and static frontends, brings much needed flexibility to this rigid system. The decoupling of building/hosting, of backend data/frontend files, makes it way easier to migrate code from one provider to another, from one stack to another.

I encourage developers and agencies to consider this development paradigm more seriously.

Here is a primer on the Jamstack.

Nuxt.js

After meeting the founders in Toronto and chatting with my team, I think it’s safe to say Nuxt is going places. That funding announcement will help! Some cool stuff to expect:

TypeScript as first-class citizen
Better community modules & sample apps (e.g. auth-module could be improved)
Stronger, larger community
Becoming the “go-to framework” for complex Vue.js applications

For those interested in getting started with Nuxt and PWAs:

Happy coding! 🙇‍♂️

Making Peace with Process: A Bittersweet (Ongoing!) Release

Francois Lanthier Nadeau — Tue, 22 Oct 2019 21:55:15 +0000

We released Snipcart’s v3.0 today. 🚀

The Product has officially been Hunted:

https://www.producthunt.com/posts/snipcart-3-0

I’m proud of our team, but it’s a bittersweet release.

This train of thought started as a Twitter thread, but I decided to turn it into a blog post for posterity.

We first started talking about the v3.0 in late 2017. Back then, we boldly claimed we’d ship it by the end of 2018. Clearly, that didn’t happen.

Let’s explore why.

For those who don’t know us, it’s worth noting that we are a bootstrapped business. There is a particular twist to our foundation story—we launched inside an agency. It de-risked our first year and gave us plenty of “pay later” dev and design hours. Still, no VC millions ever landed in our bank account.

Cowboy days

During the first years, our operations team consisted of roughly two developers and myself. They wrote code. I did marketing stuff.

We worked side by side, every day. Often on weekends. Communication and decision-making were super easy: when you don’t have a lot of bandwidth, you can’t start dozens of features. You try to crunch through the essential.

From 2018 to 2019, we went from three to eight team members. We had a rough rule of thumb: every +5K MRR or so; we’d try to hire a new person. We didn’t quite respect that rule for our last two hires, but anyway.

I naively thought that doubling our size would more than double our output and revenues. Boy, was I wrong. 🤦‍♀️

See, in startup absolutes, 3 → 8 doesn’t seem like a big deal. Hell, Shopify hired like a thousand employees this year.

But in our micro, relative context, 3 → 8 is a pretty big deal. It represents a 166.6% 😈 increase in HUMANS—the most lovable and volatile variable in any equation.

We weren’t three tight-knit cowboys anymore. We had parents and freshly graduated students. Senior and junior team members. Distinct personalities and work styles. Different alarm clocks.

We were becoming a… business?

Mamma Management and Poppa Process

As a “cool” indie startup, we were always process and management-averse. I know I was. I always had a problem with authority.

Anyway, we did NOT include Mamma Management and Poppa Process in our new, bigger family. Looking back now, this was a mistake. But it took us months to figure it out.

Wasting eight people’s time and energy costs a lot more than doing so with three people. Quick maths. Operations issues started creeping in. Next thing we knew? We got hit in the face with a few curveballs:

Scattered communications
Unstructured support schedule
Ad-hoc meetings
On-the-fly documentation
Unplanned issues
“Priority” interruptions (I SEE YOU GDPR; HI PSD2)

But the hardest-hitting curveball was an unclear decision-making process.

Being rational human beings with a minimum of awareness, we eventually realized things weren’t great. We were not shipping as much as we’d like to. And that lack of decision-making structure stalled us big time:

No one was calling the shots; there were no clear balls to be dropped.

I call it the shrug emoji period. ¯_(ツ)_/¯

Eventually, we got our shit together. We realized that the layer of process and management we were avoiding could, in fact, act as a protection from these hazards—a shield for business curveballs.

More concretely, we:

Appointed a CEO (me).
Designated + trained a product owner (also me—listen, it’s a small startup).
- Did the whole Scrum exam thing.
- Working on backlog refinement as I write this.
Seriously committed to sprint plannings & reviews.
Structured and planned customer support efforts.
Cut down nice-to-haves for marketing & product.
Set revenue goals and marketing budgets.
Structured vacation + training processes.
- Can’t have most of the team offline at the same time for days.
- Can’t be repeating and freestyling the same stuff every time we hire.

Gotta do what you gotta do!

Product and profits and people and… that’s it.

Slowly, we’re re-focusing the team on product experience.

Over the years, we’ve helped thousands of developers enable e-commerce on all sorts of sites. We became JAMstack champions. We shipped great marketing work. We generated lots of traffic and sign-ups. And that’s all good and well.

But as we start maturing as a company, so must our product. Today, we all agree on a focus that resonates with this:

Improving product experience to boost activation and reduce churn. That’s it.

The “better product” goal is not only better margins but better mornings:

Our customers will prefer waking up with 10x more order notifications from their store.
We’ll prefer waking up with positive product feedback in our inboxes and fun, challenging features to tackle.

So we do it for our customers and ourselves. For the people! 💃

About that Snipcart v3.0 release

All of the above starts with our shopping cart's v3.0. It’s the tip of the spear for Snipcart—offering an awesome, customizable checkout experience.

Here, we even tried our hand at producing a video for this one:

Now for the “bitter” part: the v3.0 currently lacks a few features to get to v2.0 parity. They’re listed in our new documentation. We’re actively working on these, one sprint at a time. 🏃‍♂️

Why release without these features, you ask?

Because we’re proud of what we built, it works just fine! We solved tricky backend puzzles and fun frontend challenges. We stepped our design game up.

At the end of the day, our users deserve a better version of our cart. Releasing it motivates us to improve upon it and harness our new processes to do so. That’s precisely what we’re going to do.

Now let me tip my hat to my wonderful teammates. Your skills and jokes make my work life 10x better, easy:

❤ @couellet
❤ @thatfrankdev
❤ @JeanSebTr
❤ @MathDy24
❤ @josscuette
❤ @geosaa
❤ @VincentGirard
❤ and Michael, who stubbornly refuses to create a Twitter account

Next up on the broader roadmap is the merchant dashboard; chunky piece, can’t wait to get started. Best believe I won’t commit to an ETA here, though! 😅

“Insert inspiring conclusion from new CEO”

It has been a wild ride since we launched in 2013. We helped devs & merchants, worked on a nice SaaS, survived the e-commerce industry.

We made it past the 5 years startup gap of death.

Now, as Jason Fried would say, it’s time to build a business, not a startup.

Got work to do. Franck out. 🙇‍♂️

You can check out Snipcart v3.0 on Product Hunt, or simply sign up. It’s forever free in Test mode.

How We Tried to Chatbot Our Way out of a Support Crisis

Francois Lanthier Nadeau — Sun, 17 Sep 2017 20:34:51 +0000

Has your customer support ever felt like a re-enactment of the Sisyphus myth?

40 opened tickets.

You breathe in, roll up your sleeves: “Hold my coffee mug, I’m going in!”

5 hours later

15 opened tickets.

You self-five yourself for all the issues solved amidst your ad-hoc to-dos. Content, you log out, grab a snack, and go to bed.

Next morning.

40 opened tickets.

“What the #$@&%*!”

A few months ago, support at our SaaS became this shared Sisyphean reality. However hard we worked at it, tickets just… kept stacking up.

I had read about “big startup support horror stories before.

“Jeez, we’re lucky support isn’t such a pain at Snipcart! I remember thinking in 2013.

I used to be convinced it would never be an issue for our small, humble SaaS.

But that humble SaaS scaled a bit. As support intensified, things started to change.

Development velocity plummeted. Marketing initiatives slowed down. Morale dropped a notch. I started understanding why entire products & blogs were built around support.

We had to do something.

After rounds of fruitless investigations, we came up with an idea: build a support chatbot.

Context & expectations

Our gut feeling was that most answers users wantedâ€Š–â€Šespecially technical onesâ€Š–â€Šwere already in our documentation. It was like people weren’t actually reading through it. Now, we knew it needed a little love, but we subconsciously overlooked that fact.

“Why oh why aren’t our supposedly tech-savvy users reading all that info we’ve written for them! did we chant in harmony.

To top it off, we were still hooked on a grandfathered UserVoice plan with sluggish UX.

So our plan was simple:

Switch to Intercom.
Build a chatbot using their API to redirect users to the documentation.

Our expectations:

Use automation and a new system to reduce support efforts and regain development velocity.

Now, we knew chatbots weren’t mature enough to replace our whole support infrastructure. With that in mind, we didn’t try to reinvent the chatbot wheel or inject hardcore machine learning in our chatbot. We just went for the lowest hanging fruit and built what we fondly call “our dumb bot.”

Beep bop beep bop, I’m a bot!

First, we tagged our documentation (a Node.js app) entries with relevant keywords.

Then, we built the botâ€Š–â€Ša webhook handler in Node/Express. Its function was simple: run semantic analysis on the Intercom tickets, match them with relevant entries, and serve them in Intercom.

If the bot didn’t find matching entries, it’d simply greet the user and inform him of an incoming human response.

As you can see, we were doing the typical bot to human handoff. If our dumb bot couldn’t answer, we’d take over. In other words, we simply applied a layer of automation on top of support to improve both ours and our customers’ lives.

Injecting these answers inside the channel we thought customers often used without consulting the documentation was key for us. First, it answered expectations of “good and fast service with valuable answers and not just “please wait placeholders. Second, it actualized the help potential in lingering our static documentation.

You’re probably thinking: “sure, cool stuff, but did it work?”

Well, it kind of did, actually!

Results: making sense of numbers & words

We tracked the following results over a four months period.

Support metrics

6.5% tickets were fully answered by the bot (only human input = friendly goodbye, closing ticket)
10% tickets were partially answered by the bot (quick human follow-up)
83.5% tickets weren’t answered by the bot (human solved issue)

Merging the first two points, we see that our dumb bot got us a 16.5% reduction in support efforts. Which, for the time we spent on it, is great!

Engagement metrics

We tracked behaviour and results in Google Analytics with simple UTM parameters on our bot-suggested links:

5% of leads not engaged with product yet converted into active users following a bot conversation (>2x our usual conversion rate)
Bounce rate on site sessions triggered by bot links was low, around 48%
Users consulted 3.5 pages/session & spent over 5 minutes on site

More importantly, this data tells us that one of our assumptionsâ€Š–â€Šthe “laziness of usersâ€Š–â€Šwas wrong. They either found an answer and kept looking, or looked without finding one. Considering a majority got back to us on Intercom, the latter seems to have happened more often. The insight here? Bot redirections weren’t solving a majority of user issues.

Qualitative results

After focusing on hard metrics, we turned to softer data: conversations. We analyzed over 100 individual threads with users and noted our observations.

A question successfully answered by the bot

A question partially answered by the bot

Idem

A question needing a recipe or cookbook we didn’t have

While this qualitative approach was indeed time-consuming, it was well worth it. It drove us to three conclusions:

Users, more often than not, did try to find answers on their own in the documentation. Many times, the answers they were looking for simply weren’t there, or weren’t easy to find.
There was a clear lack of “structured content in our documentation (cookbooks, recipes, workflows).
The developer-first, flexible approach to e-commerce we champion inevitably increases the complexity and diversity of support questions. And it doesn’t refrain merchants for asking direct questions themselves!

Wrapping up: what happened exactly?

Influenced by the droves of chatbot articles sweeping the web, we opted for an impulsive, trendy shortcut to solve a deep problem. While we often praise focusing on the basics, we did the opposite. That being said, our bot did help us out (and still does). However, this whole episode was a clear reminder to practice what we preach and give a whole lotta love to our documentation.

I like to think our bot, while not having all the conversations we would’ve wanted it to have with customers, at least had a very useful one for us:

DUMB-BOT: Guys, you’re not giving me enough well-articulated information to feed your users. You need to refactor your docs.
SNIPCART TEAM: You’re right, dumb bot. We’ll get on it.

All in all, I’d say we sort of led a half-experiment with this support crisis. A full one would’ve been to refactor our help content (docs) too. But I’m glad we drank the chatbot Kool-Aid a little on this one. Because our chatbot experiment, while it did help with support a bit, also reminded us that:

There are content gaps and architectural issues to address in our docs.
With a product as flexible as ours, some conversations will inevitably needâ€Š–â€Šand benefit fromâ€Š–â€Špersonalized, “human input.

Focusing on these will allow us to better serve interested and active users.
And these people are just vital to a SaaS’ success. They’re way down your conversion funnelâ€Š–â€Šthey’ve taken action, signaled interest, and often started using your product. Either their money’s out in their hand, or already in your pocket. As a SaaS business, you can’t afford to not give these users the care they deserve.

So should you build a chatbot for your SaaS support?

Well… maybe?

I think it’s important to state that 16.5% (our numbers) reduction in tickets can mean a lot of time and money saved. Especially for mid to big-sized SaaS. So a chatbot experiment might be well worth your time, especially if your product usage is more streamlined than ours!

Also if, like us, you host most of your help content, building a bot and analyzing its interactions might help leverage this content and improve it. There are cool platform-specific bots on the market, like Intercom’s Operator, but they require help content to be hosted on the platform’s third party. A few reasons why we prefer hosting it ourselves:

Control branding & visual experience
Control depth and format of content
Improve SEO (bigger site architecture, more thematic authority on-site, inbound links pointing to own domain, technical KW targeting, etc.)

Anyhow, I’d love to hear other thoughts and experiences on leveraging bots for your SaaS or business!

I’ll be following the comments section closely, should you want to participate. :)

If you’ve enjoyed this piece, go ahead, give it a reaction! You can also share it somewhere online. That’d be cool.

This post originally appeared on Chatbots Magazine.