DEV Community: Nathan M

I replaced a $99/month headless CMS with Shopify's built-in Metaobjects — here's the full starter

Nathan M — Sat, 07 Mar 2026 21:12:03 +0000

Every Hydrogen tutorial eventually hits the same wall.

You've got your storefront working. Products loading. Cart functional. Then the tutorial says:

"For content management, add Sanity."

Or Contentful. Or Builder.io. The cheapest plan starts at $99/month. You haven't made a single sale yet.

There's a better way.

Metaobjects: The free CMS already inside Shopify

Metaobjects are Shopify's native custom data type. They live in the same admin where you manage products. Free, forever, no extra API keys, no third-party login.

The pattern is simple:

import { Sections, SECTIONS_FRAGMENT } from './sections';

// In your route loader
const { metaobject } = await storefront.query(ROUTE_QUERY);

// Renders CMS-driven sections
<Sections sections={metaobject} />

Your content editors work entirely inside Shopify admin. No new tool to learn. No monthly bill.

What I built

A complete Hydrogen starter built around this pattern.

14 CMS-driven section types:

Section	Section	Section
Hero	Hero Slider	Featured Products
Collection Grid	Rich Text	Image + Text
Video	Testimonials	Logos
FAQ	Features	Banner
Countdown	Newsletter

Full store features:

Cart, wishlist, search, collections, product pages
Works with mock.shop out of the box — no Shopify account needed
Pre-configured Vercel deployment — live in 90 seconds

One command to start:

npx degit nathanmcmullendev/hydrogen-mockshop-clone my-store
cd my-store && npm install && npm run dev

Deploy to Vercel:

npx vercel

Why Metaobjects instead of a headless CMS?

The standard Hydrogen + Sanity setup costs $99/month minimum before launch. For an agency building client stores, that's overhead on every project. For an indie developer, that's a real barrier to shipping.

Metaobjects eliminate that entirely:

	Sanity / Contentful	Metaobjects
Cost	$99–$300/month	Free
Login	Separate service	Inside Shopify admin
API keys	Extra setup	Already configured
Learning curve	New tool	Same admin as products

Same functionality. Zero extra cost.

How content management works

Instead of writing to an external CMS, your content editors create and edit Metaobjects directly in Shopify:

Go to Shopify Admin → Content → Metaobjects
Create a page metaobject
Add sections (Hero, Featured Products, etc.)
Save — changes are live instantly

No deployments needed for content updates.

Connect your own store (optional)

The starter works with mock.shop by default. To connect your real Shopify store:

PUBLIC_STOREFRONT_API_TOKEN=your_token_here
PUBLIC_STORE_DOMAIN=yourstore.myshopify.com

That's it. One env file.

Shopify Dev Starter Kit - Store Checkout with a Dual-Mode Architecture

Nathan M — Thu, 22 Jan 2026 23:47:12 +0000

Solving Shopify's Dev Store Checkout Problem with a Dual-Mode Architecture

TL;DR: Shopify dev stores are password-protected, which blocks checkout testing entirely. I built a starter kit with Stripe fallback for development, native Shopify checkout for production. Looking for architecture feedback before I keep building.

The Problem Nobody Talks About

If you've built a headless Shopify store, you've probably hit this wall:

You spin up a free development store. You connect the Storefront API. Products load beautifully. You build your cart. Then you try to test checkout and... password page.

Shopify dev stores are permanently password-protected, and that protection extends to the hosted checkout. When your headless frontend redirects to checkoutUrl, visitors (including you) hit the password wall instead of completing a purchase.

This means you can't:

Demo a complete purchase flow to a client
Test your order creation webhooks
Verify fulfillment integrations work
Show investors/stakeholders a working prototype

Hydrogen has the same limitation — Shopify's own docs acknowledge it: "Online store password protection prevents Hydrogen checkouts."

The Architecture

The solution is dual-mode checkout:

Development: Cart → Stripe Elements → Payment Intent → Admin API → Order
Production:  Cart → Shopify Checkout URL → Native Hosted Checkout → Order

One environment variable switches between them:

# Development (works on free dev stores)
VITE_CHECKOUT_MODE=stripe

# Production (native Shopify checkout)
VITE_CHECKOUT_MODE=shopify

How Stripe Mode Works

Instead of redirecting to Shopify's hosted checkout, the Stripe path:

Collects payment via Stripe Elements (full UI control)
Creates a PaymentIntent server-side
On success, creates a draft order via Admin API
Completes the draft order (marks as paid)

The result is a real order in Shopify Admin — inventory decrements, webhooks fire, fulfillment workflows trigger. Indistinguishable from a checkout-created order.

Why Not Just Use Stripe Forever?

You could, but Shopify's native checkout handles:

Shop Pay, Apple Pay, Google Pay
Shopify's fraud analysis
Automatic tax calculation
Their checkout conversion optimizations

For production stores with a paid Shopify plan, native checkout is the right choice. The Stripe path exists purely to unblock development and demos.

What I Actually Built

Stack: React 18, TypeScript (strict), React Router 7, Tailwind, Vite

Features:

Shopify Storefront API integration (products, collections, variants)
SSR-safe cart persistence (no hydration errors)
Stripe Elements checkout with Admin API order creation
Cloudinary CDN for image optimization
347 tests, 89% coverage

Live demo: ecommerce-react-shopify.vercel.app

Test card: 4242 4242 4242 4242 (any future expiry, any CVC)

Where I Want Feedback

I'm self-taught and working solo on this, so I'd genuinely appreciate experienced eyes on:

1. Cart Context Pattern

I'm using useSyncExternalStore for SSR-safe localStorage persistence. It works, but I'm not sure if it's overengineered. The implementation is in src/lib/createPersistedStore.ts.

2. Checkout Flow Security

Payment verification happens server-side before order creation, but are there edge cases I'm missing? The logic is in app/routes/api.create-order.ts.

3. Project Structure

Does the file organization make sense, or is anything non-obvious?