How Rilla supported a 2000 person conference with Major

The Challenge

Rilla hosts the Masters — a flagship, multi-day conference that brings together enterprise prospects, partners, and the broader Rilla community. The 2025 edition was their biggest yet: three days, 2,000+ attendees, multiple product launches, breakout sessions, and live demos.

Running an event like that requires a constellation of internal tools — registration check-in, badge reprinting, attendee queue management, on-site ticket purchasing, and more. The problem: Rilla's engineering team was fully occupied building the products they were launching at the event itself. Internal tooling kept getting deprioritized.

To make matters worse, many of these tools couldn't be off-the-shelf SaaS. They needed to plug directly into Rilla's proprietary database, marketing pipelines, and event registration system. Each new attendee had to be tracked across campaigns, registered for sub-events, and synced with multiple internal systems.

"We can't just use a public tool to do that because it needs to plug into our security systems and our databases." — Alexander Jabbour

The Year Before

At the previous year's Masters — a smaller, one-and-a-half-day event with far fewer attendees — the team spent two to three weeks building internal tooling. They had to spin up a dedicated service, provision database access, configure environment variables, and deploy through Vercel. The agentic coding tools available at the time were weaker, the models were weaker, and the workflow was largely manual.

Even after all that effort, the tools had to be reworked multiple times before the event. It was a painful, expensive process for a set of apps that would only be used for a few days.

Building with Major

This year was different. On the first day of the Masters, the team realized they had gaps — there was no app for non-technical registration staff to update attendee records, no way to handle walk-up ticket purchases, and no system for managing the demo queue. These were problems they hadn't fully anticipated.

Rather than scrambling to stand up infrastructure, Alex opened Major and started building. Within 15 minutes, the registration team had a working app that let them update badge names and company information without touching a database directly. Because Major connects natively to Rilla's existing environment variables, databases, and design system, there was no provisioning step — just code and ship.

The biggest benefit of Major: your infrastructure is managed by someone else. All you have to do is give your environment variables, give your code, and everything just works. It's a level of abstraction above containerization — you don't worry about infrastructure, just the functionality.

The team also built an external-facing app for demo queue management. With 2,000 attendees and capacity for only a handful of people at a time, they created a QR-code-based queuing system. Attendees scanned a code, entered a queue, and received a time slot — all powered by a Major app that read and wrote directly to Rilla's database. Because Major supports public apps, there was no need to stand up a separate backend or deploy to another hosting provider.

When bugs came up during the event, any engineer could fix them on the spot — opening a Claude Code terminal, describing the issue, verifying the fix with Playwright, and pushing to Major, all agentically through the CLI. No manual version control, no manual testing. The entire build-test-deploy loop happened in one pass.

"Using Major has opened my eyes to how much better modern development is with agentic tools. The toolset you have on Retool is just incomparable — it's like day and night compared to what we have as modern engineers." — Alexander Jabbour

Why Not Retool?

Rilla had an existing Retool footprint, but for Alex, the comparison was clear. Retool's visual builder felt unintuitive for engineers, lacked version control, and frequently broke. Major, by contrast, fits the way modern engineers already work — writing code in their own environment, using their own design system, deploying through a CLI.

The risk calculus was straightforward: even in a worst-case scenario, Rilla would still own all the code. There's no lock-in to a proprietary visual builder with no portability. Alex's teammates who had been building on Retool started migrating to Major on their own — not because anyone mandated it, but because the experience was simply better.

The Results

What took weeks the year before now took minutes. The team shipped multiple internal and external-facing tools over the course of a three-day event — without pulling a single engineer off their core product work. Non-technical staff at the registration booth used Major-built apps without ever knowing or caring about the underlying infrastructure. And when problems appeared in real time, they were fixed agentically and redeployed in a single pass.

Alex summed it up simply: Major let them solve problems they didn't even know they'd have, at a speed that matched the pace of a live event. For a team that was already stretched thin, that was the difference between a smooth conference and a logistical crisis.