There is a line item most enterprises have stopped seeing. It doesn't appear cleanly in any budget, because it's spread across a dozen of them: the standing cost of keeping commerce software alive that was architected for a different decade. It shows up as the integration that takes a quarter, the catalogue sync that runs overnight because it can't run in an hour, the specialist contractor whose entire job is to keep something fragile from breaking. Individually, each is explainable. Together, they are a tax — and like most taxes you've paid for years, you've stopped noticing the size of it.

This piece is for the people who do still notice: the operators who sign off on the renewal and quietly wonder what exactly they're renewing.

The number vendors quote is the smallest one

When a legacy commerce or ERP platform is priced, the licence is the figure on the slide. It is also, by the industry's own accounting, the minority of what you will actually spend. Analyses of 2026 replatforming and migration costs put the licence at roughly 20–40% of total project cost — the remaining 60–80% is implementation, ERP integration, data migration, and the endless rounds of QA that complex integrations demand. The sticker is the part they show you because it's the part that looks reasonable.

The tax continues after go-live. Teams running aging platforms report that legacy systems silently consume 40–60% of every development sprint in workaround maintenance, custom backports, and one-more-patch fire drills. That is not a capability budget. It is a survival budget — engineers paid handsomely to keep the past running instead of building the future. The most expensive thing about old software is rarely its price. It's the opportunity cost of everyone tending it.

A concrete tell: the catalogue

Abstract cost arguments are easy to wave away, so here is a specific one that operators feel in their bones. Consider importing a catalogue of one million complex products — variants, pricing rules, taxes, relationships, media. On a typical legacy commerce platform, that is an overnight job: three hours or more, scheduled for the quiet window because it cannot be done in the working day.

Comparison chart: importing a 1,000,000-product catalogue takes 3+ hours on a typical legacy platform versus about 40 minutes on VBWD
The same task on modern, self-hosted infrastructure. The VBWD figure is an internal import benchmark; legacy times vary by platform and integration depth.

On VBWD, the same million-product import lands in around 40 minutes. We put the caveat on the chart deliberately: that's our benchmark, not a laboratory-controlled industry certification, and your mileage depends on your data. But the order-of-magnitude difference is the point, and it isn't cosmetic. When a full catalogue re-sync stops being an overnight operation and becomes a coffee-break one, the whole rhythm of the business changes. You can reprice for a market shift the same morning. You can test a merchandising idea before lunch instead of next week. Speed at the infrastructure layer quietly becomes speed at the strategy layer.

The honest part

Here is what a careful operator is already thinking, so let's say it plainly: a platform that imports a million products in forty minutes but is younger than the incumbent is trading maturity for modernity. That trade is real, and it is not free. Legacy platforms carry two decades of edge cases already discovered and patched. A modern, self-hosted core has fewer generations of accumulated cruft — and also fewer generations of accumulated scar tissue.

The strategic question is not "which is more mature." It is "which class of problem do you would rather own." With the incumbent, you inherit a mature system whose costs compound every year and whose architecture you cannot change. With a modern core, you accept a younger platform in exchange for speed, a codebase you can actually read, and an architecture built for the compliance and sovereignty realities of this decade rather than the last one. For a great many businesses, the second problem is the better one to have. For some — the ones who need a specific, battle-tested edge case that only twenty years of patches can provide — it isn't. Knowing which you are is the entire decision.

What "modern and self-hosted" actually buys

VBWD is a full-stack SDK: one self-hosted Python backend core, a Vue/TypeScript web front end, and native iOS and Android SDKs, with a plugin system where every behaviour — payments, subscriptions, catalogue, CMS, booking, chat — switches on or off without a restart. The core is deliberately agnostic; the differentiation lives in plugins you control.

The VBWD platform home page describing a fullstack self-hosted SDK for SaaS and digital sales

Self-hosted means the data, the customers, and the billing relationship are yours — not a tenant on infrastructure you don't govern. In 2026 that is not an ideological preference; it is increasingly a legal and commercial one, and we've written separately about what the NIS2 era does to that calculus. And because it's source-available under BSL 1.1 — free for commercial use while annual VBWD-attributable sales stay below the value of 6.7 BTC per year — you can evaluate it against your real workload before any commercial conversation happens.

The leverage most people miss

The quiet implication of all this is about who can now serve whom. When the infrastructure does the heavy lifting — the identity, billing, tax, admin, catalogue and mobile surface arriving already wired together — a small, sharp digital studio can credibly stand up and operate the commerce or booking stack of a business far larger than itself. The moat that used to require a large systems-integrator engagement shrinks to something a focused team can hold. If you are that studio, this is your opening. If you are the enterprise, it means your options are no longer limited to the handful of vendors who could afford the old complexity.

Where to take this next

If any of this resembles a conversation happening inside your own organisation — the renewal you're not sure about, the integration that never quite finishes, the overnight jobs that define your operational tempo — the useful next step is a specific one, not a generic demo. We set up enterprise installations against a real workload, so the question stops being "is this credible in the abstract" and becomes "how does it handle our catalogue, our compliance surface, our integrations."

Request an enterprise installation → Tell us what you're running today and what it's costing you to keep running it, and we'll show you the same workload on modern, self-hosted infrastructure. No obligation beyond seeing the numbers for yourself.