Own the shopfront. Keep ERPNext as the truth.

01 · When to choose it

For consumer brands that want a real store they own outright, with no platform fee and no per-order cut, while stock and pricing stay in ERPNext. When it isn't the right fit, we say so:

02 · Who owns what

One rule makes the whole thing work: ERPNext is master for everything the business counts. The shop presents it and takes the money.

03 · What runs where

About 290 MB of memory for the whole shop tier. It runs beside ERPNext on the same server, or on its own small VM.

04 · The ERPNext side

• Prices include VAT. A sales tax template with VAT included in the rate, so the website, the Sales Order and the invoice agree to the cent.
• Sizes are variants. One template, one variant per size; the ERPNext item code is the shop SKU.
• Website fields on Item: publish flag, tagline, spec pills, badge, compare-at price, warranty text. Only published items reach the shop.
• A gateway clearing account. Web payments land there, and gateway payouts reconcile into the bank.
• Serial numbers where there's a warranty: recorded at receipt, picked at delivery, so "who has frame 0004?" is one lookup.
• A narrow API user for the shop: it can read items, prices and stock, and create customers, sales orders and payment receipts. Nothing more.
• Imports done properly: factory orders in USD, a clearing-agent invoice for freight, duty and port charges, and a landed cost voucher that puts them into stock value. The shop's margin is real, not FOB.

All of it is configuration-as-code: scripts that build the setup on a fresh site and check it, so a client's version is a re-run on their data, not a fresh build.

05 · The Vendure side

• Pinned, hardened scaffold: Vendure 3.7 on Postgres in Docker, with South African base data (ZAR, the South Africa zone, VAT 15% and zero-rated) and test mailboxes and debug tools off in production.
• The ERPNext plugin, about 450 lines:
  • Pull: published items, VAT-inclusive prices and per-warehouse stock. It runs on start, every five minutes and after every order, and matching on item code means it never duplicates.
  • Push: once a payment settles, it finds or creates the customer (with contact and address), creates a submitted Sales Order at the website's prices and a payment receipt against it, then refreshes stock.
• Stock without double counting. A paid order is held in both systems until delivery, so the sync adds Vendure's own allocations back onto ERPNext's free stock.
• The storefront is replaceable. We ship a working store page, and a client build can use the Vendure Next.js starter or their agency's front end. The plugin doesn't care which.

06 · How we prove it

Landed cost on the demo range came to R29k–R39k per bike against R39k–R52k retail ex VAT. The demo prices are placeholders, but the arithmetic is the real thing.

07 · From demo to live

What a production build adds to the demo:

1. A real payment gateway (PayFast, Yoco, Peach or Paystack), with webhook settlement, fees booked, and payouts reconciled.
2. A guaranteed order push: queued with retries and keyed on the shop order number, so a retry never creates a second Sales Order. Failed pushes are visible in the admin.
3. Delivery back to the shopper: ERPNext delivery → "shipped" email with tracking; cancellations and refunds in both directions.
4. A live price and stock check at checkout, if stock moves faster than every five minutes.
5. Go-live hygiene: database migrations, email, nightly backups, monitoring, and POPIA consent at checkout.

08 · Effort and licence

These are indicative ranges, firmed up in the proposal once the catalogue and design are known. Licence: Vendure Core is open source (GPLv3, with an exception that lets plugins carry their own licence). Running your shop is not distribution, so there is no licence fee and no per-order cut. Vendure's paid Platform edition is only needed for its packaged B2B features, which ERPNext already provides here.

09 · What we learned building it