How I turned access control into an engagement funnel for 400+ vendor perks
Bridge Perks Portal — Product Designer & Developer — 2025–2026
perks.brdg.app400+
Perks Available
100+
Vendors Integrated
300+
Whitelisted VC Domains
AA
WCAG Accessibility
Setting the stage
Bridge needed to turn a generic vendor portal into a product that reinforced VC exclusivity
Bridge is a platform connecting VC firms with their portfolio companies. They had an existing perks marketplace powered by GetProven — a third-party vendor portal offering cloud credits, dev tools, marketing spend, and HR platforms to startup founders. But it was a generic iframe with no access control, no brand alignment, and no VC-specific flows.
I owned the entire product — from discovery and access control UX strategy through design system creation, visual design, and production development. I used Claude Code as my development partner, writing detailed design specs that the AI implemented while I reviewed every output against my design intent.
Bridge perks ecosystem — the missing layer
What Bridge had
VC social graph
Portfolio relationships
GetProven vendor API
Basic perk listings
What was missing
Domain-gated access control
Brand alignment with Bridge
API failure resilience
Admin marketplace tooling
What I built
Tiered access gate system
Full Bridge design system
Cached fallback architecture
7-section admin dashboard
My role
Solo Product Designer + Developer
End-to-end ownership: research, UX strategy, design system, visual design, production code
AI partnership
Claude Code as Dev Partner
Wrote detailed design specs; AI implemented while I reviewed every output against design intent
Timeline
~3 Months
Dec 2025 – Feb 2026. Next.js 14, TypeScript, Tailwind CSS, Supabase
The constraint: The perks portal had to feel like a Bridge product, not a white-labeled third-party tool. And access control — the thing that makes these perks exclusive — had to feel motivating, not frustrating. Every design decision flowed from this constraint.
What was broken
Without meaningful access control, a perks marketplace is just another coupon site
User perspective
Founders navigated a third-party interface that didn’t feel like Bridge. There was no sense of exclusivity — anyone could browse and redeem, which undermined the core value proposition of being VC-backed. When GetProven went down, founders saw blank pages with no explanation.
Business perspective
The perks program was a key retention lever for Bridge’s VC network. If portfolio company founders didn’t feel the perks were exclusive and valuable, VCs had less reason to stay on Bridge. The generic portal was actively undermining the network’s value.
Technical perspective
The upstream GetProven API had reliability issues, and there was no caching layer. Denied users received no context about why they were restricted or how to get access. Admin visibility into the marketplace was nonexistent.
Before — GetProven iframe
Generic portal. No exclusivity. No brand. No resilience.
After — Bridge Perks Portal
VC-gated exclusivity. Bridge brand. Resilient architecture.
Research & synthesis
I started with the access control problem because it was the one nobody had solved well
Before designing any screens, I needed to answer four questions that would determine the shape of the entire product. Each one looked like a technical problem on the surface, but was actually a UX design challenge.
The core insight came early: access to perks IS the product. Without meaningful access control, the portal is just another vendor directory. The design challenge was making exclusivity feel motivating for both approved and denied users.
Research → synthesis process
User personas I designed for
Startup Founders & Employees
VC-backed company team members
Browse and redeem exclusive perks — cloud credits, dev tools, marketing spend, HR platforms.
Quick browsing with filters
Clear redemption flow
Understand access status instantly
VC Firm Team Members
Partners, associates, talent partners
Access perks themselves and manage their portfolio companies’ whitelist.
Self-serve access
Portfolio company management
See what perks their network offers
Bridge Admins
Platform operations team
Manage the full marketplace — providers, vendors, offers, access requests, analytics.
Bulk operations
Vendor health monitoring
Access request review with context
Design principles I established
Exclusivity as engagement
Access control should feel motivating, not punishing. Showing restricted content builds desire; hiding it kills both desire and trust.
Trust through designed delay
Instant verification feels cheap for a gated product. Intentional animation communicates rigor and reinforces the value of what’s behind the gate.
Bridge-native experience
Every screen must feel unmistakably like a Bridge product. No generic white-label aesthetics. Full design token alignment.
Graceful degradation
When the upstream API fails, users see cached data with clear staleness indicators — never a blank page or error screen.
Architecture decisions
Four design decisions that shaped the product
Access control is typically treated as a binary gate — you're in or you're out. I designed a tiered system with distinct UX for each state, turning the restriction itself into an engagement mechanism. Each decision below required choosing the harder path because the obvious solution undermined the product's core value.
Trust through delay
The 8-second access gate — a scanning metaphor that builds trust
The obvious approach: check the user's email domain against the whitelist and show an instant result. But instant "approved" feels cheap for a gated product. I designed an 8-second scanning metaphor that communicates "we're checking something real."
VC logos cycle through a conveyor belt while the user's email domain is verified against 300+ whitelisted domains. Pulsating rings, a progress bar, and sequential status messages create a sense of intentional verification. The technical check is instant, but the animation communicates rigor and reinforces exclusivity.
Access gate — three result states
Granted
Green check · Email matches whitelisted VC/portfolio domain
Full access to all perk details and redemption links. VC affiliation shown as trust badge.
Browse Mode
Eye icon · Work email not in whitelist
Can browse all perk cards freely. Blocked at redemption with access request flow.
Explore Mode
Compass icon · Personal email (Gmail, Yahoo, etc.)
Same browse access. Prompted to re-enter work email for domain verification.
Why this matters: This applies the Aesthetic-Usability Effect — users perceive a more carefully designed experience as more trustworthy. The 8-second delay is "security theater" in the best sense: it makes the real verification (which is instant) feel rigorous. It respects prefers-reduced-motion and skips entirely on return visits, applying Jakob's Law — repeat users get the fast path they expect.
Engagement architecture
Browse mode for denied users — show the catalog, block at redemption
The standard approach: denied users see a locked door. "You don't have access. Request it." This kills engagement instantly because users can't evaluate whether access is worth requesting.
I made the deliberate choice to let denied users browse ALL perk cards freely — but block at redemption. Detail pages show blurred content with a modal overlay explaining how to request access. This was counterintuitive to stakeholders, but the logic is clear: you can't want what you can't see. Showing the catalog builds desire; hiding it kills both desire and trust.
What denied users CAN do
What denied users CANNOT do
Restricted modal — design system component
Mobile
Full-screen bottom sheet
Desktop
Centered card with backdrop blur
Interaction
Focus-trapped, keyboard-dismissible, exit animations
Content
Explains restriction + path to access in 3 steps
The engagement funnel
Why this matters: This applies the Peak-End Rule — by letting users explore freely before hitting the restriction, the "peak" of their experience is discovering valuable perks, not being told "no." The restriction at redemption (not at browse) creates the IKEA Effect in reverse — users who invested time browsing are more motivated to request access than users who were blocked at the door.
Friction reduction
Interactive VC directory — replacing text input with single-tap selection
The biggest friction point in access request flows is the open-ended "who's your VC?" text input. Users misspell fund names, use abbreviations, or don't know which entity to list. Every failed submission is a user lost.
I replaced the text input with an interactive directory — a searchable grid of 300+ approved VCs with logos. Clicking a VC pre-fills the request form, reducing the entire question to a single tap. Discovered investors are shown as green chips, auto-detected from Bridge's API.
Access request flow — 7 steps
- 1User sees restricted modal on perk detail page
- 2Clicks "Request Access" — opens multi-step flow
- 3Discovered investors shown as green chips (auto-detected from Bridge API)
- 4Interactive VC directory: searchable grid of 300+ approved VCs with logos
- 5Clicking a VC pre-fills the request form — single tap, not a text input
- 6Form collects VC contact info for admin verification
- 7Admin reviews with expandable details and colleague lookup
Why this matters: This applies Hick's Law — by presenting a visual directory instead of an open text field, I transformed an unbounded decision (type any name) into a bounded selection (pick from a grid). The auto-detected green chips apply Recognition over Recall — users don't have to remember their VC; the system surfaces it. This also follows Fitts's Law — a large, clickable VC card is faster to hit than typing a name in a small input field.
Resilience architecture
Designing for API failure — cached fallback with staleness indicators
The upstream GetProven API had reliability issues — and previously, outages meant founders saw blank pages. The naive solution: show an error message. The better solution: design a fallback experience that prioritizes user continuity over data freshness.
I designed a cached data layer using Supabase tracker tables that stores the last known good state. When the API is down, users see slightly stale perks with clear visual indicators — never a blank page. The design challenge wasn't technical caching; it was communicating staleness honestly without undermining trust.
Live
API responding
Status
Fresh data from GetProven. No indicators needed. This is the normal state.
Cached
API down, data < 24h
Status
Amber "Showing cached data" banner. Users can browse and plan. Data is slightly stale but functional.
Stale
API down, data > 24h
Status
Enhanced warning with timestamp. Users know the data may be outdated. Admin gets sync failure alerts.
The resilience chain
Why this matters: This applies the Visibility of System Status (Nielsen's #1 heuristic) — but elevated from error messages to honest communication. The amber/red color system follows Pre-attentive Processing — users process color faster than reading text, so staleness registers visually before the banner is even read. Slightly stale perks are infinitely better than a blank page, applying Postel's Law to UX — be liberal in what you accept (stale data), conservative in what you show (clear indicators).
Design foundation
The design system I built for brand alignment
I created a complete design token system used across 60+ files — ensuring every screen felt unmistakably like a Bridge product. Tokens were codified as direct hex values, not abstraction layers that could drift.
Color palette — 20+ named tokens
Royal Blue
#0038FF
Charcoal
#0D1531
Slate
#F9F9FA
Mist
#E8EAF0
Kelly
#0EA02E
Honey
#E19500
Ruby
#E13535
Typography
Mulish
Weights 400–700, consistent sizing hierarchy
Components
Button + Badge + Card + Input
5 button variants, 6 badge colors, pill-shaped inputs
Animation
6 Tokens
fade-in, fade-in-up, scale-in, scale-out, fade-out, shimmer
Radii
Contextual
xl for cards, full for buttons/search, 4px for badges
Why this matters for AI development: The design system wasn't just documentation — it was the instruction set for Claude Code. Every CSS custom property, animation token, and component spec became a constraint that kept AI-generated code on-brand. Without this system, the output would have drifted into visual inconsistency.
Production features
Every page designed with intent — from landing to admin dashboard
Everything below is live at perks.brdg.app and actively used by Bridge's VC network. I owned the design end-to-end and partnered with Claude Code for implementation, writing detailed specs and reviewing every output against my design intent.
Landing Page
Scroll-triggered animations with staggered fade-in-up, count-up stats, infinite logo marquee. Three-step "How It Works" with animated connector lines. Gradient CTA section.
Design rationale: The page communicates exclusivity and breadth. Logo marquee signals "real companies use this." Count-up stats make the scale tangible. Gradient CTA creates urgency without aggression.
Perks Listing
Dual view modes: Grid (card layout) and By Vendor (accordion groups with smooth CSS grid height animation). Combined filter dropdown with 4 cascading categories. Three-tier default sort.
Design rationale: Dual view maps to two browsing behaviors: "I know what I need" (grid + filters) vs. "I want to see what Stripe offers" (vendor view). Three-tier sort surfaces best content without user action.
Perk Detail Page
Two-column layout: offer context + redemption sidebar. Value pills showing deal value, discount, and estimated savings. Related perks grid. Glassmorphic hero with backdrop blur.
Design rationale: Value pills translate abstract "perks" into concrete dollar amounts — the key conversion element. For denied users, blurred content + modal creates FOMO without frustration.
Admin Dashboard — 7 Sections
Analytics with redemption metrics. Offer and vendor tracking tables with search, filters, sync-to-DB. CSV bulk upload with drag-drop, validation, preview, confirmation. Access request review with colleague lookup. Vendor group management. Provider config and audit log.
Design rationale: Designed for operators. Every table has search and filters because data sets are large. CSV upload has validation AND preview because bad imports break the marketplace. Access review surfaces colleague info for faster decisions.
Accessibility (WCAG 2.2 AA)
Micro-interactions I specified
Access gate: 8-second sequence with 5 animation layers
Card hover: translateY(-2px) + shadow elevation (200ms)
Accordion: CSS grid height animation for smooth expand/collapse
Logo marquee: Infinite scroll, pauses on hover
Outcome & results
Shipped to production, serving Bridge's entire VC network
400+
Perks Available
From 100+ vendors
300+
Whitelisted Domains
VC + portfolio companies
7
Admin Sections
Full marketplace operations
AA
WCAG Accessible
Across all user flows
Access control is a UX design challenge, not just a technical one
The difference between "you can't use this" and "here's how to get access" is entirely design. The tiered system turned a rejection into an onboarding funnel.
Showing restricted content builds desire; hiding it kills it
Letting denied users browse freely but blocking at redemption was counterintuitive — but it's the right UX. You can't want what you can't see.
Design for failure, not just success
The cached data fallback meant users never saw a blank page during API outages. Designing the failure state was as important as designing the happy path.
A designer who ships is a designer who learns faster
Owning the full stack — from research to production — meant I could iterate on UX decisions in real-time, with real users, without waiting for handoffs.
Division of labor — designer + agentic AI
Me (Product Designer)
Product strategy & scope definition
Access control UX architecture
Design system tokens & specifications
UX flows & interaction patterns
Visual hierarchy & layout decisions
API resilience design strategy
Claude Code (AI Partner)
TypeScript implementation
Supabase database & queries
GetProven API integration
Next.js routing & server components
Caching layer & sync engine
Admin dashboard tables & forms
Lessons learned
What I'd do differently next time
Invest in the admin experience earlier
The 7-section dashboard grew organically as operational needs surfaced, and some of the information architecture could be tighter. I'd build analytics into the admin panel from day one — tracking which perks get redeemed most would help Bridge prioritize vendor relationships.
Prototype the access gate animation sooner
The 8-second scanning animation was the most debated design decision. Getting stakeholder buy-in earlier through a quick prototype would have saved iteration time. The final result validated the approach, but the path there was longer than necessary.
The bigger takeaway: Access control is fundamentally a UX problem. The technical implementation of domain gating is straightforward — the hard part is designing an experience where being restricted doesn't feel punishing. The tiered browse mode was the most debated design decision, and it turned out to be the most important one.
Want to see Bridge Perks Portal live?