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.

Share X LinkedIn

The verdict

NICHE

Replaces

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.

Entryusage-based≈ estimated · 2026-08-10
Open sourcefree / quoteFree, BSD-3 licensed

Fully free and open source (BSD-3). Cost is hosting and developer time only.

Where this number comes from
Captured
2026-08-10 (45 days ago)
Verified by
human

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.

The one-shot build promptbuild it on Lovable
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

Technical difficulty6/10
Operational burden5/10
Integration depth6/10
Data advantage1/10
Network effects2/10
Compliance load5/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.

Community verdict

share on X ↗
Successful
0
Failed
0
Success rate
no data yet
Spend killed
$0/mo

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