PlayBrackit

I started PlayBrackit because I wanted to organize a padel tournament with my friends.

The first one was done by hand, like a lot of tournaments. For the next one we made an Excel spreadsheet. By the third tournament I had the obvious thought: wait, I am a developer. We can make this much better.

The first version was not really a product. The data was hardcoded and it only worked for our tournament. It was enough to prove the idea, and then enough to show me everything it could not do.

As we kept using it, I added what was missing. Eventually that meant rewriting the whole project and turning it into something that could support organizers and players, not just my friends and me.

The first problem I thought I was solving

At first I thought the hard part was the tournament itself: categories, groups, match generation, results, standings, and the different rules around each format.

So I built those things. PlayBrackit grew from a single hardcoded tournament into a system where organizers can create different tournaments, configure their structure, generate matches automatically, and run the event from one place.

The player side grew alongside it. Players need a public page that works on a phone, a simple way to register, a way to reserve a partner, and a clear view of their matches and results.

That gave the project two connected sides: a B2B workflow for the organizer and a B2C experience for the player.

The product bet

I wanted the organizer and player experiences to share the same source of truth, but not the same interface.

Organizers get the controls for building and running a tournament. Players get the information they need to participate without having to understand how the tournament was configured behind the scenes.

That led to a few straightforward rules:

• Registration should happen from the tournament page, not through a conversation with the organizer.
• A partner can be reserved without forcing every player to create an account first.
• Categories, phases, groups, and matches should be explicit domain objects, not fields hidden inside a giant form.
• Results should update the public tournament view as soon as they are recorded.
• Americano needs to be treated as its own format, with its own match generation and standings rules.

The point was to make the operational path boring in the best possible way. But I only understood that this was not the first problem after I started talking to organizers.

The problem I did not see at first

Once the tournament system was working, I started speaking to a few organizers. I realized their problem was not exactly the same as mine.

The operational side is important, but many organizers do not describe it as a problem because they have never had another way to run a tournament. Their first real pain is earlier: getting enough people to sign up, and chasing one person after another on WhatsApp.

That changed the direction of the product. I simplified player registration and started working on a WhatsApp bot, so the first interaction can happen in a place players already understand.

The bot is still early, but the direction feels right. The product should not ask everyone to learn a new workflow before they can join a tournament.

How it evolved

The project went through a few very different versions:

1. Do it by hand. We organized the first tournament manually.
2. Use a spreadsheet. Excel helped for the second tournament, but it still left us doing too much coordination ourselves.
3. Build the smallest useful version. I hardcoded the data for our tournament to see if the idea was worth pursuing.
4. Rewrite it properly. Once the limitations were obvious, I rebuilt the project around organizers, players, multiple tournaments, automatic match generation, and the rules each format needs.
5. Move earlier in the journey. Conversations with organizers showed me that registration and player acquisition mattered before the tournament operations even started.

The current system is built with Laravel, Vue, TypeScript, Inertia, and Tailwind. The stack is familiar. The interesting part has been learning what deserves to be modeled, what should be simplified, and when the product is solving my problem instead of someone else’s.

What I still want to prove

PlayBrackit can make the mechanics of a tournament clearer. The harder question now is whether it can help an organizer get the tournament off the ground in the first place.

I am still working out how much of that should happen through the public tournament page, how much should happen through WhatsApp, and where the organizer needs to step in.

The product is useful when an organizer does not have to chase every player manually, and nobody has to ask which version of the tournament is the real one.