Can I vibe code Solidus?
solidus.io ↗·ecommerce-platforms·usage-based·license
NICHE — BUILD THE NICHE VERSION
Solidus costs nothing but developer time. The honest verdict: rebuilding it with AI is very doable, but the payoff is not savings — it is control and stack fit. If your team is TypeScript-native, a generated headless core plus Stripe may beat maintaining a Rails monolith. If you are already productive in Rails, a rewrite buys you nothing but risk.
The verdict
NICHEReplaces
usage-based
Vibe code score
6/10
MVP build time
2 weeks
Full replacement
8-14 months
Editorial opinion, produced with a published methodology from public information. Not a statement of fact about the vendor. How we score · Report an error · Pricing checked 2026-08-10
01
Why this verdict
There is no licence to escape. Rebuilding makes sense only if you want to leave Ruby; otherwise you are trading a maintained core for a bespoke one.
Verdict
NICHE
Vibe code score
6/10
Moat strength
2/10
02
What it really costs
Sticker price versus what a real store ends up paying.
| Open source | free / quote | Free, BSD-3 licensed |
Fully free and open source (BSD-3). Cost is hosting and developer time only.
- Captured
- 2026-08-10 (45 days ago)
- Verified by
- human
- Source
- solidus.io
Assumptions: Fully free and open source (BSD-3). Cost is hosting and developer time only.
03
The one-shot build prompt
Paste it into your agent of choice. Nothing else needed.
Build a self-hosted e-commerce platform core inspired by Solidus, using TypeScript + NestJS + PostgreSQL (if leaving Ruby) or Rails 7. DATA MODEL: 1. Product: id, sku, title, slug, description, status (draft|active|archived), tax_class, brand_id, created_at. 2. Variant: id, product_id, option_values (jsonb), price_cents, compare_at_cents, currency, weight_grams, barcode, inventory_item_id. 3. InventoryItem: id, sku, location_id, on_hand, reserved, incoming, reorder_point. 4. Category: id, parent_id, slug, name, position, seo (jsonb) — materialised path for fast tree queries. 5. Customer: id, email, password_hash, accepts_marketing, default_address_id, tags (text[]). 6. Cart: id, customer_id nullable, currency, items (line_item[]), discount_codes (text[]), totals (jsonb), expires_at. 7. Order: id, number, customer_id, status (pending|paid|fulfilled|cancelled|refunded), payment_status, fulfilment_status, totals (jsonb), addresses (jsonb), placed_at. 8. Payment / Fulfilment / Refund: append-only rows linked to Order, never mutated in place. CORE FUNCTIONALITY: 1. Storefront read API (products, collections, search, cart) with SSR-friendly caching and stale-while-revalidate. 2. Cart engine: line-item pricing, tax-inclusive and tax-exclusive modes, promotion stacking rules, currency rounding per ISO 4217 exponent. 3. Checkout state machine: address → shipping rate → payment intent → capture → order. Idempotency keys on every mutating call. 4. Payment adapter interface with a Stripe implementation (payment intents, 3DS redirect, webhooks for async capture, refunds). 5. Inventory reservation on checkout start with TTL release, oversell protection via row-level locking. 6. Admin API + minimal admin UI: catalog CRUD, order search, refunds, manual orders, discount rules. 7. Webhook/event bus (order.created, order.paid, inventory.low) with retries and exponential backoff. 8. An order state machine with partial fulfilment, partial refunds and an append-only ledger that always reconciles to the payment provider. FAILURE MODES TO HANDLE: - Duplicate payment webhooks: dedupe by provider event id, store processed ids. - Concurrent checkout on the last unit: pessimistic lock or reserve-then-confirm, never optimistic-only. - Price drift between cart creation and payment capture: re-price server-side before capture and fail loudly. - Tax and currency rounding: compute in minor units, never floats. - Traffic spikes: cache catalog reads at the edge, keep cart/checkout uncached. OUT OF SCOPE: - A third-party app marketplace and extension sandboxing. - Multi-tenant SaaS billing for other merchants. - Payment processing licences: build on a PSP, never become one.
$ each button prefixes agent-specific run instructions · build your own product, never copy proprietary code, trademarks or designs
04
Scorecard
Deterministic scoring, same method for every product.
Vibe code score
6/10
Moat strength
2/10
05
What you keep, what you lose
The honest trade of rebuilding it yourself.
What you can actually replace
- ✓Catalog, variants and option types
- ✓Cart, checkout and order state machine
- ✓Promotions with basic rules and actions
- ✓Admin interface for orders and products
What you lose
- ×A maintained upgrade path with a security-conscious core team
- ×Rails extensions for payments, taxes and reporting
- ×Free bug fixes from other people's production incidents
06
Why people still pay — the real moats
Moats
- — An active maintainer community absorbing edge cases you have not hit yet
Hard parts
- — Order state machine correctness under partial fulfilment and partial refunds
- — Promotion engine determinism
- — Inventory units and stock location allocation
- — You inherit upgrade and security duty
- — Bespoke code has no Stack Overflow answers
Build this instead
Headless storefront over Solidus
Keep the Rails core, replace only the storefront with a modern SSR front end.
Build this instead
Commerce ledger service
Extract payments, refunds and payouts into an auditable append-only service usable by any core.
07
Prior art — do not start from zero
Existing projects and paid alternatives worth pricing first.
08
Open source alternatives to Solidus
Self-hostable projects that cover most of the same ground. Free licence, your infrastructure, your on-call.
09
Have you actually replaced it?
One click, no account. It moves the ranking.
10
Compare
Same category, different trade-offs.
11
FAQ
+Can I really replace Solidus with an AI-generated app?
KINDA — IT IS FREE ALREADY, SO THE QUESTION IS STACK PREFERENCE. There is no licence to escape. Rebuilding makes sense only if you want to leave Ruby; otherwise you are trading a maintained core for a bespoke one. An MVP takes roughly 2 weeks; matching the product properly is closer to 8-14 months.
+How long does it take to rebuild Solidus?
A usable internal version: 2 weeks. A version you would sell or bet a business on: 8-14 months, mostly spent on order state machine correctness under partial fulfilment and partial refunds.
+What do you actually lose by leaving Solidus?
A maintained upgrade path with a security-conscious core team Rails extensions for payments, taxes and reporting Free bug fixes from other people's production incidents
+Is it legal to build a Solidus alternative?
Building a competing product with your own code is normal competition. Copying their code, trademarks, brand assets or scraping their platform is not. Use the prompt to build your own implementation of common features.
Written by Andrea Saccà — 18 years in the Magento ecosystem. Last reviewed 2026-08-10.
Conflict of interest: Declared conflict of interest. The author is the official representative of Magento Open Source for Italy at Netcomm and works at Host S.p.A., which sells Magento hosting. Read the Platforms and Hosting & Infra entries with that in mind.
Scores are computed, not typed. Read the methodology.
One e-commerce SaaS teardown every week.
Honest verdicts, build prompts and overlooked vertical SaaS opportunities. No tracking pixels, no drip sequence, unsubscribe in one click.
free forever · no third-party tracking · the prompts stay public