Six years at Crowdcast

The interview

In early 2020 I was looking for a new challenge. My freelance gig at the time had become unsatisfying, so I was browsing remote JavaScript job boards when I stumbled upon an ad by Crowdcast, a platform for running live video events. It sounded super interesting and I was excited about the prospect of working for a US tech startup.

I got invited to a call and prepared thoroughly — I read up on their engineering blog to understand the technical challenges they were facing and to get a feel for their culture. The interview went well, and then came the anxious wait. It took them a bit longer to respond than anticipated, but when the positive answer finally arrived I was over the moon. I was literally jumping on the bed with my partner. Everything felt great, I was on top of the world.

That was one week before the COVID lockdowns started in Europe.

The COVID rocket

For the next six months I was locked inside my flat with not much else to do, so I could fully focus on the new remote job. And there was a lot to focus on: Crowdcast being an online video event platform, COVID turned out to be an incredible catalyst for the business. Within a few months we saw customers and revenue grow by several hundred percent.

When I started, the company was just the CEO, a mobile developer, one customer support person and me. Within a year we scaled to around 20 people across customer support, sales, marketing and engineering.

But the hypergrowth also exposed the cracks in the platform. Due to the nature of live events we experienced irregular, extreme spikes of traffic, and a single big event could affect the entire platform — database blocks, Firebase timeouts, the works. Big companies like Siemens came to us wanting to run huge events that we simply could not support at the time. I wrote about some of these scaling issues in more detail in this post.

The rebuild

We initially scored some wins by extracting the live chat into its own microservice to take load off Firebase, and by introducing different caching strategies. But Firebase Realtime Database — already a legacy product at that time — could not be scaled any further. Eventually we decided we had to re-architect the entire platform from scratch.

The rebuild gave us the chance to fix more than just the database:

• Angular → React/Next.js. The old client-side Angular monolith was slow and hard to maintain. We wanted server-side rendering and a component-based architecture, and we adopted TypeScript throughout the stack.
• Postgres on AWS. Our biggest issue had been database scalability, so we moved to a database we could fully control.
• AWS Lambda. For the backend we went serverless — no single point of failure, automatic scaling with demand, pay-as-you-go.
• EventBridge and SQS. Communication between the different services was handled through events and queues.
• Hasura GraphQL. For maximum flexibility between the new and the legacy data model, Hasura let us auto-generate a GraphQL API on top of the new Postgres database while integrating legacy APIs through remote schemas.

What we got wrong (and right)

In hindsight, Hasura was a mistake. Their "realtime" subscriptions are not really realtime — they poll Postgres every second, which both feels slow and, as we discovered later, led to serious database performance problems. Hasura also changed their billing and business model with v3, which became really confusing for us (we stayed on the self-hosted v2 community edition). Honestly, a classical REST API architecture would have served us better — which is what we eventually moved to. In 2024 we started adopting Supabase and migrating away from GraphQL. Supabase offers much better realtime subscriptions and overall feels like a way better product and service than Hasura.

Other bets paid off, though. We migrated the live video centerpiece — the WebRTC infrastructure — from Vonage to LiveKit, which was a great choice: significantly cheaper, with a modern, flexible, event-driven API. Really good experience overall.

Another area we struggled with was the reliability of our streaming and recording engine. Orchestrating the different services and making them work together reliably was a big challenge in the new event-based architecture. We later adopted Temporal to handle workflow reliability and moved the workloads to Kubernetes on Hetzner, which was significantly cheaper than AWS. Since we had implemented our entire infrastructure as code using Terraform, we were relatively cloud-agnostic and could move between providers quickly — even run a multi-cloud setup.

The AI shift

In 2024, LLM-based development really started to take off — first with tools like Copilot, then Cursor became the new standard with AI agents directly integrated into the editor. Then came Codex and Claude Code, and developer productivity skyrocketed. Things that previously took us weeks to implement could suddenly be done in a few days.

Looking back, I still can't believe how quickly everything changed. As someone who always liked being on the cutting edge of technology, I fully embrace this shift — but it also makes me a little nostalgic to remember how we wrote everything by hand, just a few years ago.

The hard part

Here is the uncomfortable truth about running a live video event platform: the best and most interesting events draw the most users — and thus have the highest chance of something going wrong. We had a couple of big failures where the platform crashed during peak times. Attendees would start complaining in the chat while the event was still running, which made the hosts (and us!) feel terrible. Some of those hosts cancelled afterwards, and winning back a customer you lost is much harder than keeping one in the first place.

After the peak in 2021, the business slowly but steadily declined. The team shrank back down to five people, and towards the end I went part-time — helped by the fact that fewer developers, armed with AI, can now get more things done in less time. So when my time there eventually came to an end, it didn't come as a surprise. I had seen it coming, and honestly, it felt right.

Moving on

I really loved this job — at some point I even described it as my Ikigai. But after multiple rewrites, I feel like my part of the story is done.

I have nothing but love for the team and I'm confident they will continue to deliver exciting new features. They recently shipped v3, which comes with a lot of stability fixes and improvements for running interactive events.

As for me, I'm now focusing on AI-based projects. It feels like an exciting new challenge, and I fully embrace it.