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.

This is the quiet tragedy of catalogue-first commerce: your engineers spend their careers maintaining the digital equivalent of a glossy brochure, while the part of the system that turns a visitor into revenue 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." It declares an invoice-line-item object 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.

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. Payments are provider-agnostic and can settle non-custodially — funds land in the merchant's own wallet, not a middleman's float. 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.