~/blog/build-vs-buy-subscription-ecommerce-cost-analysis
Architecture2023·15 May 2023

Build vs Buy for Subscription E-Commerce: A Detailed Cost Analysis

After running a rigorous build vs buy analysis for a subscription e-commerce platform, the numbers told a clear story. Here's the full framework, the cost breakdown, and why 'just use Shopify' is the wrong answer for complex subscription models.

build-vs-buyShopifysubscriptione-commerceSaaSCTO

The Question Every Growing E-Commerce CTO Eventually Faces

At some point in the lifecycle of any subscription e-commerce business, the architecture review becomes unavoidable. The original platform — whether Shopify, WooCommerce, or a custom build from the early days — starts showing structural limits. Features take longer. Workarounds accumulate. Engineers start dreading certain parts of the codebase.

The question that follows is almost always framed incorrectly: "Should we rebuild, or stick with what we have?" The better question is: "What is the right architecture for the business we are now, and the business we plan to be?"

This post documents how I've approached that question — including a detailed cost comparison that often surprises people.

Why Standard Retail E-Commerce Platforms Don't Fit Subscription Models

The fundamental problem with retail-focused platforms (Shopify being the dominant example) for subscription businesses is that the entire platform is designed around a different mental model.

Retail e-commerce is transaction-first: customer browses, selects, pays, done. The relationship ends at the confirmation email.

Subscription e-commerce is relationship-first: the customer signs up, and then you manage an ongoing, evolving relationship across dozens of interactions — skips, pauses, swaps, gift redemptions, dunning, reactivations, plan changes. The subscription lifecycle is the product.

This manifests in concrete capability gaps:

| Subscription Requirement | Platform Limitation | Consequence |

| --- | --- | --- |

| Customer-based delivery scheduling | Not native — custom app required | Custom dev cost on top of platform fees |

| Skip / pause / swap / opt-in logic | Third-party plugins with limited flexibility | Plugin constraints, workarounds, multiple vendor dependencies |

| Zone-based routing and fulfilment | No concept exists natively | Entire workflow needs a custom app |

| B2B portal with custom pricing | Separate solution required | Additional SaaS cost and integration complexity |

| Weekly product cycle management | Static catalogue model | Misalignment with buying/operations workflows |

The Cost Analysis

In 2023, I ran a rigorous cost comparison for a subscription business doing approximately £3M monthly revenue. The comparison was between a Shopify Plus + plugin stack and a hybrid bespoke solution (custom core + best-in-class SaaS for commodity capabilities).

| Cost Component | Shopify + Plugins | Hybrid Bespoke |

| --- | --- | --- |

| Platform / Infrastructure | £1,600/mo | £2,000/mo (AWS) |

| Subscription management | £1,600/mo (Recharge) | Included in custom build |

| CMS / landing pages | £160/mo | £350/mo (Builder.io) |

| Fulfilment management | £500/mo | Custom (included) |

| A/B Testing | £400/mo | Statsig (included) |

| Referral platform | £1,500/mo | Custom / included |

| Cancellation flow | £1,500/mo | Custom / included |

| Transaction fees (0.5%) | £46,000/mo | £0 |

| Staff costs | £30,000/mo | £48,839/mo |

| TOTAL | £83,630/month | £61,739/month |

Annual saving in favour of bespoke: ~£262,000.

The staff cost differential reflects the engineering capacity needed to build and maintain what the plugins would otherwise provide. The platform + transaction fee savings more than offset this — and critically, the transaction fee saving scales with revenue. At higher revenue, the advantage grows dramatically.

The "Hybrid" Framing Is Important

The word "bespoke" triggers alarm in experienced CTOs — and rightly so. Fully bespoke systems are expensive, slow to build, and accumulate debt. The key is the hybrid model: build only what differentiates you, buy everything that doesn't.

| Capability | Approach | Rationale |

| --- | --- | --- |

| Payment processing | Stripe + Braintree (SaaS) | Best-in-class, PCI-compliant — no competitive advantage in building this |

| Subscription / delivery logic | Custom | Core business logic — must be owned and controlled |

| CMS / landing pages | Builder.io (SaaS) | Marketing must move without engineers in the critical path |

| Email / SMS | Brevo (SaaS) | Commodity communications |

| Feature flags (frontend) | Statsig (SaaS) | Built-in statistical significance for A/B tests |

| Customer support | Dixa (SaaS) | Specialist tooling, integrated via API |

| Admin / ops tooling | Custom | Unique operational workflows requiring bespoke tooling |

The result is a system where engineering effort is concentrated on genuinely differentiated capabilities, while commodity capabilities are delegated to vendors who do them better.

When Platform Wins

To be fair: for businesses where the subscription model is simple (basic recurring billing, standard catalogue, no fulfilment complexity), Recharge on Shopify is a perfectly viable choice. If your model is "ship the same box every month", the platform economics look different.

The decision framework:

  1. 1.Map your business model's capabilities that are not standard e-commerce
  2. 2.For each, evaluate whether a platform plugin can meet your requirements without workarounds
  3. 3.Build a genuine cost model including transaction fees — these are usually underestimated
  4. 4.Make the decision on data, not instinct

The "just use Shopify" instinct is correct for many businesses. For subscription businesses with genuine operational complexity, it's usually wrong — and the numbers show it.