⚡ VBWD

Architecture as a business advantage

Most SaaS codebases get slower as they grow — every feature touches the core, every client needs a fork, every release is a gamble. VBWD is built the opposite way: a small, hardened core with an open set of plugins around it. That one decision is what lets you move fast for years — ship a feature without touching the core, run a hundred tenants from one codebase, and onboard a client as a config diff instead of a fork.

Three runtimes. One contract. Plugins everywhere.

Every corner of VBWD is its own runtime with the same plugin contract. A feature lights up by shipping a coordinated trio — a backend plugin (API + data model), an fe-admin plugin (configuration UI) and an fe-user plugin (customer surface) — or any subset; they are independent.

The backend ships the core, then steps aside for plugins

• Flask blueprint auto-mounted at /api/v1/<plugin>/* on enable, unmounted on disable.
• SQLAlchemy 2.0 models + Alembic migrations tied to the plugin lifecycle.
• register_event_handlers(bus) — subscribe to subscription, payment, checkout and security events. No polling.
• Emit your own domain events; other plugins consume them without direct imports.
• Line-item handlers plug into checkout totals: discounts, taxes, shipping, token deductions.
• Shipping providers, categories + routing, declarative permission scopes in the RBAC matrix.
• Namespaced get_config / set_config, JSON-schema-validated, secrets via env indirection only.

A finite, named set of aggregates — not "anything goes"

Every domain has a small, named set of SQLAlchemy 2.0 entities. Plugins add their own; the core never grows by accretion.

A typed DI container. No globals. No accidental singletons.

dependency-injector wires repositories, services and infrastructure (DB session, Redis, event bus, secrets). Every consumer asks for what it needs through constructor injection; in tests, providers are swapped for in-memory repositories, a fake bus and a deterministic clock — no service knows it is mocked.

• AuthService, UserService, SubscriptionService, InvoiceService, RefundService, TokenService.
• PluginService, WebhookService, EmailService, EventDispatcher.
• One repository per aggregate; multi-aggregate writes orchestrated in services, never in ORM session magic.

SOLID as contracts, not decoration

• S — routes validate, services orchestrate, repositories persist, models describe.
• O — extend by adding plugins, never by editing core.
• L — every payment provider is interchangeable; checkout never branches by provider.
• I — the plugin SDK is segregated: emitting events needs no knowledge of line items.
• D — services take interfaces; the container injects SQLAlchemy in prod, in-memory in tests.
• TDD-first — no tests, no merge. DRY — a bug fix happens once. Clean code — no abbreviations.

Defaults that don't get you breached on a Tuesday

• JWT bearer + refresh, per-deploy secret, rotatable without dropping live sessions.
• RBAC roles + access levels; plugins declare their own scopes.
• Per-IP / per-user rate limiting; stricter caps on login + password reset.
• Argon2id hashing; same response on bad-password and unknown-user — no enumeration.
• HMAC-signed outbound webhooks; inbound provider webhooks verified before any state change.
• Idempotency keys on order/capture/refund; full audit log; secrets never in plugin_config.

Read the architecture, end to end

The marketing tour is the short version. The documentation has the full design — and the rest of the platform is one click away.