all work

Team Lead & Eng. Manager

Veeps

Rebuilding a livestream concert platform from Ruby on Rails to Elixir and Phoenix, so it could survive the moment a million fans hit "buy" at once.

My Role
Team Lead & Eng. Manager
Promoted To
Eng. Manager · May 2021
Client
Veeps (via DockYard)
Timeline
Sep 2020 – Dec 2021
01 overview

Overview

Veeps is a ticketed livestream platform that hosts digital concerts for some of the world's biggest musicians. It began as a way for artists to sell VIP packages, then pivoted hard into livestreaming when the pandemic shut down in-person shows. The traffic that came with that pivot quickly outgrew what the original product could handle.

DockYard partnered with Veeps to rebuild the platform in Elixir and to embed senior engineers alongside their team. I was the team lead on the engagement from the start, and midway through, in May 2021, I was promoted to Engineering Manager, taking on my first reports while continuing to lead the build.

10–100×
target usage volume
90%+
test coverage, up from near zero
11
person team I led (8 eng · 2 QA · 1 UX)
02 the problem

The problem

The original Ruby on Rails app was never designed for the volume Veeps was suddenly seeing, and demand was outpacing the platform's ability to keep up. It's the kind of inflection point startups hit when growth outpaces the engineering underneath it.

"If a top artist posts an event link to a hundred million fans, can the system absorb a million clicks in a minute and still hand out exactly twenty thousand tickets?"

That "thundering herd" problem was the headline challenge. Underneath it sat real technical debt: the legacy app used schema-based multitenancy (via the since-abandoned Apartment gem) that had spawned thousands of Postgres schemas and put crushing weight on the database, to the point that production backups were failing.

03 phase one

Phase one: stabilizing the legacy app

Tight timelines and an app crashing under load meant we couldn't wait until after the rewrite to deal with the data. My first months on the project went into hardening the existing Rails application and clearing a safe path forward. In that stretch I:

  • Drove test coverage from near-zero to over 90%, turning a fragile codebase into one the team could change with confidence.
  • Led the database migration off schema-based multitenancy, collapsing thousands of per-tenant schemas into a single-tenant, table-based model and removing a major class of bottlenecks and bugs before a line of Elixir was written.
  • Used a prefactoring approach, reshaping the data model with UUID keys and backfills run during low-traffic windows so the eventual migration would be smooth and low-risk.

That cleared the path for everything that followed. A clean, consolidated data model gave the rewrite solid ground to stand on.

04 the rewrite

The rewrite: Ruby on Rails to Elixir & Phoenix

With the legacy app stabilized, we rebuilt the platform on Elixir. Running on the Erlang VM, with decades of engineering behind it dedicated to concurrency and reliability, Elixir was the natural fit for a product whose whole job is absorbing enormous bursts of simultaneous activity. Paired with Phoenix and LiveView, it let us ship rich, real-time experiences quickly.

I led the team that built the backend and the administrative "backstage" side of the new platform:

  • A multi-layer ticket reservation system, the direct answer to the thundering-herd problem, built to absorb a flood of concurrent requests and release exactly the right number of tickets without buckling.
  • The backstage for artists and venues, with dashboards giving them real-time insight into fans, ticket sales, and revenue, plus the controls to run their events.
  • A secure, reliable checkout built to stay dependable under peak load.
05 two jobs at once

Two jobs at once: leading while becoming a manager

My role went well beyond team lead. In practice I was also the de facto client partner, account manager, and product owner, handling the hard conversations and managing expectations directly with the client through some difficult stretches. And I did all of it while onboarding as a brand-new engineering manager, picking up my first direct reports mid-engagement.

I led a team of eight engineers, two QA, and one UX resource, a mix of DockYard and Veeps developers, and brought real engineering discipline to a startup codebase: branch protection and required code review, static analysis with Dialyzer and Credo, a comprehensive test suite, and a CI pipeline that ran the full data migration on every build so application changes could never quietly break the path to launch.

06 impact

Impact

The rewrite did more than put out the immediate fire. It gave Veeps a foundation built for 10 to 100 times the usage volume, with LiveView keeping ongoing development fast and inexpensive. The second statement of work delivered on time, the client extended the engagement for the data migration, and the new platform launched in December 2021.

We also left the team with the tools to keep improving: performance-testing and benchmarking dashboards, plus flame graphs that pinpointed where to optimize request paths and where to cache for the biggest speed gains.

07 tech stack

Stack

Core technologies on this project:

Elixir Phoenix Phoenix LiveView Erlang / BEAM PostgreSQL Ruby on Rails (legacy) Sidekiq Dialyzer Credo CI/CD
Next · Engineering foundations
Prodicle Distribution