Pursue Networking — Professional Connection Platform

Overview

Pursue Networking is a professional connection platform built around one thesis: most networking tools optimize for volume, not quality. Pursue focuses on meaningful introductions — its matching algorithm surfaces people you're genuinely likely to benefit from knowing, based on complementary skills, goals, and career trajectory rather than just mutual connections.

I was the full-stack engineer responsible for the matching engine, the user profile graph, and the search infrastructure.

The Challenge

Building a match quality metric is fundamentally a product problem disguised as a technical one. "Good match" means different things to a recent graduate looking for a mentor, a founder looking for an investor, and a hiring manager looking for a senior engineer. The system needed to be personalized without requiring users to fill out endless preference forms — most people won't.

At 25K+ users, naive O(n²) pairwise matching on every recommendation request was computationally infeasible. We needed approximate-nearest-neighbor techniques to make the recommendation engine fast enough for real-time use.

Architecture & Technical Decisions

Multi-Signal User Graph

User profiles were modeled as attribute vectors across several dimensions: skills (from profile + inferred from job history), goals (from onboarding + behavioral signals), seniority level, industry, and geographic preference. Each dimension was weighted differently depending on the requesting user's stated intent (job seeking vs. mentorship vs. business development).

• PostgreSQL with pgvector extension for dense vector storage and ANN search
• User vectors updated incrementally on profile edits — no full re-indexing needed
• Intent detection from onboarding answers + session behavior (clicked mentor profiles? investor profiles?)
• Skill ontology: "React" and "ReactJS" and "React.js" normalized to the same node

Approximate Nearest Neighbor Matching

Using pgvector's HNSW index, candidate retrieval for 25K users ran in ~8ms per query. Post-retrieval, a re-ranking stage applied business rules: mutual connections boosted score, users who previously declined a connection were suppressed, verified professionals were ranked above unverified. The final ranked list of 20 suggestions was cached in Redis per user with a 6-hour TTL.

• pgvector HNSW index for sub-10ms approximate nearest neighbor retrieval
• Re-ranking layer: mutual connections, past interactions, verification status
• Redis cache with 6-hour TTL per user's recommendation set
• Background job refreshes cached recommendations when user profile changes

Connection Flow & Messaging

Connection requests were asynchronous — no real-time pressure. Messages between connected users used a standard polling architecture (30-second poll interval) rather than WebSockets, keeping infrastructure simple for a feature that didn't need sub-second latency. Notification emails were queued via SQS and sent through AWS SES.

Results

• Connection acceptance rate 3x the industry average benchmark for professional networks
• Match relevance score (user-reported in post-connection survey): 4.3/5
• Recommendation engine p95 latency: 12ms (retrieval) + 3ms (re-ranking) = 15ms total
• 25K+ monthly active users with 62% 30-day retention
• Skill normalization reduced duplicate skill entities by 78%

What I Learned

The matching algorithm's biggest improvement didn't come from a better model — it came from better feedback loops. We added a simple thumbs-down on recommendation cards that fed a suppression signal back into the ranker. Within two weeks of shipping that one feature, user-reported match quality scores jumped from 3.6 to 4.1. Explicit negative feedback is often more signal-rich than implicit positive engagement.