Stadibox

How I Got There

The team reached out because they didn’t have anyone focused on the frontend. They were full-stack and backend developers doing their best with what they knew, and they needed someone who could look at the whole thing, spot what wasn’t working, and fix it. A proper pass through the entire application, not a quick patch job.

I sat down with them, went through the app, and pretty quickly saw where things were falling apart. Pop-ups that didn’t validate correctly, filters that were static and hardcoded, notifications that didn’t exist yet. The frontend needed someone to own it. So that’s what I did.

What Stadibox Is

A marketplace for renting stadium boxes and seats in Mexico. Owners list their luxury boxes or bleacher sections for specific events or annual leases. Buyers browse by stadium, search events, go through a multi-step checkout with add-ons like catering or transport, and the platform handles the transaction, logistics, and delivery. There’s also a memorabilia section for sports collectibles, VIP experiences, and an admin console for the whole operation.

The scale is real. Dozens of features, over 50 different pages, and about 10 people working on it at the same time. This wasn’t a side project. It was a full product with real users and real money moving through it.

Rebuilding the Frontend

My biggest single contribution was pretty much rebuilding the frontend. 14 files, thousands of lines. The pop-up system, the admin styles, the public-facing pages, the forms. Pretty much all of it.

One of the problems I ran into early was that the platform loaded every pop-up for every event on the page at once. Each event had a multi-step form, and each form was built from multiple pop-ups stacked together. If you had several events on screen, that meant dozens of these things sitting on the page at the same time, and computers just couldn’t handle it. The fix was pretty straightforward: don’t create anything until the user actually clicks to add or edit. That one change made the whole admin section usable again.

The Filter System

The available listings page had static dropdown menus with hardcoded options. I replaced the whole thing with a system that pulls real data and lets users filter by country, city, stadium, and property type at the same time. Results update instantly without reloading the page, which for me was the right call because of how often people were switching between filter combinations.

I built this once and applied it across three different admin views. A teammate had done an earlier version of the property filters with a different approach, and I replaced it because I wanted one way of doing it everywhere. Three views doing the same thing three different ways didn’t sit right with me.

Validation

The registration form had a disabled submit button and not much else. I built a validation system that checks name length, email format, password matching, and calculates the user’s age from their birthdate to make sure they’re 18 or older. Each field gets its own error message, and the most critical issue is always the one that shows up.

I carried that same approach into the login form and the box registration wizard, which is a multi-step process. Instead of checking every field on every keystroke, each step only validates what belongs to it before letting you move forward. Way less frustrating for the user.

Real-Time Notifications

Box owners needed to know when their tickets sold. I built a notification system that checks every few seconds, counts how many tickets were sold that day, and shows a badge in the header with the right number. Singular or plural, correct phrasing, the small stuff that makes it feel finished.

While I was wiring that up, I found a bug in the backend where a variable wasn’t scoped correctly and was affecting other parts of the app. Fixed that too, even though it wasn’t really my area.

Helping the Team

For me this is the part that matters the most. A big chunk of my work was taking what everyone else built, making sure it all fit together, and getting it ready to ship. I’d review what other developers were working on before it went live. When someone was stuck on a UI problem, I’d go to their desk and walk through it with them.

The team had people on payment flows, logistics, database work, all of that. They were good at what they did. What I brought was the frontend eye: knowing what a form should feel like, how filters should behave, where a validation message should go, why a pop-up was too slow. I was there to fill the gap they knew they had, and that’s pretty much what I did.

Shark Tank

Stadibox appeared on Shark Tank Mexico. A teammate told me when it aired, and I still remember that moment.

I don’t bring this up to make it about me. The whole team put in serious work. Backend developers handling payment flows, database exports, logistics systems, all of that was happening at the same time I was fixing pop-ups and building filters. The fact that the platform got to a place where it was functional, polished enough, and working correctly, that was everyone.

But for me, this project confirmed something. I already had the eye to look at a frontend and know what’s wrong, what’s fine, and what needs to change. I’d been building that instinct since my first job, and Stadibox was where I got to put it to the test with a real product and a real team counting on it. Seeing it on national television, that part was pretty surreal.

What I Took From This

This was the first time I was brought in specifically because a team needed someone who understood the frontend. I was the person they called to look at the whole thing and make it work. We had conversations with the client about how the app felt, how it was perceived, what the experience was like. That changed how I thought about my work going forward, because the founders didn’t care about how things functioned line by line. They cared about how it felt.

The technical stuff was pretty straightforward. Filters, validation, pop-ups, notifications. None of it was bleeding edge. But doing all of it across a platform this size while helping a team that was learning frontend patterns in real time? That’s where it actually got interesting. I’m grateful for the team. They trusted me to lead that part of the work, and we built something really, really good together.