Skip to content
allan.
All work

Bitespeed · Multichannel Marketing for Shopify Brands

The push channel, built end to end on serverless.

BiteSpeed gives e-commerce brands one place to run marketing and support across every messaging channel. I built the web and mobile push notification channel, from the broadcast backend to the mobile SDK.

Push notification service, end to end · AWS Serverless, Node.js, React Native

The product

BiteSpeed

bitespeed.co

A multichannel marketing, sales and support platform for e-commerce brands, spanning WhatsApp, email, SMS, Instagram, website chat and push notifications.

Built for: E-commerce merchants, with a particular focus on Shopify brands.

Stated publicly by the company

  • BiteSpeed states it works with 6,000+ e-commerce brands across 50+ countries
  • The company cites $100M+ in sales driven and 1.5B+ messages sent

One channel among many, and it has to behave like the rest

A multichannel platform is only as good as its weakest channel. A brand composing a campaign does not want to think about whether push behaves differently from email - it should schedule, target, send and report the same way.

Push has its own awkwardness underneath that expectation. It runs through vendor infrastructure you do not control, it is subject to delivery mechanics that differ between web and mobile, and a broadcast means a very large number of sends in a very short window rather than a steady trickle.

What I built

I built the web and mobile push notification service end to end on AWS Serverless: the broadcast path that fans a campaign out to its audience, and the webhook handling that brings delivery and engagement signals back, both sized for the burst shape that broadcast traffic actually has.

Push vendors do not agree with one another, so I engineered multi-vendor configuration handling to keep those differences out of the rest of the system, along with scheduled template fetching so campaign content stayed current without a person triggering it.

For the mobile side I wrote a React Native SDK for FCM push, so the channel worked inside the Shopify mobile app rather than only on the web.

I also built a Lambda authorizer covering the REST and Lambda surface, so authorisation was enforced in one place rather than reimplemented per endpoint, and a tool that automated domain verification for email broadcast - a step that had been manual, slow and easy to get wrong during onboarding.

What I would do differently

This was infrastructure work where the interesting failures are all operational rather than logical. I would build the delivery observability first next time: when a broadcast underperforms you want to know within minutes whether it was the audience, the vendor or the payload, and that is much harder to add afterwards.

The multi-vendor abstraction was also drawn after the second vendor rather than in anticipation of it, which is the right instinct but meant one migration that a slightly later abstraction would have avoided.

Delivered inside this engagement

  • Built a Web Push and Mobile Push Notification service end-to-end on AWS Serverless, handling broadcast notifications and webhooks at scale.
  • Engineered multi-vendor configuration handling and cron-based template fetching for broadcast messaging.
  • Created a React Native mobile SDK for FCM push notifications on the Shopify mobile app.
  • Developed a Lambda Authorizer securing all REST and Lambda API endpoints.
  • Built a Postmaster tool for automated domain verification in email broadcast workflows.

Stack

AWS LambdaServerless FrameworkReact NativeFCMNode.jsCronREST APIsShopify API

Next case study