Back to work
Live in Production

How I unified 13 ATS providers into one trusted talent board for VC networks

Bridge Jobs — Product Designer & Developer — 2026

jobs.brdg.app

13

ATS Integrations

120+

Portfolio Companies Synced

15+

Pages Across 4 Roles

57

UI Components Shipped

Context

Setting the stage

Bridge needed a way to turn its VC social graph into a hiring advantage

Bridge is a VC networking platform connecting investors, portfolio companies, and talent through warm introductions. The platform had a strong social graph and intro system — but no way for portfolio companies to surface their open roles to network talent, and no way for talent to discover jobs across the VC ecosystem.

I owned the entire product — from discovery and competitive research through UX strategy, design system creation, and production development. The scope was equivalent to what a designer plus 2–3 engineers would deliver over several months. I used Claude Code (Anthropic's agentic AI) as my development partner, authoring 9 custom skills to maintain design quality throughout.

Bridge ecosystem — the missing layer

What Bridge had

VC social graph

Warm intro engine

Investor profiles

Portfolio relationships

What was missing

Job discovery for talent

Hiring pipeline for VCs

ATS aggregation layer

Career page infrastructure

What I built

Unified talent board

Multi-ATS sync engine

Branded VC career pages

Role-based dashboards

My role

Solo Product Designer + Developer

End-to-end ownership: research, strategy, design system, production code

AI partnership

9 Custom Claude Code Skills

Authored skills for UI, UX, accessibility, code quality, and design system fidelity

Scope equivalent

1 Designer + 2–3 Engineers

Multi-month project delivered by one person with agentic AI as multiplier

The constraint: Bridge's existing users already had access to warm intros and investor profiles. The talent product had to feel native to that ecosystem — not a bolted-on job board. Every design decision flowed from this constraint.


Problem

What was broken

Talent in VC networks had no way to discover jobs — the network advantage was invisible

01

User perspective

Talent in networks like Techstars, Orange DAO, and Angel Invest Ventures had to manually check each portfolio company’s career page across Greenhouse, Lever, Workable, Ashby, and a dozen more ATS providers. The “network advantage” didn’t translate into an actual hiring experience.

02

Business perspective

Bridge’s value proposition was warm introductions — but without jobs surfaced in the network, there was nothing to introduce talent TO. Competitors like Getro ($210–500/mo) and Consider (enterprise pricing) had staked out this space, but with generic UI and no community layer.

03

Technical perspective

Each VC network’s portfolio companies used different ATS providers with different APIs, different data formats, and different rate limits. There was no unified way to aggregate jobs across 13+ providers without building a custom sync layer for each one.

Before — Fragmented

Greenhouse careers page
Lever careers page
Workable careers page
Ashby careers page
9 more ATS career pages...

Talent checks 10+ separate pages. Network advantage = zero.

After — Unified

All 13 ATS providers in one board
VC trust signals on every job
Warm intro paths visible
Company discovery by network
Branded pages per VC fund

One trusted board. Network advantage = the product.

Competitive landscape

PlatformModelPriceLimitationBridge Advantage
GetroAuto-scraping aggregator + warm intros$210–500/moBasic UI, no rich profilesRich profiles, community, endorsements
ConsiderTalent circles + recruiter toolsEnterpriseExpensive, complex setupIntegrated platform ecosystem
WellfoundPublic marketplace, 10M+ candidatesFree–$499/moPublic = noisy, no trust signalsPrivate, vetted, network-endorsed

Discovery

Research & synthesis

I mapped three user worlds before drawing a single screen

I started with a comprehensive product specification — not wireframes. Before I could design interfaces for a multi-role platform, I needed to understand what each user type actually needed to accomplish and where those needs overlapped or conflicted.

The competitive analysis revealed an insight that shaped the entire product: existing solutions treated job boards as a standalone feature. None of them leveraged an existing social graph. Bridge already had the trust layer — the design opportunity was to make it visible in the hiring experience.

Research → synthesis process

Competitive analysis (Getro, Consider, Wellfound)User role mapping (4 roles, overlapping needs)ATS API audit (13 providers, different schemas)Design principles (5 pillars)Product specification document

User personas I designed for

Talent

Job seekers in the Bridge network

Discover curated roles with warm intro paths instead of competing on noisy public boards.

See which VCs back each company

Find mutual connections for warm intros

One-click apply with pre-filled profile

Hiring Manager

CEOs, CTOs, VP People at portfolio companies

Fill roles fast with vetted, network-endorsed candidates.

Post jobs from existing ATS without duplication

See which candidates have warm paths

Track pipeline per VC network

VC / Fund Manager

Partners and talent partners at VC firms

Help portfolio companies hire and track talent flow across the network.

Dashboard with hiring velocity metrics

Branded career page for the fund

Control which companies are visible

Design principles I established

01

Network-first

Every screen reinforces this is a private, trusted network — not a public job board. The VC brand is always visible.

02

Trust signals everywhere

VC badges, endorsements, and mutual connections at all interaction points. Trust is the core differentiator.

03

Progressive disclosure

Essential info first, detail on demand. Job cards show what matters — the full story lives in the detail view.

04

Warm over cold

Always surface warm intro paths before a generic "Apply." The network advantage should feel tangible.

05

Minimal friction

One-click apply, auto-filled forms, SSO login. Every extra step is a candidate lost.


Process

Architecture decisions

Four product decisions that shaped the architecture

These aren't UI polish decisions. Each one determined how four user roles, 120+ companies, and 13 ATS providers coexist in a single product — and each one required choosing the harder path because the obvious solution didn't scale.

01

Data architecture

One job record, three completely different experiences

The obvious approach: build a job board and bolt on VC management later. Instead, I treated each VC's data scope as the fundamental design unit. A single job record in the database flows through three entirely different user experiences — with zero data duplication.

The key insight: a VC should be able to hide a job from their branded career page without affecting the public board or other VCs. This isn't a visibility toggle on the job itself — it's context-dependent availability. The same "Senior Engineer at Stripe" listing can be visible on the public board, hidden from Techstars' career page, and featured on Orange DAO's — all from one database record.

Senior Engineer at Stripe

Single record in database · source: Greenhouse · synced 2h ago

Public Job Board

Visible to all talent

Aggregated across all VCs. Deduplicated by company domain. Shows every active job.

Techstars Careers

Hidden by VC manager

VcHiddenJob record exists. This job won't appear on Techstars' branded page.

Orange DAO Careers

Featured on their page

No hidden record. Stripe is in Orange DAO's portfolio, so the job appears.

Why this matters: Most multi-tenant platforms duplicate data per tenant or use simple boolean flags. I designed a join-table approach (VcHiddenJob) that creates scope isolation without copying records. One source of truth, infinite presentation contexts. This applies Jakob's Law at the platform level — each user group experiences an interface that matches the mental model of their own domain (talent sees a job board, VCs see a portfolio tool), even though the underlying data is shared.

02

Multi-role UX

Same data, four different relationships — role as a lens, not a gate

The standard approach to multi-role products: show different features per role. Show more buttons for admins, fewer for talent. But Bridge's users don't just need different features — they need a fundamentally different relationship with the same data.

A VC manager looking at "23 jobs this week" sees a portfolio health metric. An admin seeing the same number sees a platform growth signal. Talent sees opportunity. Same number, three meanings. I designed the entire interface around this principle: roles don't just gate access — they change what data means.

NavSwitcher

Job BoardVC ManagerAdmin

One dropdown changes everything

Talent

23

Opportunity to explore

Job cards with salary, location, warm intro paths

VC Manager

23

Portfolio hiring velocity

Trend chart, top hiring companies, sync freshness

Admin

23

Platform-wide growth

Cross-VC aggregates, provider distribution, system health

The component architecture

VcDashboardSections

VC dashboard, Admin dashboard, Admin VC detail

StatCard + valueColor

Same card shows green/amber/red based on data freshness

JobTrendChart

VC sees their portfolio; Admin sees all networks

What changes per role

Data scope

basePath prop switches between /vc/:domain and /admin

Stat meaning

Color-coded freshness: green (<6h), amber (6-48h), red (>48h)

Available actions

VC: sync + brand. Admin: sync + edit + manage users

Why this matters: I designed one shared VcDashboardSections component that renders identically across three dashboards — only the data scope changes via a basePath prop. This applies Miller's Law — by keeping the visual structure consistent across roles, users chunk information the same way regardless of which dashboard they're on. A VC manager promoted to admin doesn't relearn the interface. And it embodies the Aesthetic-Usability Effect — the visual consistency signals reliability, making users trust the data more because the container feels familiar.

03

Platform strategy

Making Bridge disappear — career pages as invisible infrastructure

Here's the counterintuitive product decision: Bridge's best outcome is when VCs forget they're using Bridge. The career page at careers.techstars.com shouldn't look like a Bridge product — it should look like Techstars built it themselves.

I designed the career pages not as white-label templates (slap a logo on and ship), but as fully owned product surfaces. Custom domain routing at the edge proxy level. Per-VC navigation, hero content, footer links, and social icons — all configurable from the VC Manager settings panel. JSON-LD structured data scoped to each VC. Even an offline screen that carries the VC's brand, not Bridge's.

This changed Bridge's distribution model. VCs don't share bridge.app links — they share their own career page URL. Bridge becomes invisible infrastructure, and that's exactly what makes VCs adopt it.

VC Manager Settings → what they control

Brand

Logo (light + dark)

Brand color

Accent color

Favicon

Content

Hero headline

Hero subtext

Display name

Description

Navigation

Custom nav links

Footer links

Social links

"Post a Job" toggle

Distribution

Custom domain

SEO metadata

JSON-LD schema

Owner banner

Techstars

careers.techstars.com

JobsCompanies

Orange DAO

careers.orangedao.xyz

JobsCompanies

Angel Invest

careers.angelinvest.ventures

JobsCompanies

Why this matters: This applies Tesler's Law (the conservation of complexity) — the complexity of custom domains, SEO schemas, and brand theming doesn't disappear; it shifts from the VC to the system. The settings panel absorbs all the technical complexity so fund operators never touch code. The owner banner applies Postel's Law to UI — be generous in what context you show the user. When a VC visits their own page, the system proactively tells them "You're viewing your own directory," reducing the cognitive load of figuring out what mode they're in.

04

Trust through transparency

Exposing the machine — sync freshness as a visible trust metric

A job board that shows stale listings is worse than no job board at all. But most platforms hide their sync status behind admin dashboards or monitoring tools. I made a different choice: make data freshness a first-class, visible metric that VC managers and admins see every time they open their dashboard.

The "Last synced" stat card uses color-coded urgency — green when fresh, amber when aging, red when stale. This isn't decoration. It's a trust mechanism that turns infrastructure health into a product feature. VCs can immediately tell if their job data is current without filing a support ticket.

Fresh

2 hours ago

Last synced

Synced within the last 6 hours. Jobs are current. No action needed.

Aging

18 hours ago

Last synced

Between 6-48 hours since last sync. May be worth a manual refresh.

Stale

3 days ago

Last synced

Over 48 hours. Something may be wrong. Investigate immediately.

The full trust chain

13 ATS providers sync every 6hFreshness color on dashboardActivity log records every syncVC manager sees audit trailCandidates see current jobs

Why this matters: This applies the Visibility of System Status (Nielsen's #1 heuristic) — but elevated from a loading spinner to a persistent trust metric. Green/amber/red follows the Pre-attentive Processing principle: users process color faster than reading text, so a stale sync registers as a problem before the number is even read. The valueColor prop creates what Doherty Threshold research calls "system confidence" — when the interface communicates its own health, users trust the data it shows. Combined with the activity audit log, this closes the loop: VCs never ask "is this current?" — the interface answers before they think to ask.

System

Design foundation

The design system I built before the first line of code

I codified every design decision into CSS custom properties and Tailwind utilities. This became the single source of truth, and critically, the instruction set that kept AI-generated code consistent with my design intent across 57 components.

Color palette — 8 semantic tokens

Royal Blue

#0038FF

Charcoal

#0D1531

Slate 05

#F9F9FA

Slate 30

#D9DBE1

Kelly

#0EA02E

Honey

#E19500

Ruby

#E13535

Sky

#568FFF

Typography

Mulish

Weights 400–700, 12–36px scale, tight tracking for headings

Spacing

8px Grid

Consistent rhythm across all components and layouts

Elevation

3 Levels

Ds1 (subtle), Ds2 (card resting), Ds3 (hover/focus)

Radii

Contextual

xl for cards, full for buttons/search/filters, 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, spacing token, and elevation level became a constraint that kept AI-generated components on-brand. Without this system, 57 components across 15+ pages would have drifted into visual inconsistency.


Shipped

Production features

15+ pages across 4 user roles — live at jobs.brdg.app

Every feature below is live in production and actively used. I owned the design end-to-end and partnered with Claude Code for implementation — authoring 9 custom AI skills to maintain design system fidelity, accessibility standards, and UX consistency throughout development.

01

Public Job Board

/jobs

Full-width hero with gradient, elevated search bar, Jobs/Companies tab bar, advanced filters, staggered card animations.

Design rationale: The hero gradient establishes brand tone immediately. Search is visually dominant — it's the primary action. Horizontal filter scrolling on mobile avoids a cramped multi-row layout.

02

Job Detail

/jobs/:id

Two-column layout with rich content + sidebar. Contextual breadcrumbs via URL params. Warm intros card with three auth states.

Design rationale: The sidebar stays fixed while content scrolls on desktop. Warm intros card sits above the company card — warm paths are the differentiator and get top placement.

03

Companies Browser

/jobs?tab=companies

Company cards with logo, industry, funding stage, open jobs count, and VC network badges. Deduplicated across VCs.

Design rationale: VC badges are the trust signal — always visible on the card, not behind a click. Card density optimized for scanning: enough to decide, not so much it overwhelms.

04

Branded Career Pages

/careers/:domain

Fully customizable per-VC: header, hero with custom colors, job filters, company listings, footer. Custom domain support, SEO, JSON-LD.

Design rationale: Each VC fund's career page feels like their own product. The branding form includes a live preview iframe so managers see changes in real-time.

05

VC Manager Dashboard

/vc/:domain/dashboard

Stat cards with color-coded freshness (green < 6h, amber 6–48h, red > 48h), 12-week trend chart, top hiring companies, activity log.

Design rationale: Color-coded freshness makes data staleness immediately visible — no need to read timestamps. Gradient chart fill adds depth without competing with stats.

06

Admin Panel

/admin/*

Aggregate stats, bulk job management, VC network CRUD, user management, sync controls. Reuses VC Manager components via shared module with basePath prop.

Design rationale: Component reuse was deliberate — same tables, different data scope. This kept the design language consistent and reduced surface area.

57 components across 7 domains

Component architecture breakdown

DomainCountKey Components
Layout4TopNav (glassmorphism), AppSidebar, NavSwitcher, UserProfilePopup
Jobs4JobCard, JobFilters, JobBoardTabBar, JobPostForm
Careers13VcHeader, CareersHero, CareersJobCard, CareersFooter, OfflineScreen
Admin8AdminTable, StatCard, SyncActionCard, ConfirmDialog
VC Manager5JobTrendChart, VcBrandingForm, PreviewIframe
Shared2CompanySidebarCard, WarmIntrosCard
UI Primitives21Extended shadcn/ui with Bridge variants

Accessibility

WCAG AA color contrast on all text
Focus rings: 2px Royal Blue, 2px offset
Reduced motion via @media query
Semantic HTML with heading hierarchy
Keyboard navigation (Radix primitives)

Micro-interactions I specified

Card stagger: 8 cards, 50ms delay, 300ms total

Card hover: translateY(-2px) + Ds3 shadow (200ms)

Nav transitions: 150ms color, 200ms shadow

Page transitions: opacity 300ms with content shift


Impact

Outcome & results

A production SaaS serving Bridge's entire VC network

1

Production SaaS

Live at jobs.brdg.app

57

UI Components

8,196 lines of code

13

ATS Integrations

6,046 lines of sync logic

3

Cron Jobs

Running daily in production

01

Product designers can ship production software

With the right tools, design thinking translates directly into working systems. This isn't a prototype — it's a production SaaS with enterprise auth, cron jobs, and real users.

02

Agentic AI is a multiplier, not a replacement

I handled every product decision, information architecture choice, and visual hierarchy call. The AI handled TypeScript, Prisma queries, and API integrations. The division was clear.

03

Design systems matter more with AI

A well-defined design system became the instruction set that kept AI-generated code on-brand. Without tokens, specs, and principles, the output would have been inconsistent.

04

The designer-developer gap is closing

Not because designers are becoming engineers, but because AI lets designers express intent at a level of specificity that produces engineering-quality output.

Division of labor — designer + agentic AI

Me (Product Designer)

Product strategy & scope definition

Information architecture for 4 roles

Design system tokens & specifications

UX flows & interaction patterns

Visual hierarchy & layout decisions

9 custom AI skills for quality control

Claude Code (AI Partner)

TypeScript implementation

Prisma ORM & database queries

13 ATS API client integrations

Next.js routing & server components

Cron job & sync engine logic

Test coverage & error handling


Reflection

Lessons learned

What I'd do differently next time

01

Invest in visual artifacts earlier

Even with AI, having Figma mockups to reference speeds up review cycles significantly. My design intent was clear in my head, but verifying it against production output was slower than verifying against a visual spec.

02

Build a component playground sooner

I caught most inconsistencies at the page level, but catching them at the component level is cheaper. Past 50+ components, I wished I had automated visual regression testing to catch design drift before I had to spot it manually.

The bigger takeaway: The designer-developer gap isn't closing because designers are learning to code. It's closing because AI lets designers express intent at a level of specificity that produces engineering-quality output. The design system was the bridge.


Want to see Bridge Jobs live?