FounderMatch

AI-powered B2C · Mobile & Web App

FounderMatch by FounderWay is an AI-powered networking tool designed to connect startup founders, technical talent, and investors, driving networking efficiency through AI-driven matching, targeted networking, and event integration.

I designed an end-to-end, trust-driven matching system, that transformed networking into a more transparent experience.

Team

1 Designer (Me)

2 Developers

1 Product Manager

5 months

250+ founders onboarded in 72 hours of launch

The Problem

Finding a co-founder still comes down to luck

For startup founders, finding the right co-founder is tough. They reach out through scattered connections, with no structured way to know who's actually the right fit. It's slow, inefficient, and rarely leads to real alignment.

This journey is slow, inefficient, and rarely leads to real alignment

Insight #1

Skills weren't the hard part

Assessing commitment and vision was. Even when founders found someone with the right skills, evaluating long-term alignment took months of informal back-and-forth, with no guarantee.

Months of hard work finding nothing

Insight #2

A digital match alone didn't feel real

Founders didn't trust a cold, algorithm-generated connection, no matter how compatible it claimed to be. Without a shared, real-world context, a match felt like a guess dressed up as data.

A high score, still strangers

“The challenge wasn't building a better matching algorithm, it was designing an experience founders could trust.”

Solution

One flow, personalized to intent

Founders arrived with different intents: building their own idea, joining someone else's, or just exploring.

Everyone completed the same core inputs, but the flow adapted based on why they were on the platform, so the data feeding the algorithm stayed intentional without asking anyone to sit through steps that didn't apply to them.

Solution

A reason, not a ranking

That intentional data didn't just shape onboarding, it shaped what founders saw next. Rather than one long list to sort through, the highest-compatibility matches gave founders a starting point, along with the rest of their most aligned profiles and reasons instead of a score to judge it by.

Solution

Matching, scoped to who's actually in the room

A cold, algorithm-only match didn't feel trustworthy on its own.

Matching only within a specific event's attendee list, virtual or in-person, meant founders were never paired with a stranger from platform-wide pool, only with people also actually attending that same event.

Design Decision

Making the algorithm legible

The matching engine scored founders on skills, vision, industry, and commitment, in a way only the algorithm understood. My job was deciding what it should say out loud.

Working with engineers, I surfaced the specific overlapping attributes behind each match, not a single abstracted score, so founders had a transparent reason to trust it.

# Internal matching logic (simplified, illustrative)
founder_a = {
    "industry": "Fintech",
    "vision": "Building a fintech platform for underbanked communities",
    "time_commitment": "Full-time",
    "skills_needed": ["Backend engineering", "Fundraising"]
}
founder_b = {
    "industry": "Fintech",
    "vision": "Passionate about financial inclusion, especially in emerging markets",
    "time_commitment": "Full-time",
    "skills_offered": ["Backend engineering", "Fundraising"]
}

# Each response is embedded or compared across matching dimensions
vision_embedding_a = embed(founder_a["vision"])
vision_embedding_b = embed(founder_b["vision"])

vision_score = cosine_similarity(vision_embedding_a, vision_embedding_b)   # 0.87
commitment_score = match_commitment(founder_a["time_commitment"], founder_b["time_commitment"])  # 1.0
skill_score = overlap(founder_a["skills_needed"], founder_b["skills_offered"])  # 1.0
industry_score = match_industry(founder_a["industry"], founder_b["industry"])  # 1.0

# raw_compatibility_score = 0.93  ← this is what the model actually knows

The algorithm's reasoning, made visible

Design Decision

A card that earned trust, not just showed a match

My first instinct was a compatibility score. Testing killed it fast. The card now shows the specific reasons behind every match, so founders judge fit for themselves, building real trust in what the AI surfaced.

Design Decision

Mobile first, on purpose, not by adaptation

Someone's first match likely arrived on their phone, mid-event. Designing for that smallest, most distracted screen first forced the real hierarchy questions. Web inherited those priorities.

Research

Context

Why this mattered

Solo founders were building alone by default, not by choice, and every existing tool optimized for the easiest thing to filter on, skills, while ignoring what founders said mattered most.

Research

Understanding what founders actually needed

I had my own assumptions about why founders were struggling to find a co-founder, but the only way to actually test them, rather than design around a guess, was to ask founders directly.

From 8 interviews and 18 surveys with founders, four patterns emerged:

•Found people, but the skills didn't complement their own
•Didn't know what skillset to look for
•No dedicated place to search
•Commitment nearly impossible to gauge

Solution Ideation

Scoping before the interface

Sat with our PM and engineers to prioritize the MVP scope and map the product end to end, that structure set the boundaries for everything that follows.

Solution Ideation

Weighing ideas against what we could actually build

Working closely with engineers and founders, I brought ideas to the table and stress-tested them against real constraints, what was technically feasible, what fit the timeline, and what actually served the product, before any screens got designed.

Keeping onboarding in our control

✓Manual entry with inline validation gave us a reliable onboarding flow
✓No reliance on external APIs or third-party services
–LinkedIn autofill was limited by API access and scraping restrictions
–Not practical for the first MVP release

Information Density vs. Scannability

✓Prioritize high-signal match attributes over complete profile data
–Normalized onboarding responses into four scannable compatibility tags
–Moved lower-priority details to the profile to keep cards lightweight

Solution Ideation

Exploring the solution space

With those constraints set, I explored many many card layouts, score-display formats, and looked at how existing tools approached this problem.

Solution Testing

Design meets its first skeptics

After ideating through more variations than I'd like to admit, I pulled the strongest pieces into one prototype, ready to put in front of real founders and the founding team.

Where trust broke down:

•Matches felt relevant, but the reasoning wasn't clear.
•Compatibility scores created comparison instead of confidence.
•Location was essential to judge whether a connection was realistic.

Solution Testing

Addressing feedback

Each gap became a fix: scores gave way to the actual reasons behind a match, location became a primary field, and only the strongest matches were shown at all. These changes are what made the product trustworthy, not just functional.

Each gap became a fix:

•Scores gave way to the actual reasons behind a match.
•Location became a primary field on every card, so feasibility was clear upfront.
•Only the strongest matches were shown at all, so there was nothing left to compare, only someone to reach out to.

Solution Testing

A platform that goes beyond skills

The final experience focused on making AI matching feel transparent, showing why a match existed, not just how good it was, and grounding it in real events instead of an anonymous pool. Founders needed an algorithm they could understand, not one they had to trust blindly.

Impact

What got delivered

•250+ founders onboarded within 72 hours at launch, presented at Harvard Innovation Center, Techstars Startup Weekend Boston 2024
•80% task success rate across onboarding and matching, tested with 18 founders

Key Learnings

•Designing for AI meant designing for uncertainty. The hardest part wasn't the interface, it was helping people trust something that wasn't always black and white.
•I stopped asking Can we build this? and started asking Should we build this? Constraints usually led to better ideas anyway.
•AI doesn't always have one right answer, so neither does the UX. I learned to design for confidence, not certainty.

Redesigned content discovery to give low-digital-literacy users a more personalized journey.

Confidence for low-digital-literacy usersCognitive load