From lockdown to 240K users
I started ComediaPlay when live entertainment stopped during the pandemic. I designed, built and operated almost the entire product myself until closing it in August 2026; most activity was concentrated through 2024.
- Users
- ~240K
- Paid digital accesses
- ~400K
- Transaction volume
- ~US$3.5M
- Peak concurrent users
- ~10K
ComediaPlay started because live entertainment stopped.
During the pandemic, comedians, producers and audiences suddenly needed a way to keep shows happening online. I built a platform for selling and accessing comedy shows, digital events and film premieres.
I ended up running almost everything myself: product, design, development, infrastructure and operations. Accounting was basically the only part I didn’t own.
Snapshot
- Timeframe
- April 2020 – August 2026
- Product
- Online entertainment platform for comedy shows, digital events and film premieres
- Stack
- WordPress + WooCommerce core · PHP · SQL · Redis · Rust WebSocket services · load-balanced VPS nodes · LLM APIs (2023–24)
A paid access is one purchased entry to one show, event or premiere. One user could buy many, which is why the figures are always shown separately.
Real screens, 2021: home and an event page. Pictured content belongs to the artists.
It started simple. I didn’t rewrite it.
The first version used WordPress and WooCommerce.
That was intentional. I needed to get a real product into people’s hands quickly, and rebuilding commerce, content management and administration from scratch would have been a terrible use of time.
WordPress worked well, until some parts of the product started needing very different things from it. A full rebuild would have stopped product work and put a business that was already processing real transactions at risk. So I kept WordPress where it was useful and gradually separated the workloads that were becoming bottlenecks.
The steps are in the order they happened. Each one was a response to a load, latency or operational problem the previous stage exposed.
Traffic spikes changed the architecture
Premieres were not normal ecommerce traffic.
Thousands of people could arrive within a very short window, authenticate, access content and start interacting at almost the same time.
I isolated the database, put the application behind a load balancer and added multiple VPS nodes so the web layer could scale horizontally. Redis became shared infrastructure across those nodes.
That architecture eventually handled peaks of roughly 10K concurrent users during a high-demand premiere.
Realtime didn’t belong inside WordPress
Chat and session control had another problem: connections stayed open.
I didn’t want thousands of persistent WebSocket connections competing with checkout, authentication and content access.
So I moved realtime work into lightweight services written in Rust.
The important part wasn’t Rust itself. It was being able to scale realtime independently from the rest of the product.
Access control moved there too. Content could be watched on one device at a time per account, a rule stated on every event page and in the terms, and the realtime layer could enforce it without putting more work on the core application. Scaling also made some old assumptions less acceptable, so I modernized parts of the authentication stack, including moving credential hashing to Argon2id.
WordPress stayed. The frontend changed around it.
I also didn’t want a frontend rewrite just because the product needed richer interactions.
Instead, I gradually introduced dynamic islands where the experience actually benefited from client-side behavior, and lightweight endpoints for the simple, frequent customer and creator actions that didn’t need the whole application stack to answer. WordPress kept doing the things it was good at, CMS, commerce and administration, while more interactive pieces could evolve separately.
It was less elegant than starting from a blank architecture diagram. It was much safer for a product people were already paying to use.
Support moved into the player too: a quick-solutions panel for the minutes before a show starts, when nobody has time to open a ticket.
Generative AI came later
ComediaPlay did not start as an AI product.
I began adding Generative AI workflows in 2023–2024, when the models had become useful enough to solve real product and operational problems.
Turning metrics into useful advice
Creators already had data. The problem was that numbers still had to be interpreted.
I built endpoints that calculated and exposed product and business metrics, then converted those metrics into structured, readable context before sending them to a model through an API.
The model didn’t calculate the numbers.
The application did that first.
The model read that context and turned it into explanations and personalized recommendations for creators.
That separation mattered to me: the system remained the source of truth, while the model handled interpretation and communication.
Writing event pages without starting from zero
Event publishing had another repetitive step: writing useful descriptions from information that already existed in the platform.
I started using structured event data as context for the model to generate or complete SEO-oriented descriptions.
The creator still controlled what was published.
Closing the platform
Most of ComediaPlay’s activity and results were concentrated through 2024. Sales continued at a lower volume through the end of 2025. No new events or content were added in 2026, and I closed the platform definitively in August 2026.
It changed how I think about product design. A checkout problem could turn into an infrastructure problem, and a licensing rule into a session architecture problem. I stopped thinking of the interface as the product. The product was the whole system behind the experience.