Blog > Building Olsson Designs: A Journey Through E-commerce Architectures

Olsson Designs device mockups

Olsson Designs is my furniture and home goods company that needed an e-commerce platform to showcase their handcrafted pieces and manage business logic such as inventory, pricing, and content.

To begin the development of the platform I started with some research into a few commercial solutions such as Shopify, Squarespace, and Square.

Ultimately I decided to give Square a shot. Their free tier offered some of the best experiences for managing inventory, finances, and other business logic as well as the lowest payment processing fees (I compared Stripe, PayPal, and Snipcart).

Olsson Designs draft website using Square
Olsson Designs draft website using Square

Additionally, Square’s website builder gave me some useful insight into the key features of e-commerce sites such as product variations, filtering, SEO, and the customer sales funnel.

Their extensive documentation and support for REST and GraphQL APIs also gave me confidence that Square would be a good way to make the first revision of the Olsson Designs website.

Deciding on Strapi + Next.js

After deciding to use Square I now needed to decide which front-end framework to use. Here’s my pros/cons of the three options I considered

Option 1: Static Site Generators (Gatsby/Hugo)

Pros:

  • Lightning Fast Performance: Pre-built static files serve instantly from CDN
  • Security: No server-side vulnerabilities or database attacks
  • Cost Effective: Cheap hosting on services like Netlify, Vercel, or GitHub Pages
  • Version Control: All content versioned in Git alongside code
  • Developer Experience: Modern tooling, hot reloading, and familiar React ecosystem (Gatsby)

Cons:

  • Build Time Bottleneck: Site rebuilds required for any content changes
  • Non-Technical Barrier: Content creators need Git/markdown knowledge. Can be more fragile
  • Complex Data Management: Product variants and relationships difficult in markdown
  • Limited Dynamic Features: Shopping cart, user accounts require external services

Option 2: WordPress

Pros:

  • Familiarity: I’ve built many small websites using WordPress
  • User-Friendly: Familiar admin interface for non-technical users
  • Mature Ecosystem: Thousands of plugins and themes available
  • Content Management: Rich text editor, media library, and draft system

Cons:

  • Security Vulnerabilities: Frequent security updates required, common attack target
  • Performance: Likely to be slowest of the options
  • Technology: PHP ecosystem conflicts with modern JavaScript workflow
  • Maintenance Burden: Regular updates for core, themes, and plugins required

Option 3: Strapi + Next.js (Headless CMS)

Pros:

  • Best of Both Worlds: CMS flexibility with modern frontend performance
  • Developer Experience: TypeScript support, modern tooling, and excellent developer experience I am used to
  • Customizable: Easy to model complex content types and relationships
  • Content Management: Intuitive Strapi admin interface for non-technical users
  • API Flexibility: GraphQL and REST APIs with custom endpoints
  • Performance: Static generation with dynamic capabilities (ISR)
  • Scalable Architecture: Headless approach supports multiple frontends

Cons:

  • Setup Complexity: More moving parts than monolithic solutions
  • Learning Curve: Team needs to understand both Strapi and Next.js
  • Maintenance Overhead: Two applications to deploy, monitor, and maintain
  • Development Time: Initial setup takes longer than WordPress installation
  • Infrastructure: Need to manage database, media storage, and API hosting

The current Olsson Designs architecture

The current Olsson Designs website is built as a modern monorepo with the following tech stack:

Frontend (Next.js)

  • Framework: Next.js 15 with App Router
  • Language: TypeScript for type safety
  • Styling: Tailwind CSS for rapid UI development (chosen over Sass)
  • Data Fetching: Apollo Client for GraphQL queries (chosen over REST)

Backend (Strapi Headless CMS)

  • CMS: Strapi 5 with TypeScript
  • Database: PostgreSQL for production reliability (chosen over SQLite)
  • API: GraphQL for flexible data fetching (chosen over REST)
  • Package Manager: pnpm for efficient monorepo management (chosen over npm)
  • Linting: ESLint and Prettier for code quality

How I got to this architecture

To rapidly prototype a first draft of the front-end I started by building directly on Square’s e-commerce API. Using their API explorer, I exported a JSON file that contained the product catalog and content. This approach avoided the complexities of setting up a headless CMS and database and allowed rapid iteration of the front-end.

It also taught me a lot about the proper relationships between products and their variations as well as the fields required for business logic (stock, taxes, order fulfillment)

Lessons Learned

  1. Start with Business Requirements
    • The Square API taught us to prioritize business needs (complex variants, rich content) over convenient integrations.
  2. Embrace Iterative Development
    • The JSON file phase wasn’t wasted time—it helped us understand the data model and user experience before committing to a CMS.
  3. Headless Architecture Provides Flexibility
    • Strapi’s headless approach allows us to potentially add mobile apps, admin dashboards, or other frontends without rebuilding the content management system.
  4. Type Safety Across the Stack
    • TypeScript prevented countless bugs during the JSON-to-Strapi migration and continues to catch issues during development.
  5. Balance of static and dynamic generation + rendering
    • For SEO and performance, all product and content pages are statically generated at build time. Dynamic compoennts are only used for variant selection, shopping cart, and user interactions. I use Cloudflare as a CDN which works well with the static generation.

Conclusion and future considerations

The journey from Square API to JSON files to Strapi showed me the importance of matching technology choices to business requirements. This approach also allowed me to rapidly iterate (especially combined with AI tools like Github Copilot) before committing to the final architecture.

The current Strapi + Next.js architecture balances performance, developer experience, and flexibility while also allowing us to easily add features to Olsson Designs for future growth:

  • Email notification webhooks: Rich email campaigns and order tracking with Shippo webhooks
  • Admin Dashboard: Separate admin interface for inventory management
  • 3D rendering: Tools to display 3d models of goods to users with selectable colors and options using Three.js integration into Next.js

Carl Olsson

Engineer, musician, and lifelong learner. Loves building things