We're a Nuxt. js-based Single Page Application (SPA) statically generated and pushed over a CDN globally for the highest speed and availability. This is unusual for e-commerce but allows us to support many products without needing to pre-render and statically generate thousands of pages at build/deploy time, as we faced this issue early in development.

We use Netlify's CDN and their pre-renderer, which handles the fallbacks for SEO and refreshes, as we typically have no server or index files.

We don't have anything fancy for the back end because we plan to scale this with the traffic, but we have MongoDB Atlas for easy scaling and global availability later in growth and a simple EC2 server with PM2. We originally launched this over Docker and ECS, but the tech and cost to run were unnecessary as we weren't planning to scale past one server for a while, so we dropped down to something simpler for the time being.

We looked into several payment providers and were able to explore integration with Stripe and Braintree. We could utilize Strapi lifecycles to keep product catalogs in sync with third-party providers. Allowing product changes to sync to payment gateways easily.

Bootstrapping a platform and startup comes with many challenges, cost, and instability. Despite our strong technical background, building an unconventional social e-commerce platform made these considerations for a small team as prevalent as ever.

While we had experience with several headless CMS services, most were cloud-based, and none allowed us to introduce our in-house business logic close to our data. This flexibility and the simple model lifecycle was the deciding factor.

We chose Strapi as it allowed us to drastically reduce the technical focus on the familiar framework of a complex application and restore our focus on the value-add of our product. Strapi gives us a platform that can scale to meet low or high demand at a cost we control without getting locked into a SaaS product.

Customization-wise, we needed to build a lot of business logic into the controllers for handling orders, accounts, etc. We have a couple of unique endpoints for pulling back specific information like popular artists or products in dedicated endpoints for performance reasons they were better than the standard queries because we had to populate the different relationships.

We added and then removed GraphQL because the performance of the REST endpoints ended up faster. We leaned on a few different plugins for handling image assets with S3 so they could be compressed, batch resized, and converted to the web over our CDN, but no aggressive need for us to get involved with the actual internals of Strapi other than to help temporarily resolve a few bugs that were being actively worked on by your team.

We were able to develop a social commerce MVP within one month that otherwise may have taken six. This acceleration gave us earlier business insights, important opportunities to pivot, and the refreshing ability to focus on the value-adds of our business.

Make sure you understand the responsibility of Strapi and the responsibilities you may still have. Strapi gives a great baseline, but your decisions or poor structure can still impact performance and security. Strapi can't solve the issues of slow database queries if you are overcomplicating your models. Strapi isn't a silver bullet that solves query speed times and security issues; you will still need to be considerate with the development.

Understand this from the get-go!