Nobody talks about what side projects look like in the middle. You see the launch posts and the weekend build threads, but the reality of something that's been running for six years is messier and more interesting than that.

Buzzer Beater has been in some form of active development since 2018. Here's what that actually looks like.

Infrastructure is never finished

The backend has gone through several homes over the years. Each move was driven by the same logic — find the setup that lets us focus on features instead of servers, at a cost that makes sense for a project of this scale.

The most recent migration made a significant difference: from a setup costing considerably more per month to something around £12–15. For a side project, that's the difference between sustainable and not. That kind of cost discipline is what lets Buzzer Beater keep running without needing to rush monetisation.

The data problem

Live sports data is surprisingly hard to get reliably. Formats change, endpoints move, and things occasionally go down without warning. Keeping data accurate across players, teams, injuries, and live scores requires constant maintenance — not dramatic rewrites, just steady attention.

Injury tracking in particular is an ongoing challenge. Status changes happen frequently and close to game time. Getting the right information to users at the right moment — without overwhelming them — took a long time to get right. The current approach groups updates intelligently and prioritises what's most time-sensitive. It's not glamorous work, but it's what makes the product actually useful.

The web platform

The iOS app ran alone for four years. Building the web platform in 2025 was partly about reach — not everyone is on iOS — and partly about making the platform more discoverable. The web app now has player pages, team pages, standings, live game scores, and a match chat that runs alongside the iOS version.

Getting live scores working reliably on mobile browsers was one of the more persistent problems. Connections behave differently when a phone locks its screen or the browser tab moves to the background. The reconnection logic had to be rethought several times before it was consistent.

What keeps it going

The honest answer is the community. There are users who've been on the app since the early iOS builds. They report issues, suggest features, and notice things that automated checks miss.

That feedback loop is what separates a project that survives from one that gets abandoned. We take it seriously because without it, this would have quietly stopped years ago.

The prediction engine is next. It was the original idea from the 2018 university thesis and the long-term goal throughout. The beta is on track before the end of the current season. More on that soon.