OutdoorPersonals

The premise

Finding people to do outdoor activities with is a real problem that dating apps solve badly, because the thing being matched is different. It isn’t romantic compatibility — it’s whether you hike at the same pace, have comparable experience, want the same kind of day out, and are free at the same times.

Getting paired with someone who wants to summit fast when you want to photograph wildflowers is a bad day for both of you.

The matching model

Compatibility is scored 0–100 from weighted components: shared activities at 40%, pace at 20%, experience level at 15%, availability at 15%, and outing style at 10%.

The weighting encodes an opinion. Shared activity interest dominates because without it there’s nothing to do together. But pace and experience are weighted meaningfully above scheduling, because a mismatch there produces a genuinely bad — and occasionally unsafe — outing, while a scheduling mismatch just means waiting for a better weekend.

It’s deterministic and inspectable rather than learned, which for a cold-start product with no interaction data is the correct choice — and it means a user could be shown why a match was suggested.

That last part is only half-built. The score appears on every partner card and the browse screen names the factors it used, but there’s no per-match breakdown showing how the number was reached. It’s the first thing I’d finish. After an outing, both people rate it, and that feedback is meant to inform later matches.

Safety as a design requirement

Meeting strangers in remote places carries risk that a normal social product doesn’t. So the data model includes reporting and moderation, an admin review surface, and shared outing plans — a plan accessible by token so details can be sent to someone not on the platform, which is the digital version of telling somebody where you’re going.

Regions are gated with an open or waitlist state, so the product can launch somewhere with enough density to actually work instead of being empty everywhere — the standard failure mode for matching products.

Scope

22 pages covering signup, onboarding, profiles, browsing, matches, requests, messaging, activity and guide content, safety information and admin. Eight Prisma migrations across users, profiles, matches, requests, messages, outing plans, reports, regions and email tokens. A 37-entry catalog holding 29 activities alongside resource groups, services and safety topics. Auth with email verification and password reset.

Status

This one is honest about being a prototype. It’s a complete, working MVP running locally — and it is not deployed, has no users, and its own planning document states plainly that nothing serves the domain today.

I’m including it because the product thinking is the substance: deciding what to match on, weighting it defensibly, designing for safety, and solving cold-start density before launch rather than after.