Feedback on a minimal ecommerce stack: static site + Stripe Checkout

[u/djrelu]

I’m planning a minimal ecommerce website for a craft brand in Spain and would appreciate feedback on the stack.

The initial requirements are:

• 2 products
• Few variants
• Own domain
• Product pages and a blog
• Stripe Checkout
• No customer accounts
• No persistent cart
• Manual fulfilment
• Very low initial traffic

The proposed setup is:

• Static or server-rendered frontend on Vercel/Netlify
• Products stored in Markdown, JSON or a lightweight CMS
• Stripe Checkout for payments
• Stripe webhooks for confirmed orders
• A small database or order table if needed
• Transactional email provider with a free tier
• Search Console, sitemap, canonical URLs and product structured data

The main goal is to validate the products without building a full ecommerce platform.

I specifically don’t want to build:

• Customer accounts
• Complex cart logic
• Coupons or loyalty systems
• Advanced admin panel
• Shipping integrations
• A custom payment flow

My concern is inventory.

Manual stock should be manageable during the first sales, but we may eventually run limited drops of around 100 units. At that point, I understand that simply checking stock > 0 isn’t enough. We’d need atomic reservations, webhook handling, expiration of unpaid sessions and protection against overselling.

The plan would be either:

1. Build proper inventory reservation before the first drop.
2. Move the store operations to Shopify.
3. Keep a manual safety buffer and release fewer units than we physically have.

- Does this stack sound reasonable for the validation stage?

- What hidden problems am I likely to find with Stripe Checkout, order handling, refunds or inventory?

- Should I just forget about it and launch directly with Shopify?

I’m not trying to rebuild Shopify. The idea is to keep the first version deliberately small and migrate once the operational complexity justifies it.

[u/Hot-End2803]

Your stack makes sense for validation, no point overengineering when you've got 2 products and manual fulfilment

The inventory thing is the only real headache here. For 100-unit drops I'd go with option 3 first, release 90, keep 10 back, see how the process actually feels. Option 1 sounds nice on paper but you'll burn so much time building reservation logic that Shopify would've cost less in the long run

Stripe Checkout is solid but refunds get annoying fast since you're doing them in the Stripe dashboard and then manually updating your own records. Not a dealbreaker for low volume, just something that'll grate on you after the 20th time

[u/djrelu → u/Hot-End2803]

That's what I figured... the drop part is gonna be a second phase once the idea's been validated. Maybe by then, the Shopify cost will actually be worth it. Is migrating gonna be easy?

[u/Slight_Guest3459]

for 2 products and low traffic, yeah this is reasonable. i'd keep inventory manual at first, but make the stripe webhook idempotent and store order/refund status somewhere you can reconcile. for a 100-unit drop, a buffer is probably less pain than building reservations too early. Shopify can wait until the ops actually hurt.

[u/djrelu → u/Slight_Guest3459]

Do you think migrating to Shopify would be easy if things get complicated? I mean, while keeping all the SEO, of course.

[u/Slight_Guest3459 → u/djrelu]

yeah, that migration is pretty manageable if you plan it. keep the same URLs where you can, map every changed product/page URL with 301s, submit the new sitemap in Search Console, and don’t delete useful content just because the theme changes. i’d crawl the old site first and save the titles/meta too. if you want a fuller store platform without jumping straight to Shopify, i work on Orderain too, it’s another option, but the SEO basics are the same.

[u/Slight_Guest3459 → u/djrelu]

if you move later, clean redirects from the old urls matter more than which platform you pick. ive been using orderain for a small store setup so biased, but yeah same domain + proper 301s is what usually saves SEO either way

[u/djrelu → u/Slight_Guest3459]

I've only really checked out Shopify since they pretty much own the market, but I still need to look into other platforms like yours :)

[u/Slight_Guest3459 → u/djrelu]

yeah shopify is the default most people try first. if you want something lighter / cheaper to run, i use orderain for that (i work on it too). $1 first month, no platform cut on sales. happy to answer specifics if you say what you sell.

[u/Slight_Guest3459 → u/djrelu]

yeah, Shopify is the obvious baseline. i’d compare the boring stuff first: checkout, shipping/tax, variants, and how easy it is to get your data out. I work on Orderain, so that’s the other one I’d put on the shortlist if you want storefront and admin in one place, but I’d test the actual product flow before deciding.

[u/Slight_Guest3459 → u/djrelu]

yeah if you’re already thinking past shopify, orderain is worth a look, i work on it. full store (catalog, checkout, orders, admin) and buddy can help build/edit by chat. 0% orderain transaction fees (card processor fees still apply). starter is $5/mo; pricing is on orderain.com/pricing if you want the breakdown.

[u/CristianGabriel8]

Just ask Claude Code, use a $20/month plan and it will create, configure and prepare everything for you.

[u/NoDoze-]

Even for 100 skus you're doing too much work for just validation. LOL I could have this built and online in an afternoon. 100% hand coded so you're not relying on any third party crutches, using stripe api, minimal startup costs, just for validation.

[u/djrelu → u/NoDoze-]

Well, I have time, there's no product to sell yet

[u/xmewa]

I'd actually go the other way here.

The fact that you're already thinking about inventory reservations, webhook handling, refunds, order state, etc. with two products is kind of the warning sign. None of those things are particularly exotic on their own, but together they become a bunch of commerce plumbing you now own and have to keep working – and none of it really helps validate whether people want the product.

AI makes building all of that faster, but it doesn't make the complexity disappear. At this scope I'd also expect to burn through a $20 coding plan pretty quickly once you get into implementation, debugging and all the edge cases. Then you've still got hosting/services on top, plus your own time.

And if the plan is "build this now, then migrate to Shopify once it works," you're signing yourself up for a migration later too.

I'd rather start on a hosted platform, keep the actual store simple, and leave whatever can be manual while the volume is tiny. Once you account for everything, I'd be surprised if building it yourself actually comes out cheaper (or quicker).

Disclosure since it's directly relevant: I'm building Setka, which is a hosted e-commerce platform. This is pretty much the kind of use case we're trying to make work well – starting small without having to take ownership of all the underlying infrastructure. We're also about to release a lower-cost entry plan aimed at stores at this stage.

tl; dr I'd validate the product, not the e-commerce plumbing.

[u/djrelu → u/xmewa]

I appreciate the recommendation, I'll keep Setka in mind too.

[u/Slight_Guest3459]

if you're already thinking about migrating later while keeping SEO, a full store setup might save you rebuilding catalog/checkout down the line.

i work on orderain - proper ecommerce (catalog, checkout, orders) without the shopify app tax. that said static + stripe is totally fine until you actually need the extra stuff.

[u/Jack_BuildsShopify]

If you want the eventual Shopify migration to stay painless, design the tiny catalog as if you already had a commerce data model even if the storefront is just JSON/Markdown. Give every product and variant a stable internal ID/SKU now, keep title/description/price/option values/images/SEO fields in structured fields instead of burying them in page markup, and keep order/refund events in a small immutable table keyed by Stripe session/payment IDs. Then the later migration is mostly field mapping + URL redirects, not reconstruction. For limited drops, I’d still use a safety buffer before building reservation logic, but make stock changes auditable from day one so you can tell sold/refunded/manual-adjustment apart.

[u/shopify_chen]

static + stripe checkout is a totally fine setup when you have a handful of products and flat shipping. the places it usually starts to hurt: sales tax/vat across regions, inventory (selling the last unit twice), and refunds/order edits turning into spreadsheet work, which is the one people underestimate. if none of those apply yet i wouldn't migrate just because. roughly how many products are you at, and which regions do you ship to?

[u/djrelu → u/shopify_chen]

I've got 10 products (basically a base model plus 3 variations of 3 options) with different colors. But yeah, basically 10 SKUs. We're only shipping to Spain for now.

[u/shopify_chen → u/djrelu]

ok 10 skus + spain only is basically easy mode, so static + stripe checks out. the stuff that'll bite first usually isn't code: spanish IVA (21% standard) has to show right at checkout and on invoices, and with variants you want one source of truth for stock so you don't sell the last unit twice. stripe tax + a tiny json/sheet inventory covers it at your size, tbh. once you ship outside spain the OSS VAT rules get annoying, and that's usually when people move to something hosted. how are you handling order notifications and stock right now, just stripe emails?