Mikhail VodopianovProduct & Digital DesignerSelected Work ↙

B2Base

Defining trust and inventory mechanics for a private luxury network

Zero-to-one client project · 2026 · Built, not launched

Role
Product & Digital Designer
Scope
Product definition · Product UIIdentity · Webflow · Print
Market
UAE luxury assets

Overview

B2Base started as an early idea for a private network connecting luxury brokers and asset businesses in the UAE.

I defined the product model behind it: how inventory entered the network, who could access it, when availability became trustworthy, and what information both sides needed before committing to a deal.

The same model was then carried through the full product UI, identity, acquisition website, and sales brochure. The service was fully developed, but the client ultimately chose not to launch it.

B2Base asset detail page showing a Porsche listing, availability, wholesale terms, supplier reputation, and the request action.
Asset detail brings availability, wholesale terms, supplier identity, and the request action into one decision surface.

01

From chats to structured requests

The main problem was not the lack of listings. It was that high-value inventory was still coordinated through private messages, fragmented contacts, and repeated availability checks.

B2Base turned that process into a structured request flow.

Asset businesses could publish idle dates together with wholesale terms. A requester could search by location, dates, and asset, see the verified supplier and relevant deal terms, and submit a formatted request instead of starting another “is this available?” conversation.

B2Base requester flow connecting an informal client request to asset search, a verified supplier, wholesale terms, and a confirmed request.
Open full resolution ↗
Requester flow · From an informal client request to structured search, verified supply, wholesale terms, and confirmation.

02

Availability required confirmation

I treated availability as two different states.

First, an owner published specific idle dates to the partner network. This made the asset discoverable, but did not guarantee the booking.

A requester then submitted a request for specific dates and terms. The owner could review the verified requester, reputation signals, and deal details before confirming or declining it.

Only after this second action did the request become confirmed. This kept inventory useful for discovery without presenting tentative availability as a final commitment.

B2Base availability calendar comparing published, booked, unavailable, and open dates across ten luxury vehicles.
Open full resolution ↗
Availability calendar · Published, booked, and unavailable dates remain visible across the shared inventory.
  1. Published
  2. Requested
  3. Confirmed or declined
Availability state model
B2Base supplier flow showing an idle asset alert, publication to the partner network, a verified broker request, and confirmation or decline.
Open full resolution ↗
Supplier flow · From idle inventory to publication, a verified broker request, and explicit confirmation.

03

One network, changing roles

The network was not limited to a fixed broker-versus-owner relationship.

An asset business could publish its own unused inventory, then act as a requester when its own fleet could not fulfil a client request.

This cross-rent model allowed businesses to source an equivalent asset at a wholesale rate, add their own margin, and keep the end-client relationship.

Inventory visibility was further structured through Private, City, and Vertical pools, allowing access to be organised around selected partners, markets, or asset categories.

  • Private pools
  • City pools
  • Vertical pools
One business can publish and request inventory across three pool types

04

Trust at the point of decision

Verification was embedded directly into the transaction flow through KYB/KYC status, blacklist screening, ratings, reputation, participant identity, and explicit confirmation states.

The goal was to surface trust information where a user was deciding whether to request or accept a deal, rather than separating it into a generic profile or marketing layer.

B2Base participant card showing business identity, rating, review count, and inventory count.
Participant identity and reputation signals.
B2Base client check showing a high-risk result linked to non-payment reports.
Blacklist screening before a deal.
B2Base confirmation message for a specific asset and booking dates.
Explicit confirmation as the final availability state.

05

Built, not launched

The completed work covered the full service interface, identity system, Webflow acquisition website, and sales brochure.

  • full service interface;
  • identity system;
  • Webflow acquisition website;
  • sales brochure.

The product was developed but never launched, so there are no verified adoption, transaction, revenue, or retention metrics.

The case is therefore about defining and building the mechanics of a new network product rather than claiming commercial validation.

The mechanics were built.Commercial validation never happened.