Klubbi

Parents spend hours trying to find youth sports programs and mostly come up with a name, an address, and a phone number. Organizations spend just as long trying to get found. The information that actually decides whether a family signs up, the real cost of a season, the culture of a program, whether there's a spot left, lives nowhere a parent can search. It isn't a passion problem. It's an infrastructure problem.

Klubbi is the marketplace that fixes that, one city at a time, starting in Houston.

I'm the founder, but the reason this is a useful case study is the technical product work underneath it. I made the calls on the stack, the data model, the payments architecture, and the launch sequence, and I directed the build and reviewed every change that went in. Here are the decisions I'm proudest of.

The first version was on WordPress and a stack of plugins. It got me sixty percent of the way fast, then fought me on every feature that actually made the product different. So I made the harder call early: tear it up and rebuild on Next.js and Supabase.

The reasoning wasn't "newer is better." It was that the whole point is to grow city by city, and a pile of plugins doesn't travel. Clean code I own does. It also meant the custom features (the cost breakdown, the culture profile, the comparison tools) became straightforward instead of a fight. Early, mostly reversible, and the kind of call that's cheap now and very expensive in a year.

A directory is only as good as its data. The first scrape of Houston came back with over eleven thousand records, and most of it was noise: doctors, daycares, tutoring centers, gyms. Worse, real organizations showed up three different ways, and a single club might run soccer, basketball, and flag football all at once, which the database had no idea how to handle.

So I designed the resolution pipeline: strip the noise, match duplicates across phone, domain, and a fuzzy match on the name, and tag each organization to the sports it actually offers. Eleven thousand noisy rows became a few thousand real, trustworthy organizations. This is the unglamorous systems work that decides whether a parent believes what they see.

The hard part of a two sided marketplace is the money. I designed the payments on Stripe Connect so that when a parent registers and pays, the organization is paid directly and Klubbi takes its fee on top, rather than money landing with Klubbi and getting paid out later. That's a real architecture choice with real consequences: it changes who the merchant of record is, how fees are calculated, and what each side sees.

It also demanded precision. The amount an organization sees has to be their share, never the parent's total with the platform fee folded in. I caught that exact mistake in a confirmation email before it went out, and I caught a separate gap where a server function could have returned one organization's billing details to another. The point isn't the bugs. It's that I was close enough to the build to find them.

There was more to build than time to build it, so I split the work into what blocks launch and what can wait. Payments and the organization's view of who registered had to be live for the launch cohort. Full automation, subscriptions, and the deeper integrations could ride a later timeline without holding up the date. I built the runway around that, and front loaded the slow outside dependencies like legal review so they wouldn't become the thing that slipped the launch.

The piece I'm most excited about is integration. Most organizations already use a tool. So instead of asking them to switch, the plan is for a parent to register on Klubbi and have it sync into the tool the organization already runs, through their API. That's the difference between a directory and infrastructure, and it's the work I find most satisfying: making separate systems behave like one.

Klubbi is the proof that I can take a problem, decide what to build and in what order, make the architecture and data and payments calls myself, and ship it. That's the technical product manager. The parts where the hard problem is how the systems fit together, that's the solutions architect. Same instinct, two different layers.