Designing the Systems That Made Brava Acquirable
As the founding product designer, I owned product strategy, monetization, and trust-critical workflows. Taking Brava from concept to acquisition.
Brava at a Glance
Brava was a commission-tracking platform for independent travel advisors in a trust-poor industry.
As the founding product designer, I owned monetization, trust systems, and core platform architecture, helping move Brava from concept to an acquirable product.
User Frustrations
The Decision
The Bet: Monetization Without Breaking Trust
Brava entered an industry where monetization is often punitive. Independent travel advisors are typically charged upfront fees, commission cuts, and foreign transaction penalties before they ever see a dollar earned.
From the start, I believed charging early would kill adoption, but not charging at all would undermine legitimacy. “Free” raised more skepticism than confidence.
As the founding product designer, I recommended a delayed monetization model: advisors would only pay once their first commission was successfully earned. This reframed Brava from another gatekeeper into a partner aligned with advisor success.
The risk was real. Waiting months to charge meant absorbing skepticism, uncertainty, and pressure to prove legitimacy fast.
We shipped the full subscription flow in under two weeks, end-to-end. Pricing logic, edge cases, failure states, and Stripe integration were all designed, tested, and validated in production.
Activation increased, but something unexpected surfaced next…
The Consequence:
Trust Became the Bottleneck
After releasing the subscription flow, advisor activation increased, but trust did not resolve itself. It shifted.
Pricing skepticism (“What’s the catch?”) turned into legitimacy questions:
Can Brava actually work with my suppliers?
Is this IATA number real?
Will commissions really be paid out?
Advisors were actively searching for supplier names before committing to the platform. The absence of visible supplier support created hesitation, even as the monetization model aligned with their interests.
At this point, the problem was no longer pricing. It was proof.
Without a clear way to validate Brava’s supplier coverage, the product risked stalling at the moment of conversion. Trust had to be made visible, not explained.
User insights
Designing Proof at Scale
Suppliers As Trust Infrastructure
At this point, it was clear that trust could not be handled through messaging, onboarding copy, or support responses. It needed to be embedded directly into the product.
Advisors weren’t asking for a convenience feature. They were asking for verification.
I designed the suppliers experience as a foundational system, not a surface-level list. Its purpose was to make Brava’s legitimacy immediately inspectable, without requiring explanation or sales intervention.
This required solving several problems at once:
Modeling suppliers as a first-class data entity
Supporting recognizable, high-confidence brands (hotels, cruises, tour operators)
Designing for scale as supplier coverage expanded
Creating a structure that could later support global search and cross-entity relationships
The suppliers page became a visible proof layer. Advisors could immediately confirm whether Brava worked with the suppliers they already trusted, reducing skepticism at the moment of commitment.
Once suppliers were introduced, it became obvious that discoverability would matter next. Advisors wanted to search across suppliers, bookings, and communications in one place.
Trust had evolved from a perception problem into a platform capability.
Second-Order Effects:
Suppliers as Trust Infrastructure
Introducing suppliers as a first-class system immediately exposed the next constraint: discoverability.
Advisors didn’t think in isolated screens. They thought in relationships. A booking was tied to a supplier. A commission was tied to a booking. Verification lived across email threads, reference numbers, and supplier names.
With suppliers now modeled as structured data, it became clear that search could no longer be scoped to a single entity. Advisors needed to move fluidly across suppliers, bookings, and communications without changing context.
I designed global search as a connective layer across the platform. Not as a convenience feature, but as an organizing principle that allowed advisors to validate information, answer questions quickly, and trust the system under real operational pressure.
This reinforced a consistent pattern across Brava:
Monetization aligned incentives
Suppliers established legitimacy
Search connected the system into a coherent whole
Each decision reduced cognitive load, removed uncertainty, and increased confidence that Brava could support real-world workflows at scale.
Why This Mattered Beyond Features
By this stage, Brava was no longer a collection of useful screens. It was a system with internal logic, traceability, and credibility.
For advisors, this meant:
Faster answers without chasing emails
Clearer visibility into commissions and supplier relationships
Confidence that Brava could be trusted with real revenue
For the business, it meant:
A platform that could withstand scrutiny
Reduced reliance on manual support and explanation
A product architecture that supported growth and transition
Designing these systems under real constraints helped move Brava from an early-stage product, into something structurally sound and acquirable.
Closing Reflection
As the founding product designer, my role extended beyond interface design. I was responsible for identifying where trust would break, where systems would need to scale, and which decisions would compound over time.
Brava’s acquisition wasn’t the result of a single feature. It was the outcome of designing aligned systems that earned trust, supported real workflows, and made the product viable to own.
