Multi-tenant SaaS · Subscription billing
Order Protection
A shipping-protection and insurance product sold to merchants as a native app on Shopify, Magento and BigCommerce — one multi-tenant core, three thin platform adapters, and money that has to reconcile exactly.
- Tenancy model
- Multi-tenant, one core
- Platforms
- 3 (Shopify, Magento, BigCommerce)
The problem
Shipping protection has to attach itself to a cart, survive checkout, and reconcile against the resulting order — on three platforms whose cart, checkout and webhook models have almost nothing in common. It is also multi-tenant: every merchant has their own pricing rules, their own billing relationship and their own data, all served from one deployment. Rebuilding the product three times would have tripled the maintenance cost of every future change; letting tenant config leak into platform code would have made both impossible to reason about.
What I built
Modelled protection as a platform-agnostic multi-tenant core, with thin per-platform adapters handling each platform's cart, checkout and webhook contracts — and nothing else.
Kept tenant resolution at the edge of every request, so merchant identity is established once and every downstream query is scoped by it rather than filtered after the fact.
Built the Shopify app against the app framework properly — OAuth 2.0, session tokens, webhook registration and embedded app surfaces — rather than bolting on script tags.
Handled subscription billing and per-order premium collection, including reconciliation between what was quoted at cart and what was actually captured at checkout.
Made webhook handling idempotent, because all three platforms will deliver the same event more than once and eventually deliver it late.
Architecture
A shared multi-tenant core with per-platform adapters — the only way one product survives three commerce platforms without tripling its own maintenance cost.
Merchant surfaces
Adapters
Core service
Data
What was hard
Three incompatible checkout models
What is a line item on one platform is a fee on another and an extension surface on a third. The adapter boundary had to sit exactly where the platforms genuinely differ — push it too low and the core leaks platform detail, too high and every adapter reimplements the product.
Multi-tenancy where the tenant is someone else's store
Each merchant's config, pricing and order data lives in one deployment, but the identity comes from a platform you do not control and an OAuth session that can be revoked at any time. Tenant scoping had to be a property of the data access layer, not a `where merchant_id =` that someone eventually forgets.
Money must reconcile exactly
A protection premium quoted in the cart and captured at checkout has to match, even when the cart changes after quoting. Getting this wrong is not a UI bug, it is a billing dispute — with a merchant who can uninstall you.
Business impact
- One product core serving three platforms — a feature ships once instead of three times.
- Idempotent webhook handling removed the duplicate-charge and missed-order classes of bug entirely.
- Merchants get a native-feeling install on whichever platform they already run.
- New platform support became an adapter-sized problem rather than a rewrite.
Technologies
Working on something like this?
I'm open to senior Shopify and full stack roles. Tell me what you're building.