Every digital agency eventually runs into the same ceiling. Revenue is a function of hours, hours are a function of headcount, and headcount is expensive to add and painful to shed. Build an online store for a client on Shopware, a catalogue on Magento, a product-information system on a PIM, and you are paid once, for the time it took. The asset you created goes on generating value — for the client. You move on to the next brief, selling the same hours again. It is an honest living, but it is a treadmill, and the treadmill has a top speed.
The more interesting question, and the one a growing number of developers and agencies are now asking, is this: what if the software you build could pay you for as long as it runs, rather than only for the time it took to write? That is the business model VBWD is built to enable — and understanding it means looking past the technology to the economics underneath.
Consider the arithmetic of a conventional integrator. A ten-person shop bills, optimistically, perhaps 1,400 productive hours a month across its team. At a healthy blended rate, that is a respectable services business — but it is a linear one. To double revenue, you roughly double the team, and with the team come the costs, the management overhead, and the utilisation risk of every empty seat. Growth is addition, never multiplication. Worse, the model is inherently one-off: each engagement ends, and the recurring value the software produces accrues to the client's balance sheet, not yours.
The frameworks that dominate this world — Shopware, Magento, commercetools, the various PIM and DXP platforms — are excellent tools, but they are, commercially, sold to the agency's client. The agency's role is implementation. Its compensation is time. Nothing in the architecture invites the builder to own a piece of what the software goes on to earn.
VBWD inverts the relationship. It is a self-hosted, source-available platform that ships the parts of a commercial product every business needs and no one wants to rebuild — accounts, subscription billing, invoicing, a content system, multi-provider payments, an admin backoffice — and then gets out of the way so you can build the thing that is actually yours. The pitch is not "we help you deliver a client project faster." It is "build your own product on top of this, put it in front of a market, and earn on every transaction it processes for as long as it runs."
That is a different business entirely. Instead of selling the hours it takes to build a booking system for one clinic, you build a booking product once and sell access to a hundred clinics, taking a recurring cut of each. Instead of implementing a shop for a single merchant, you operate a niche marketplace and earn on the volume that flows through it. The subscription and billing engine that would have been the client's asset is now yours, and it bills while you sleep. The unit of value shifts from an hour sold to a transaction owned — and transactions, unlike hours, compound.
The mechanism that makes this concrete is what VBWD calls its connect-and-referral rail — and it is worth being precise about how it works, because "earn a percentage" is easy to say and hard to build. VBWD's design runs two revenue streams on a single hub instance. The first is entitlement: you sell subscriptions, plans, or licences to your product, and the platform's pricing engine handles multi-currency amounts and per-line tax without the rounding errors that quietly corrupt home-grown billing. The second is a payout rail modelled on the connected-account pattern popularised by Stripe Connect: partners onboard, referred sales are attributed to them, and commission accrues through a disciplined lifecycle — pending, confirmed, and, crucially, reversed when a payment is refunded or charged back, so you never pay out on money that was returned. The payout itself flows through a provider-agnostic port, with the first implementation on Stripe and others able to slot in behind the same interface.
The importance of that "reversed" state is easy to underestimate. Any referral or marketplace business that pays commission before it accounts for refunds is one bad month from paying out money it never kept. VBWD treats the commission ledger as a state machine, idempotent by design, because that is the difference between a payout system you can run at scale and one that leaks.
There is a second, less obvious income stream, and it is the one that turns a product business into a genuine platform business: the provision you can earn on the payment volume you generate. Payment providers compete hard for processing volume, and many operate partner or revenue-share programmes that pay a portion of their fees back to the platforms and integrators that route transactions to them. Because VBWD treats payment providers as swappable plugins behind a common adapter — Stripe, PayPal, YooKassa today, more able to follow — you are positioned not as a single merchant on someone else's checkout, but as the operator of the checkout through which many merchants transact.
That positioning is what makes payment-provider provisions attainable. When you run a marketplace or a multi-tenant product on VBWD, the aggregate volume flowing through your instance is yours to negotiate on. The platform gives you the technical seam — one integration surface, many providers, all the volume in one place — and the commercial opportunity follows from the aggregation. You are no longer just building the store; you are the rail the money runs on, and rails get paid.
If subscriptions are how you bill for access and commissions are how you earn on others' sales, the token economy is how you bill for usage — and it is the piece that makes VBWD products scale in value without scaling in effort. VBWD ships a token, or credit, system: customers buy bundles of tokens, and your product decrements them as they consume whatever you meter. An AI generation costs a token; an export costs a token; a premium action costs a token. You set the price of the bundle and the cost of the action, and the spread is your margin.
This matters for three reasons. First, it prices fairly: heavy users pay more, light users pay less, and you are never in the position of a flat fee that either overcharges the casual customer or subsidises the power user at your expense. Second, it monetises the very features — AI assistants, data exports, automations — whose costs would otherwise scale unpredictably; tokens turn a variable cost into a billed line item. Third, it doubles as a loyalty and retention instrument: credits for referrals, bonus tokens for annual commitment, rewards for engagement. A token balance is a reason to come back. Sold well, the token economy converts every metered feature in your product into a small, recurring revenue engine that runs on infrastructure you have already built.
None of this would be reachable if the platform were rigid. VBWD's defining architectural decision is that its core is deliberately generic and every domain-specific behaviour lives in a plugin. The core knows about accounts, money, and content; it knows nothing about bookings, datasets, pharmacies, or courses. Those are plugins you add without touching the core, extending the system through published seams — an event bus, dependency injection, typed registries — rather than by forking it. You can read how that agnostic-core architecture is enforced, and browse the plugin catalogue that already exists.
For a builder, the practical consequence is optionality. The same underlying platform becomes a clinic patient portal, a boutique-hotel booking site, a data marketplace, a software store gated on private repositories, or a subscription media product — each a plugin constellation on the same billing, payments, and account foundation. You are not betting the business on a single vertical; you are acquiring the ability to launch several, cheaply, and let the market tell you which deserves more investment. A product that does not work is a plugin you disable, not a company you wind down.
The financial case rests, in the end, on marginal cost. A services business has a brutal one: every additional unit of revenue requires an additional unit of someone's time. A product business built on VBWD has almost none. Once the plugin exists and the instance runs, the hundredth customer costs you very little more than the tenth, and the platform's self-hosted economics keep the fixed side modest — the whole stack runs on a small server, so your infrastructure bill grows far more slowly than your revenue. A single backend serves web and native mobile clients from one source of business logic, so you are not maintaining three implementations of the same subscription rules.
That is the multiplication the agency model never offers. Add a product to your portfolio and it earns independently, in parallel, on the same foundation. Each one bills, meters, and — through the connect rail and payment provisions — takes its cut of throughput, without adding proportionally to your cost base. Revenue and effort, welded together in the hours model, finally come apart.
None of this is passive income, and it would be a disservice to pretend otherwise. Building a product is harder than delivering a brief; you trade the certainty of an invoice for the risk and the upside of ownership. You operate the infrastructure — uptime, backups, security, updates — and you carry the compliance obligations that come with handling payments and, if you run payouts, with your provider's know-your-customer and money-transmission requirements. Payment-provider provisions are real but negotiated, and depend on volume and on each provider's partner terms; they are an opportunity the architecture unlocks, not a switch it flips. And the platform's licence, the Business Source License 1.1, is generous — free for commercial use until your VBWD-attributable annual sales exceed the value of 6.7 BTC, after which a commercial licence applies, with the code converting to Apache-2.0 on its change date — but it is a licence to read, not a detail to gloss. You can see the full terms and tiers on the pricing page.
What VBWD provides is the machinery: the billing, the two revenue rails, the token economy, the swappable payments, the plugin architecture that lets one foundation carry many products. What it does not provide is the market, the product judgement, or the operational discipline. Those remain the founder's job — which is exactly as it should be, because they are also where the returns come from.
The frameworks of the past two decades made agencies efficient at selling hours. VBWD is built for a different ambition: to let the people who understand a market build the product that serves it, and to earn on that product's throughput rather than on the clock. For a developer tired of trading time for money, or an agency that has felt the ceiling of the billable-hour model, the proposition is straightforward. Stop building assets that appear on someone else's balance sheet. Build them on infrastructure you own, put them in front of a market, and take your percentage of every transaction they process — for as long as they run.
To see how the billing engine, connect rail, and token economy fit together in practice, start with the developer documentation and the billing and plugin references.