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.

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.

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.

- Published
- Requested
- Confirmed or declined

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
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.



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.