Skip to main content
HB
Hiram BarskyProduct Designer + AI

Sports · Community · Mobile

CatchBuddy: Trust Is the Product, Not a Settings Page

The easy part is getting two strangers to agree to meet in a park; the difficult part is getting them to feel safe while doing so.

CatchBuddy on a phone: nearby pickup games with who is going and how far away each one is

Overview Section

Research Section

RESEARCH

Gathering insights

Most People Just Want a Game on Saturday

Pickup sports are declining in urban areas, and the apps designed to address this problem all assume that you want to take part in a full season, with all the commitment and the fixed schedule and the regular team that such a season entails. What most people actually want is a game on Saturday.

Emerging themes

THE WRONG FRAME

Existing apps assume a season, a fixed schedule and a regular team.

Drove: A front door built around one game on Saturday.

TRUST, NOT CALENDAR

The blocker is two strangers agreeing to meet and both feeling comfortable.

Drove: The safety layer shipped in v1 instead of being added later.

THE DATING-APP READ

Testers always read "Matches" as referring to a dating app.

Drove: Renamed to "Browse" and "Players". The match scores stayed.

Image Failed to Load

This image is currently unavailable

It wasn't the scheduling that was the issue; the problem was getting two complete strangers to agree to meet at a park and both of them feeling comfortable about it, and that's a matter of trust rather than one of the calendar.

Problem Section

Problem to Solve

Getting two strangers to agree to meet at a park is easy. Getting them to feel fine about it is the entire product.

Key Insights Section

Key insights

1

A parent verifies before a kid can post

A child won't be allowed to post a game until their parent has been verified. The panic button can be reached from any screen while playing.

2

The restriction is the feature

Meeting points come from a list I curated, so no one can drop a pin on an address of their own choosing. That one is often the subject of debate; it would be more flexible to let people add their own locations, and I still won't do it.

3

Safety first, or it becomes a settings screen

In version 1 the safety layer was the first thing included, because every product I've seen that added it later ended up with a settings screen no one opened.

My Thought Process Section

AI-ASSISTED BUILD

What AI Did, and What It Couldn't

The AI carried out the preparation of the RLS policies, the Supabase migrations, the Stripe integration and the OAuth flow, which represents a major part of the project, and it did so quickly. It wasn't clear who was allowed in, who was gatekept, and what a stranger would see about another stranger before agreeing to meet; those cases were the ones I handled manually. Although, one thing an AI security review did pick up on that I otherwise would have missed was a recursive RLS policy which would have led to data being leaked in production.

Image Failed to Load

This image is currently unavailable

Posting a game, and what one stranger can see about another before agreeing to meet.

Ideation Section

IDEATION

Multiple iterations

A Parent Verifies Before a Kid Can Post

1

Sign up

13+ age gate as the first checkpoint

2

Under 18

asks a parent to verify before posting

3

Every game

a curated meeting place and a panic button

4

Any screen

panic button reachable while playing

Ideation to prototype: sticky notes grouped into themes, then five screens from wireframe to prototype
Ideas grouped into features, safety and community, then the same five screens taken from wireframe to prototype.

What Didn't Work Section

What I Cut

What I Cut

People always read "Matches" as referring to a dating service; it's now called "Browse" and "Players". I created a Quick Start wizard which was not wanted, saw testers skip it every time, and eventually removed it. Support for Apple, Outlook and ICS calendars was developed and then removed, since hardly anyone used them and I would have had to maintain three integrations indefinitely for those few who did.

The Design System Section

The Design System

The Design System

I warmed up the palette, since a trustworthy product that looks like a fintech dashboard comes across as a company, and this one needed to look like a neighbour. The safety states have been part of the same system since v1, rather than appearing later as status chips bolted on the side.

The complete walkthrough, narrated: posting the game, selecting a park, choosing equipment and preferences, then the safety features — emergency contacts, phone verification, and the minor gate.
Desktop case-study board: why people don't play, the ideation sketches, and the finished desktop prototype
The warm ground and the single green, doing their job on the finished desktop screen.

Where It Landed Section

Where It Landed

Where It Landed

Shipped, including auth, RLS, Stripe, Google OAuth, real-time updates, the minor-approval process and the curated meeting spots — all of which I designed and built. In version 1 the safety layer was the first thing to be included, since all the products I've seen which added it later ended up with a settings screen that no one opened.

AI-Assisted Product
Trust & Safety
Mobile-First
Solo Build
"Unmatched in his ability to translate the often vague ideas from clients into beautiful, simple-to-use products."
Daanish
Business Delivery Partner at Tata Consultancy Services

More Work Section

#Healthcare#Marketplace#GenAI

More Work

HerbaLink practitioner booking interface

HerbaLink: Credential Trust for Certified Herbalists

I built a discovery and booking platform connecting users with vetted herbalists and reliable resources. The vision centered on credibility—helping users find trusted practitioners while avoiding unverified sources and misinformation.

3× Practitioner Bookings

Contact Section

Get in Touch

Tell me what you're working on and where it's stuck. Short messages are fine.