"A secure data room is a feature you rent from someone else." That assumption is exactly backwards, and it is why due-diligence tooling costs what it costs. On VBWD you can stand up an encrypted, self-hosted deal-room service — rooms that expire on a schedule, enforce who-can-see-what down to the document, bill per room, and answer questions about their own contents — by combining five capabilities that already ship in the platform: office, subscription, booking, RBAC, and mcp. The room is the product. Sovereignty over the documents is the differentiator. You never hand the crown-jewel files to a third-party SaaS to get the workflow.

This is the kind of constellation you don't realize is buildable on one stack until you see the pieces line up. Encrypted document storage, metered billing, expiring access, and an AI that reads the room are usually four separate procurement decisions. Here they are four toggles against one agnostic core, and every one of them writes to the same invoice line-item interface.

The room is an encrypted, self-hosted object

The office plugin is a self-hosted, encrypted document suite. That single sentence is the whole thesis of this business. In an M&A process, a legal discovery, or a fundraise, the sensitive material is the point — cap tables, contracts, patient records, board minutes. The moment those documents live inside a vendor's multi-tenant cloud, your customer is trusting that vendor's security model, retention policy, and jurisdiction. Running office on infrastructure you control removes that whole class of trust from the equation. You can host per-client, in-region, on hardware the client audits. For a diligence process, "our documents never left our own tenancy" is not a nice-to-have; it is frequently the thing that closes the deal.

Because the core is agnostic and plugins toggle on and off without a restart, the deal-room offering is a configuration, not a fork. You are not maintaining a bespoke codebase per client. You are running the same platform with office enabled and the room's rules expressed as data.

RBAC decides who sees which page

A data room without granular access control is just a shared folder. VBWD's core ships RBAC and multi-tenancy, so the deal room inherits real roles rather than a homemade permissions hack. In practice that means the sell-side counsel sees everything, a bidding party sees only the tranche released to them, and an outside auditor sees a read-only slice with no export. Roles are defined once and enforced by the core, not re-implemented per document type.

The honest boundary here: RBAC gives you the enforcement machinery, but it does not decide your disclosure policy for you. Which bidder gets which tranche, when a redaction is lifted, what "read-only" should forbid in your legal context — that is your product's judgment and your operator's discipline. VBWD makes the rules cheap to enforce; it does not write them.

Booking turns access into a time-boxed lease

Here is the non-obvious move. The booking plugin exists for appointments, rooms, seats, and time slots — and a deal room is a room with a start and an end. Model each engagement as a booking: access opens when the diligence window opens and closes when it closes. A bidder who dropped out loses the room automatically on the slot's expiry. A "48-hour final review" is literally a 48-hour booking. You get expiring access without building a scheduler, because scheduling is what booking already does.

Pairing booking with RBAC is what makes the room feel alive rather than static: identity decides what, the time window decides when, and the two compose. Extending or revoking access is a booking change, and it is auditable like any other event because the core is event-driven with native signed webhooks — every open, extend, and close can fan out to your logging, your notifications, or the client's own monitoring.

Subscription bills the room, per room

Deal-room pricing is naturally per-engagement: a firm running six live processes wants six rooms billed cleanly, not a seat-count guess. The subscription plugin handles tarif plans, add-ons, checkout, and recurring billing, so you can price a room as a monthly line while the deal is open, add extras (more storage, more seats, an extended window) as add-ons, and stop billing when the room closes. Every charge is an invoice line item against the one shared interface the whole platform uses — the same interface office, booking, and every other plugin declare against. That is why reconciliation stays sane: there is a single point of truth, the invoice line item, rather than four subsystems each keeping their own ledger.

Because VBWD's payment core is provider-agnostic, you settle those subscriptions through whatever rail the client requires — a regional card processor, an invoice-and-wire arrangement, or non-custodial crypto that settles straight to your own wallet. The billing layer does not care which; adding a new gateway is a fraction of the code a classic platform demands.

MCP makes the room answer its own questions

The last piece is the one that feels like science fiction until you wire it. The mcp plugin turns platform capabilities into agent-callable tools — an MCP-native capability server that an AI agent can discover and invoke. Point it at the room, and a permitted user can ask, "Which contracts have a change-of-control clause?" or "Summarize every indemnity over $500k," and get an answer grounded in the actual documents. The agent operates through MCP against the same capabilities and the same access model, so it cannot surface a document the asking user was never allowed to see. The room answers questions, but it answers them within RBAC, not around it.

The caveat worth stating plainly: an LLM over your documents is an accelerant, not an oracle. It will speed up review dramatically, and it will occasionally be wrong or incomplete. For legal and financial diligence, treat its answers as a first pass a human confirms, and make that expectation part of your product's contract with the client. VBWD gives you the secure, permissioned plumbing for the agent; it does not relieve you of the duty to verify.

What you still have to build

None of this is magic, and pretending otherwise would be a disservice. VBWD is a substrate. It gives you encrypted storage, roles, time-boxed access, per-room billing, and an agent seam that already respect one another. You still bring the actual product — the onboarding flow bidders expect, the disclosure playbook, the branding, the trust-and-safety posture — and you still run the operations of self-hosting: backups, key management, uptime, and the audits your clients will ask for. What VBWD removes is the eighteen months of undifferentiated plumbing between "we have documents" and "we have a billable, expiring, self-answering deal room." The proof that this substrate stretches to real verticals is not hypothetical: a tarot app, a dice-market game, a pharmacy shop, and dataset publishing have all been built on it. A deal-room service is squarely within that range.

Start from the public SDK at github.com/VBWD-platform/vbwd-sdk-public, read the plugin and RBAC guides at vbwd.cc/docs, and if you want to talk through a specific diligence workflow, reach us at vbwd.cc/contact.

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.