Open the hood of almost any online store built in the last twenty years and you find the same skeleton. It is, at heart, a catalogue with a checkout bolted onto the end. That is not an accident of engineering — it is genealogy. E-commerce did not spring from first principles about money and obligations; it evolved, almost linearly, from the printed mail-order catalogue and the Yellow Pages. Put a catalogue on a screen, add a shopping cart, staple on a payment form, and you have "an online shop." The whole industry inherited the DNA of a paper artefact whose entire job was to display goods — and it has been paying for that inheritance ever since.

You can see the inheritance most clearly in where the code actually goes.

A catalogue wearing a cash register as a hat

Roughly 40% of a traditional store's code is catalogue and merchandising: product models, variants, attributes, categories, facets, search, image pipelines, import feeds. Another 30% is the cart-and-order plumbing that shuttles those catalogue items toward a purchase. 20% is content and CMS pages. And then, right at the end, almost as an afterthought, sit the two things the business actually exists to do: take money and deliver goods — together a rounding error of the codebase.

The imbalance does not stop at launch. It compounds. The catalogue is not only most of the code you write once; it is most of the code you maintain forever — the endless product syncs, the third-party feed integrations, the schema migrations every time merchandising wants a new attribute.

None of that catalogue work is wasted — a well-built catalogue is real craft, tended by real people, and it matters. But there is a quiet imbalance in catalogue-first commerce: engineers pour their careers into the part that displays the business, while the part that actually is the business — the moment a sale becomes a settled, recorded fact — gets a few afternoons a year.

The uncomfortable question: what actually is a sale?

Step back and ask the question the catalogue lineage never forces you to ask. A product page is not a sale. A cart is not a sale. A stock count is not a sale. None of that code, however voluminous, can by itself create the one thing a business runs on: a binding, timestamped record that party A owes party B a specific amount for a specific thing. That record has a name. It is an invoice line item — a fragment of a legal document, not a marketing asset.

96% of a classic store cannot, on its own, complete a single legally-settled transaction. We have spent 20 years lavishing our best engineering on the 96% and treating the 4% as a plumbing detail. VBWD was built on the opposite conviction.

Invert the store: the invoice line item as the point of truth

VBWD is checkout-centric, not catalogue-centric. The point of truth in the entire platform is the invoice line item, and it is deliberately a flexible interface rather than a fixed table of "products." A plugin — booking, subscription, a marketplace commission, a metered token charge, a dataset licence, a shipping fee, a discount that carries a negative amount — does not invent its own private notion of "a thing that can be sold." Through VBWD's event bus and plugin system it registers a new invoice-line-item type — and the logic that processes it — against the same base interface, and from that moment it participates in pricing, tax, discounting, settlement and reconciliation for free.

Put the invoice in the middle of the table and something clarifying happens. The invoice becomes what it always was in the physical world: a legal document with a timestamp. Around it sits an event-based contract engine whose single job is to keep the books honest — to hold the balance between active assets (what has been delivered, what is owed to the merchant) and obligations (what the merchant still owes, what must be refunded, what a subscription will bill next cycle). Every state change is an event against a contract, not a mutation of a product row.

Look at what happens to the catalogue in this picture. It does not disappear — it is demoted. It becomes one optional plugin among many, useful when you sell boxed products, irrelevant when you sell hours, seats, subscriptions, licences, API calls or commissions. The tail stops wagging the dog. You are no longer forced to model everything you sell as a "product" just because the framework's spine is a product table.

Payments are a core, not an afterthought

There is a second consequence of putting the invoice at the centre, and it is the one merchants feel fastest: VBWD carries a payment core inside the platform. Because every provider settles the same invoice through the same interface, integrating a new gateway is wiring against a known contract rather than re-plumbing the checkout. In practice that collapses the effort dramatically — on the order of 100× less code to bring another payment provider live than the same job on a classic e-commerce platform, where payments were bolted on at the edge and every gateway is its own bespoke integration. Payments are provider-agnostic and can settle non-custodially, straight to the merchant's own wallet, with no middleman holding the float.

Why business-centric is also the faster, leaner machine

Designing around the contract instead of the catalogue is not only cleaner architecture; it is measurably lighter to run. Because selling something new means declaring a line-item type rather than bolting another module onto a monolithic product model, the heavy, repetitive operations that punish catalogue-first systems — bulk syncs, re-indexing, feed reconciliation — get dramatically cheaper. In our own load tests, long-running operations such as full catalogue synchronisation ran roughly 20× faster than the catalogue-first baseline we measured against. Less wasted compute is less wasted money and less wasted energy — a leaner machine is, quietly, a greener one.

And because capabilities are plugins that toggle on and off without a restart, and the core is deliberately agnostic, you carry only the weight you actually use. The whole thing is source-available, so nothing about your own commerce spine is a black box you rent.

A new era, not a new template

The 2000s store was the last generation of software that still thought like a printed catalogue. VBWD is a bet that the next generation thinks like an accountant and a contract lawyer — that the centre of a commerce system should be the moment money and obligation are recorded, and everything else, the beautiful catalogue included, should orbit that centre as an optional convenience. Business-centric, payment-first, open source, and built for a digital world that sells far stranger things than boxes.

If that inversion resonates, the platform is open. Read the code and clone the public SDK at github.com/VBWD-platform/vbwd-sdk-public, browse the documentation, or get in touch to talk about building on it.

VBWD is source-available under BSL 1.1 — free for commercial use while annual VBWD-attributable sales stay under the value of 6.7 BTC per year.