Raspy

A sports platform built around match records

We believed amateur matches deserved records, and that those records could connect people. We incorporated and launched the product. Our long-term plan was to grow the community, then expand into venue rentals.

Product development and field operations

I built the initial infrastructure, backend, and frontend. Once the development team formed, I led it through task definition and code review, while contributing to product priorities and business decisions.

Match combined a sports social network with a system for running live matches. I implemented WebSocket score synchronization and automatic brackets, with blue-green deployments, monitoring, and alerts to reduce the risk of disrupting matches.

We operated at tournaments involving hundreds of participants, including Dongdaemun university events, Yonsei–Korea University exchanges, and our own events. Watching people hesitate on screens or struggle to find buttons led me to prioritize usability over new features.

Restructuring feed queries

The feed felt slow during use, so I inspected its queries. It repeatedly fetched match data that didn’t depend on the user. I moved shared data into a Caffeine local cache and combined it with user-specific information at request time.

In the comparison test, average latency fell from 820 ms to 38 ms, and database queries per request fell from 81 to one.

These are comparative results on test data, not overall production latency.

Read the cache design and measurements ↗

Retention and business sustainability

Tournaments and marketing brought users in, but organic return visits were insufficient. We first added features such as a feed, thinking the product wasn’t engaging enough; later we identified the community’s cold-start problem.

The service worked, but we closed the business without establishing sustainability. We did not reach revenue or venue-rental expansion. I learned the difference between a functioning product and a sustainable business.