A club held together
by a vendor's software.

Racing didn't have a member system. They rented one. BoleteríaVip handled payments, ticketing, access control, and member data — and Racing couldn't touch any of it. No exports. No API. No way to connect member data to anything else the club needed.

When we met Racing in 2017, we helped ship their first official app. It was retired, but the relationship stayed. When we reconnected, we pitched reviving the app. Racing came back with a bigger ask: kill the vendor, build the platform, own the data.

That decision — to build, not buy — is what made everything else possible.

The technical challenge was real, but it wasn't the hard part. The hard part was time.

Negotiation ate half the project. A 12-month plan compressed to 6. We had 2–3 months of discovery just to map how the old system worked — and most of it lived in people's heads, not documents. The member-support team carried the business rules in muscle memory. Fee status. Member categories. Automatic debit logic. Nobody had written it down because it just worked.

And the scope was vast: membership, payments, ticketing, access control, reporting — across 14 member categories, family-group discounts, multiple card processors, numbered and unnumbered seats, RFID turnstiles, and 30+ people across Racing's departments.

We had two options. Build everything the functional analyst documented — 1,342 paragraphs of institutional logic — and ship in 18 months. Or simplify each problem into something shippable, lose some detail, and scale up after launch. We chose the second.

That meant cutting scope ruthlessly. Two separate frontends instead of one mega-app. Automatic debit flagged as minor — until it became the single most critical feature. 3D seat-map selection left out of Phase 1. Electronic invoicing deferred. Each cut was a trade-off: we gave up completeness for the chance to actually go live.

It was the decision that saved the project — and the one we'd refine most in hindsight.

The deadline was December 2022. Then January. Then February. Then the old system's hardware burned out — literally — and Racing had to go live with whatever was ready.

It shouldn't have worked. We tested in the stadium during the first match, refining access-control queries between halves. By the second match, the queries were fast. By the third, members flowed through the turnstiles without incident. Data migration ran nightly: export from the old system at close of business, load into the new one before morning.

The roughest piece was member registration — the first thing a new member touches. It was the last thing we wanted to ship unfinished. But we did, and we fixed it live.

We chose serverless-first on AWS because the team needed to ship new modules constantly — payments one month, access control the next, AI features a year later. A fixed infrastructure would have bottlenecked every iteration. Variable cost meant we paid for matches and renewals, not idle servers. Low DevOps meant one person could run the whole thing.

A single Aurora RDS MySQL across all modules kept integration simple. The architecture absorbed traffic spikes from matches, ticket sales, and renewals — we pushed it to the limit and refined the DB settings over months of real load.

If we rebuilt today, the frontend would be Next.js on Vercel. The backend decisions have aged well.

Before: a vendor owned the data, the channels, and the roadmap. Racing couldn't connect their member system to anything — not the app, not the website, not the accounting software.

After: Racing owns all of it. Members self-serve through the web app and the official app. Internal teams run every operation from one backoffice — automatic debit, reporting, invoicing, ticketing, access control. The club decides what to connect and when. No more vendor lock-in.

The platform runs members, ticketing, stadium access, colonies, sports, court rentals, parking, and administration. Still in production. Still growing.

We'd push back harder on the negotiation timeline. Discovery ate half the project. Next time, we'd run discovery and development in parallel from week one — ship the known pieces while still mapping the unknowns.

We'd also ship member registration earlier. It was the roughest part of the accidental launch, and it was the first thing new members touched. That should never have been the weakest link.

After the second match, around February 14–17, 2023. The turnstiles worked. The queries were fast. The members flowed in. Nobody complained.

Racing valued trust and flexibility above all. The project stood out for its challenge, the lack of time, and the scale. PATMOS learned scalability and team velocity for critical projects — and redefined everything: product, architecture, and operations.