You have the idea. It's good. You can see the product in your head, and you know who would pay for it. So you open a terminal, start a new project, and then spend the next nine months not building it.
You build authentication instead. Then roles and permissions. Then a subscription model, and the state machine that goes with it — trial, active, past due, cancelled, reactivated. Then invoices, because customers need them. Then tax, because invoices need it. Then webhooks from the payment provider, and the reconciliation logic for when they arrive twice or not at all. Then the entitlement check that answers the only question your product actually cares about: is this person allowed to do this thing right now? Then an admin panel, because someone has to issue a refund at some point. Then you do a chunk of it again for the mobile app.
Your idea is still sitting there, untouched, waiting.
The reasonable objection in 2026 is: surely AI fixed this? Claude Code can write a subscription service in an afternoon.
It can write a subscription service in an afternoon. That's not the same as having one. Here's what the afternoon doesn't cover.
Proration when someone upgrades mid-cycle. Dunning when a card fails on the third retry. What happens to entitlements during the grace period after a failed payment but before cancellation. Tax rates that differ by customer country and by product type, and the discount line that has to carry negative tax per rate or your invoice totals silently drift. Idempotency when the payment provider sends the same webhook three times. What the admin sees when a customer disputes a charge from four months ago. Refund handling that doesn't corrupt the invoice ledger. The audit trail your first enterprise customer will ask for.
None of that is hard in the sense of being intellectually difficult. It's hard in the sense of being enormous, boring, and unforgiving — a thousand small decisions where being 95% right means being wrong, because the 5% is money. AI helps you write each piece faster. It doesn't tell you which pieces you forgot, and it doesn't shorten the months of discovering the edge cases the hard way, in production, with real customers' money.
Realistically, a small team building this properly — backend, billing, entitlements, admin, and mobile — is looking at the better part of a year. Even with excellent tools. Even with Claude Code. That's not pessimism; it's an inventory.
Faced with that, teams usually pick one of two escape routes, and both have a bill attached.
Option one: build it anyway. You spend the year. Your competitors ship. You learn a great deal about VAT.
Option two: bend an e-commerce platform into a shape it was never meant to hold. This is the more common trap, and the more insidious one. E-commerce platforms are built around a fundamentally different noun: an order for a physical thing that ships once. Your product is a recurring relationship with an entitlement attached. You can force it — everyone does — and the result is a permanent tax: a plugin for subscriptions, another for the customer portal, a webhook glued to your real backend to sync who's allowed to log in, and a growing pile of code whose only job is translating between the platform's model of the world and yours. You didn't skip the work. You moved it somewhere worse, and you're paying rent on it.
VBWD exists because there's an obvious third answer: don't adapt something built for a different purpose, and don't rebuild the same foundation every team rebuilds. Start from a framework where the plumbing is already there and already the right shape, then add the part that's actually yours.
What's in the box:
payment.captured or invoice.paid instead of you threading calls through someone else's checkout code.And, because it matters in 2026: the repository ships with instructions for AI coding agents, so Claude Code lands in a codebase that tells it how to extend correctly rather than guessing.
A framework that gives you everything is usually a framework that owns you. VBWD's answer is an architectural rule enforced in the codebase itself: the core is agnostic; only plugins are gnostic.
In practice this means the core knows about users, money, events, and entitlements — and knows nothing whatsoever about tarot readings, gyms, datasets, pharmacies, or whatever your vertical is. Your domain lives in a plugin. The plugin registers its routes, its models, its migrations, and its providers through seams the core already exposes, and the core never learns your vocabulary. There's an automated check that fails the build if core code so much as references a plugin.
That rule is the whole point. It's why adding your feature doesn't mean forking the billing engine, and why upgrading doesn't mean re-applying your patches. You're not modifying the platform. You're extending it at the places designed to be extended — and everything else stays someone else's problem.
Clone it, install it, run it:
git clone https://github.com/VBWD-platform/vbwd-sdk-public.git vbwd
cd vbwd
./recipes/dev-install-ce.sh
make upThe recipe handles the clone order, the submodules, the build sequence, and the database. When it finishes you have a running platform: API, database, cache, a user app, an admin backoffice, migrations applied, roles seeded.
Then you configure — your plans, your prices, your payment provider, your access levels — and you write the plugin that contains your actual idea. That's the day-one difference: your first line of real code is your product, not class User.
It is not magic, and this would be a worse article if it pretended otherwise.
It's self-hosted: someone runs the server, applies updates, takes the backups. That's a real cost, and for some teams a managed SaaS with a monthly bill is genuinely the better trade. You'll also need to learn the platform's seams — a framework that does this much has a shape, and working with the shape is faster than fighting it. If your product isn't a recurring relationship with an entitlement — if you really are shipping boxes — a real e-commerce platform is the right tool and you should use it.
And "clone, install, configure, done" is the foundation being done, not your product. Your idea still needs building. That was always the interesting part; it's just no longer the part you get to nine months late.
Every small team with a good product idea currently pays the same entry fee: the better part of a year rebuilding a foundation that hundreds of other teams already built, badly, in slightly different ways. That fee kills ideas — not because they were bad, but because the runway ran out during the plumbing.
The foundation is not where your advantage lives. Nobody ever won a market because their invoice numbering was elegant. Clone the framework, install it, configure it, add your plugin — and spend the year on the thing only you can build.
VBWD is source-available under BSL 1.1 and free for commercial use while your VBWD-attributable sales stay under the value of 6.7 BTC a year. Start with the developer docs, look at the architecture, browse the plugin catalogue, or go straight to the source on GitHub.