Skip to main content
HB
Hiram BarskyProduct Designer + AI
All work

Case Study

CatchBuddy

Getting two strangers to agree to meet at a park is the easy part. Getting them to feel safe doing it is the product.

  • AI-Assisted Product
  • Trust & Safety
  • Mobile-First
  • Solo Build
Role
Lead UX Designer & Developer
A game on Saturday, not a season. The whole front door is aimed at the person who wants one afternoon.

01

Most People Just Want a Game on Saturday

Pickup sports are dying in cities, and the apps meant to fix that all assume you want a season. They want commitment, a schedule, a recurring team. Most people just want a game on Saturday.

The problem was never scheduling. It was getting two strangers to agree to meet at a park with both of them feeling fine about it.

Posting a game starts with the sport and nothing else. No team, no schedule, no season to sign up for.

02

A Parent Verifies Before a Kid Can Post

A kid can't post a game until a parent is verified. The panic button is reachable from every screen you can be on during a game. And the meeting spots are a list I curated, not somewhere any user can drop a pin.

That last one gets argued with a lot. Letting people add their own locations is more flexible, and I still won’t do it.

A curated list of meeting spots with distance and amenities. Nobody can drop their own pin, and that restriction is the point.

03

What AI Did, and What It Couldn't

AI wrote the RLS policies, the Supabase migrations, the Stripe integration and the OAuth flow. That is real work and it did it fast.

What it could not do was decide who gets in, who gets gated, and what a stranger sees about another stranger before they agree to meet. Every one of those I made by hand. AI's own security review also caught a recursive RLS policy that would have leaked data in production.

The small disclosures two strangers trade before they meet — who's bringing a ball, and whether this is contact or not.

04

What I Cut

Testers kept reading "Matches" as a dating thing, which is not what anybody needed here. It is "Browse" and "Players" now.

I built a Quick Start wizard that nobody wanted. Testers skipped it every time, so I stopped making them skip it.

Apple, Outlook and ICS calendar support all got built, then all got cut. Barely anyone used them and I was going to be maintaining three integrations forever for that.

Match scores on the player cards. It's called Players now, because testers kept reading "Matches" as a dating app.
Confirmation shows how many players are nearby. A real number that decides whether you get a game, not a vanity counter.
  • The 13+ gate at sign-up — the first checkpoint in the minor-protection flow, in v1 rather than bolted on later.

05

The Design System

I made the palette warm. A trust product that looks like a fintech dashboard reads as a company rather than a neighbour. The safety states sit inside the same system from v1, instead of arriving later as status chips bolted on the side.

Warm paper and one green, at three depths. Green is reserved for action so it never gets spent on decoration.

06

Where It Landed

It shipped. Auth, RLS, Stripe, Google OAuth, realtime updates, the minor-approval flow and the curated meeting spots, designed and built by me.

The safety layer went in first, in v1. Every product I have seen add one later ended up with a settings screen nobody opens.

The full walkthrough, with me talking through it. Posting a game, picking a park, equipment and preferences, then the safety layer: emergency contacts, phone verification, and the minor gate.
The thinking behind itWhen Trust Is the Product, It Can't Be a FeatureGetting two strangers to agree to meet at a park is easy. Getting them to feel fine about it's the entire product — and it's not something you…Read the post

Want something like this built?

I design and ship products end to end. Tell me what you're working on, or grab a time and we'll talk it through.