Fernside Studio
Background
Archive
Journal Entry

Building an E-commerce SaaS Hybrid Platform

Documented
Capacity
11 MIN READ
Domain
E-commerce & SaaS

Most commerce platforms are either product shops or subscription services. Rarely both. When you attempt to combine them, putting a product catalogue with checkout alongside tiered subscriptions with recurring billing, you’re entering architecturally complex territory.

We’ve built this exact platform. CardDeckr unifies a product shop, subscription tiers, and a peer-to-peer marketplace into a single codebase with a shared PostgreSQL database spanning 66 tables. It handles one-off purchases and recurring revenue from the same checkout flow, managed through a unified admin dashboard, and protected by over 6,900 automated tests.

This article explains what makes hybrid platforms different, the architectural decisions that matter, and the operational complexity you’ll face when building one yourself.

What makes a hybrid platform different

A pure e-commerce store sells products. You manage inventory, process orders, ship goods. Revenue arrives when someone buys something. The customer relationship ends at delivery (or returns).

A pure SaaS product sells access. You manage subscriptions, process recurring payments, deliver features. Revenue arrives monthly or annually. The customer relationship is ongoing, and retention matters more than acquisition.

A hybrid platform does both. You sell products and access simultaneously, often to the same customer. This introduces architectural challenges that neither pure model faces on its own.

The unique challenges

Unified accounts. Customers need a single login that works across both sides of the platform. They buy a product, upgrade to a subscription, manage both from one dashboard. Your authentication system must handle one-off buyers who’ve never subscribed and subscribers who’ve never purchased.

Shared billing. Stripe can handle products and subscriptions separately, but hybrid platforms need them to interact. A customer might buy a product, add a subscription in the same checkout, then upgrade that subscription later. Your payment flows must accommodate every combination without creating duplicate charges or orphaned records.

Single admin view. Your team needs visibility across products, orders, subscriptions, and customer accounts from one interface. Bolting a Shopify store onto a SaaS dashboard creates operational silos. Orders live in one system, subscribers in another, revenue reports in a third. A proper hybrid platform unifies these views.

Revenue model complexity. You’re tracking one-off purchases, recurring subscription revenue, upgrades, downgrades, refunds, and cancellations. Financial reporting becomes significantly harder when you can’t treat all revenue the same way. Monthly Recurring Revenue (MRR) calculations need to exclude product sales while including subscription renewals.

Architectural decisions that matter

When we built CardDeckr, we made three foundational decisions that shaped everything else.

1. Shared user accounts

Every user gets one account. Whether they’ve only bought products, only subscribed, or done both, they authenticate the same way and access the same customer portal. We implemented this with a users table that stores authentication details and a customers table that handles Stripe Customer IDs, subscription status, and billing metadata.

This means a buyer can purchase products without subscribing, and we can convert them to subscribers later without creating new accounts. Their order history, subscription status, and account settings live in one place.

2. Unified billing through Stripe

We use Stripe for everything: one-off checkout with PaymentIntents, recurring billing with Stripe Billing, and marketplace payouts with Stripe Connect. This avoids the integration nightmare of multiple payment processors with different data models and webhook formats.

CardDeckr’s checkout flow handles products and subscriptions in the same session. A customer can buy a physical product and start a subscription in one transaction. Stripe’s PaymentIntent covers the product purchase, and a linked Subscription handles the recurring charges. We track both in our database with foreign keys to the same customers record.

For a deeper look at how we structure Stripe integration beyond simple checkout flows, see our guide on Stripe integration beyond checkout: subscriptions, Connect, and billing.

3. Database design for dual revenue models

A hybrid platform needs tables for products, orders, inventory, subscriptions, plans, usage tracking, and customer accounts, all linked through a relational schema that handles both transactional and recurring revenue.

CardDeckr’s database includes 66 tables. Some handle product commerce: products, orders, order_items, inventory. Others handle subscriptions: subscription_plans, subscriptions, usage_tracking, entitlements. Many are shared: customers, payments, refunds.

The key is designing relationships that allow one customer to exist in both worlds without duplication. A single customers row can have multiple orders and one subscription, all linked by foreign keys. We wrote about this in detail: Database design for e-commerce SaaS platforms.

Why subscription-first thinking matters

If you’re building a hybrid platform, start with the subscription model and add products on top, not the other way around. Retrofitting subscriptions onto an existing product shop is architecturally harder than adding product sales to a subscription platform.

Subscriptions set the foundation. They require user accounts, recurring billing, entitlement logic, and customer portals. Products need inventory management and shipping logic, but they don’t fundamentally change how authentication, billing, or account management work.

Revenue mechanics are cleaner. Subscriptions generate predictable MRR. Products generate transactional revenue. It’s easier to track one-off purchases inside a subscription system than to bolt recurring billing onto a transactional shop.

Retention drives value. A product shop optimises for conversion. A subscription platform optimises for retention. Hybrid platforms need both, but retention typically matters more to long-term revenue. Design your platform to encourage subscription upgrades from product buyers, not the reverse.

We explored this in depth: Subscription-first e-commerce: why recurring revenue wins.

Payment flow complexity

One of the hardest parts of hybrid platforms is testing payment flows. CardDeckr has multiple paths a customer can take:

  • Buy a product as a guest (no subscription)
  • Buy a product and create an account (still no subscription)
  • Subscribe to a free trial (no product purchase)
  • Subscribe to a paid plan (no product purchase)
  • Buy a product and start a subscription in one checkout
  • Upgrade a subscription mid-cycle
  • Downgrade a subscription at renewal
  • Cancel a subscription but continue buying products
  • Refund a product purchase
  • Refund a subscription charge

Each path requires different database updates, webhook handling, and email confirmations. One-off purchases create orders and update inventory. Subscriptions create subscriptions and schedule future charges. Combined purchases do both, atomically.

We handle this with over 6,900 automated tests covering API endpoints, webhook flows, subscription lifecycle, and payment integrity. Every deployment runs the full suite. We wrote about why this level of testing matters: Testing e-commerce at scale: why 6,900 tests matter.

Admin dashboard requirements

A hybrid platform’s admin dashboard needs to surface:

Product management. CRUD for products, variants, pricing, and inventory. Real-time stock levels. Bulk import/export. Image uploads. Category management.

Order management. View all orders, filter by status, mark as shipped, process refunds. Export for accounting. Track fulfilment.

Subscription management. View active subscribers, filter by plan, see MRR calculations, manually upgrade/downgrade accounts, issue refunds, cancel subscriptions. Stripe dashboard links for deep dives.

Customer management. Unified customer view showing both order history and subscription status. Contact details, lifetime value, support notes.

Analytics. Revenue split between products and subscriptions. Conversion rates. Churn metrics. Top products. Subscription plan distribution.

CardDeckr’s admin dashboard spans 44 pages with full CRUD across all entities, audit logging for every admin action, and analytics charts for revenue tracking. It’s a custom build in Astro with API routes connecting to the same PostgreSQL database that powers the customer-facing platform.

When to build custom vs use off-the-shelf

Use Shopify + a SaaS tool if your product shop and subscription service are mostly separate. Shopify handles physical products well. Stripe Billing or a dedicated SaaS platform like Memberstack handles subscriptions. Accept the operational overhead of two systems.

Build custom if your product and subscription offerings are tightly integrated. If buying a product should unlock subscription features, or if subscription tiers gate access to certain products, you need a unified platform.

CardDeckr required custom because the product shop, subscription tiers, and marketplace are interdependent. Subscribers get higher transaction limits in the marketplace. Product purchases can unlock subscription features. Free users can buy products but can’t create marketplace listings. These entitlements require a shared database and unified logic.

The role of the database in unifying commerce and SaaS concerns

Your database is the source of truth for both revenue models. It must track:

  • Products and inventory levels
  • Orders and order items with shipping status
  • Subscription plans with pricing and limits
  • Active subscriptions with renewal dates and status
  • Usage tracking for metered billing
  • Customer accounts linked to Stripe Customer IDs
  • Payment records for both one-off and recurring charges
  • Refunds across both models

CardDeckr’s 66-table PostgreSQL schema handles all of this with foreign keys enforcing referential integrity. We use Supabase for hosting, row-level security for access control, and stored procedures for complex business logic like subscription upgrades with proration.

Operational complexity

Running a hybrid platform means:

Double the support surface. You’re answering product questions (shipping, returns, defects) and subscription questions (billing, upgrades, cancellations). Your support team needs training on both.

More complex refunds. Refunding a product purchase is straightforward: credit the customer and restock inventory. Refunding a subscription charge mid-cycle requires proration calculations and adjustment of the next billing date.

Financial reporting challenges. Your accountant needs to distinguish product revenue from subscription revenue for accurate bookkeeping. Stripe’s reporting separates PaymentIntents from Subscriptions, but you’ll likely need custom exports from your database.

Webhook handling. Stripe sends webhooks for every payment event. With both products and subscriptions, you’re handling payment_intent.succeeded, invoice.paid, customer.subscription.updated, and a dozen others. Each webhook needs idempotent handling and database updates.

We handle this with a dedicated Cloudflare Worker that processes Stripe webhooks, deduplicates events using Cloudflare KV, and updates the database atomically. Every webhook writes to an audit log for debugging.

Why Stripe is the right payment layer for hybrid platforms

Stripe handles one-off payments (PaymentIntents), recurring billing (Subscriptions), and marketplace payouts (Connect) from a single API. This eliminates integration complexity that comes from using separate payment processors for products and subscriptions.

CardDeckr uses:

  • Stripe Checkout for product purchases
  • Stripe Billing for subscription renewals
  • Stripe Connect for marketplace seller payouts
  • Stripe Customer Portal for self-service subscription management

All of these share the same Customer object in Stripe, meaning one customer can buy products, subscribe to a plan, sell on the marketplace, and manage their subscription without touching multiple payment accounts.

Real-world example: CardDeckr

CardDeckr is our largest custom build. It combines:

  • A product shop with inventory management and Stripe checkout
  • Tiered subscriptions with metered usage limits
  • A peer-to-peer marketplace powered by Stripe Connect
  • AI-powered card scanning and grading (subscription-gated features)
  • A virtual portfolio system for tracking collections

The platform handles both one-off product purchases and recurring subscription revenue from a single codebase. Customers can buy trading cards as guests, upgrade to a subscription to unlock AI tools and portfolio limits, and sell their own cards through the marketplace, all from one account.

It’s built on Astro 5 with React 19 for interactivity, deployed on Cloudflare Pages, connected to a 66-table PostgreSQL database in Supabase, and integrated with Stripe for all payment flows. Over 6,900 automated tests protect payment integrity and data consistency across deployments.

Building it required architectural decisions we wouldn’t have made for a pure product shop or pure SaaS platform. The lessons from that build inform every e-commerce project and custom software project we take on.

Should you build a hybrid platform?

Only if your business model genuinely requires it. Hybrid platforms are harder to build, harder to maintain, and harder to operate than single-revenue-model platforms.

Build hybrid if:

  • Your product purchases and subscription offerings are tightly integrated
  • Subscribers get different pricing or access to products
  • Product buyers should be convertible to subscribers in one click
  • You need unified analytics across both revenue streams
  • You want one admin dashboard for products, orders, and subscriptions

Stick with separate systems if:

  • Your products and subscriptions serve different audiences
  • Integration between the two is minimal
  • You’re optimising for speed to market over architectural elegance
  • You don’t have the engineering capacity to build and maintain custom infrastructure

How Fernside builds hybrid platforms

When we scope a hybrid platform, we start with the subscription model and add commerce on top. We map out every payment flow, design the database schema to handle both revenue models, and build comprehensive tests before writing customer-facing features.

We use Stripe for all payment processing, PostgreSQL for the database, and either Astro (for content-heavy platforms) or Next.js (for app-heavy platforms) for the front-end. Everything deploys on Cloudflare for edge performance and global availability.

If you’re planning a hybrid platform, start a conversation with us. We’ll scope the architecture, estimate the build, and outline what it takes to launch a platform that handles products and subscriptions without compromise.

Further reading:

Say hello

Quick intro