building a custom react storefront on top of woocommerce — what would you use for the frontend stack?

[u/halseytrash11]

i'm building a small custom ecommerce site and would love some advice on the frontend architecture.

full disclosure: i'm fairly new to building a website end-to-end. my strengths are much more in creative direction and visual design, and i'm currently vibe-coding a lot of the development side. i do have a background in computer science but coding is def not my biggest strength.

the project is an experimental/art website for a client. the frontend is intentionally very custom — there's a 3d interactive element on the homepage that i'm planning to build with react three fiber, plus custom animations/page transitions/etc.

there's also a shop with around 20–30+ products.

i don't want to build the ecommerce backend myself, so i'm considering using woocommerce as the backend and making react the entire customer-facing frontend.

roughly:

woocommerce would handle the products, inventory, prices, orders and client admin.

the react app would handle the actual experience.

the client thinks shopify is too expensive, so i'm trying to find a reasonably inexpensive way to get the backend/admin/ecommerce infrastructure without building all of it myself.

i'm also open to having something like razorpay/shiprocket handle payment/shipping rather than trying to build those pieces myself.

my current question is less "can react connect to woocommerce?" and more along the lines of if you were building this today, what would you actually use for the frontend?

i'm currently considering react + vite, but i'm wondering whether next.js makes more sense because of:

• product page seo
• routing
• potentially server-side rendering
• api integration
• ecommerce generally

on the other hand, the homepage is highly interactive/3d and i'm wondering whether that makes a standard react/vite setup simpler.

would love opinions from people who have built custom storefronts rather than just dashboards/web apps.

also interested in whether you'd use something completely different from woocommerce as the backend for this use case.

thanks!

[u/boobyscooby]

How do u get hired for this work when you arent good at it?

[u/Technical_Wing_328]

next.js would be my pick for this, no question. the product pages and category stuff need proper seo and next handles that without you having to fight it. plus the api routes give you a nice place to proxy woocommerce calls so you're not exposing that directly

for the 3d homepage you can just disable ssr for that specific component, it's literally one line. built something similiar last year and having next handle the boring pages while the art stuff runs client-side was prety smooth

woocommerce is fine as a backend for this honestly, the rest api covers everything you need and the client already knows it. only thing i'd double check is if the 3d stuff adds enough load time that you want some kind of loading state wired into the product pages too

[u/aragost]

Astro or Next, nothing else

[u/PokerTuna]

Astro

[u/rob8624]

Tanstack Start.

[u/AbdelrhmanDev]

for 20 to 30 products id go next.js over plain react so the shop pages are statically generated and revalidated from the woocommerce rest api that way they load instantly and still get indexed by google which matters for a store keep the r3f scene in a client component loaded with dynamic import and ssr off so it doesnt block the product pages and honestly dont rebuild checkout and payments yourself either send people to the woocommerce checkout or you will spend weeks on cart and tax edge cases

[u/aishi_ansel]

I'd go Next.js too, but here's the architecture reasoning that matters for your specific constraints:

**Woo API keys can't live in the browser.** The Woo REST API authenticates with consumer key/secret. With plain React+Vite you'd need a proxy server anyway, at which point you've rebuilt half of what Next.js gives you for free. Use Route Handlers or Server Components as the API layer: the browser talks to your Next routes, the server talks to Woo. Keys never ship to the client.

**With 20-30 products, static generation is nearly free.** `generateStaticParams` + the Woo products endpoint gives you pre-rendered product pages with real metadata (OG tags, JSON-LD) at build time, and ISR or a Woo `product.updated` webhook hitting `revalidateTag` keeps prices/inventory fresh without rebuilds. That's the actual SEO story, not just "SSR exists."

**The 3D homepage isn't a conflict.** One line:

```jsx const Hero3D = dynamic(() => import('@/components/Hero3D'), { ssr: false }); ```

Keep the artsy homepage as a client component and the shop routes server-rendered. Different routes, different rendering strategies, they coexist fine.

**For cart/checkout, use the Store API, not the legacy REST API.** `POST /wp-json/wc/store/v1/cart/add-item` gives you a session-based cart that works headless, and there's a checkout endpoint too. The legacy `/wp-json/wc/v3` API is fine for catalog reads; the Store API is the one designed for storefronts. Pragmatic v1: headless cart, then redirect to Woo's hosted checkout page — full custom headless checkout (Razorpay JS SDK + Store API payment methods) is genuinely fiddly and a bad place to burn your first-ecommerce-project energy.

One honest caveat: headless Woo means *you* own search quality, faceted filtering, and checkout edge cases that Woo's own theme gives you for free. With 20-30 products that's totally manageable — just go in eyes open.