30 days in: from first commit to a 3,500-person conference

It's Friday night and I'm reading webhook logs.

Three days from now, 3,500 people will show up in Houston for Black Is Tech Conference. When they do, the platform running the attendee experience will be Gythr. The ticketing. The agenda. The sponsor deliverables. The networking. All of it flowing through software I didn't have when I woke up one month ago today.

On March 17, 2026, I pushed the first commit for Gythr. It was the framework. Just the framework. No modules. No database schema. No branding. A Next.js app, a Supabase connection, and a folder structure that would become a system.

Thirty days later, we go live.

I want to write this down while it still feels impossible, because in a month it will feel inevitable, and the thing I want to remember is that it wasn't.

The decision

I've been in event operations for years. I've run the conferences where something almost went wrong at 7pm the night before. I've held together the stacks of ticketing plus networking plus agenda plus email platforms, all pretending to be a system. I've watched organizers burn out doing the translation work between tools that should have been talking to each other from the start.

I'd been thinking about what an event operating system should look like for a long time. Writing notes. Sketching architecture. Talking to organizers. The idea wasn't the problem. The idea had been ready for a while.

What changed on March 17 wasn't the idea. It was the decision to stop being someone with an idea and start being someone with a commit history.

Week one: the framework

The first week was infrastructure. Not sexy, not demo-able, not something I could show anyone. But everything that came later depended on getting this part right.

I set up the monorepo. I decided on the module architecture. Gate for ticketing, Bridge for networking, Stage for speakers, Partners for sponsors, Agenda for scheduling, Signal and Comms for the communication layer. Seven modules that would need to share data without being glued together with integrations. One Supabase database, one shared schema, one source of truth.

I picked the brand palette in the same week. Dark background, citron accent, violet and cyan for depth. I named things. I wrote the voice rules. No em dashes. No jargon. Organizer as hero. I did this early on purpose. A brand locked down early means I stop relitigating it every time I write a button label.

By the end of week one I had an empty system with strong bones. That mattered more than shipping features fast. The thing most event platforms get wrong is treating architecture as something you'll figure out later. Later is when it becomes impossible to fix.

Week two: the first module and the first scare

Week two was Gate. Ticketing. The first real module.

It went well until it didn't. I'd architected the webhook integration with Tito. Our first design partner, Black Is Tech, was already using Tito for registration, and I wanted Gythr to sync attendee data without making them migrate. The elegant version was to receive webhooks from Tito and write them into Gythr's database in real time.

The first time I tested it end-to-end, the webhook fired, the data arrived, and Gythr did nothing with it. Silent failure. No error. Just a successful HTTP 200 response and no record in the database.

I spent the better part of a day debugging. It was a schema mismatch. Tito was sending a field I'd named differently in my own model, and my handler was silently dropping rows that didn't conform. No exception, no log, no visible breakage. Just data quietly disappearing.

That scared me more than any loud failure would have. Because the whole premise of Gythr is that organizers can trust the data to flow correctly between modules. If I could ship a silent data loss bug without knowing it, so could anyone. I rewrote the handler that afternoon with explicit logging, explicit validation, and explicit failure modes. If data doesn't make it through, I need to know.

That lesson cost me a day. It probably saved me from a much worse day later.

Week three: the design partner

Week three I signed the first design partner agreement.

Black Is Tech Conference. 3,500 attendees. Five days in Houston. The agreement was real. A legal document. A signed contract. A partnership with specific deliverables and a deployment date. I'd written a Design Partner Agreement generator as one of the first tools I built for Gythr, partly because I knew this moment was coming and I wanted the paperwork to match the professionalism of the product.

Signing was the easy part. So was showing them what Gythr could do. That was actually the easiest part of all. Nothing else could do it. Nothing else could fill the gaps they had and connect the systems they were already running. The value was obvious the moment we walked through it.

The hard part was convincing them to trust the product mid-flow. They were already deep in conference prep. They already had tools in place for pieces of what Gythr does. Asking them to fold in a new platform four weeks out from a 3,500-person event wasn't a small thing. It was a risk, and they knew it, and I knew it, and we had to be honest with each other about it.

The hard part was figuring out how to onboard them without breaking what was already working. How to integrate with the tools they were already using without forcing migrations they didn't have time for. How to promise a better attendee experience and actually deliver on that promise, because the attendee experience is what every organizer is ultimately measured on. Get that wrong and nothing else matters.

I spent most of week three on those questions. Not building. Listening. Mapping their actual workflow. Understanding where Gythr could slot in cleanly and where it would create friction. Deciding what to defer. Deciding what had to ship.

The honest truth is that this is the part that scared me most. Not the technology. The weight. A design partner is trusting you with something real. Their attendees, their sponsors, their reputation, the months of work they've already put in. If I got this wrong, it wouldn't just be my problem. It would be theirs, and they'd deserve better.

I told them that, in exactly those words, in our first working session. I said: you are trusting me with something big, and I want you to know I'm taking that seriously. And then I got to work.

Week four: the sprint

The last week is a blur.

Webhook integration, tested with real data. Gate handoff, the peer-to-peer ticket transfer system, designed, specced, and partially built because organizers kept telling me this was the piece that every other platform gets wrong. Stage module for speaker management. Partners module for sponsor deliverables. Mixle networking integration, figured out and shipped in a way that respects all three entities involved: Gythr, Mixle, and the organizer. Branded email templates in the Gythr design system, going out from notifications.gythr.com.

I worked late. Not in a romanticized way. In the way where you realize at 2am that you've been staring at the same bug for an hour and the right thing to do is sleep and come back to it.

I shipped things I was proud of. I shipped things I wasn't proud of but knew I could iterate on. I cut features I'd promised myself I'd build, because the difference between a design partner deployment that works and one that's feature-complete is the difference between a product that ships and one that doesn't.

The thing I kept reminding myself: Black Is Tech doesn't need the perfect Gythr. They need the Gythr that works for their event. Everything else is next month's problem.

What I'd do differently

I'd build the monitoring and logging infrastructure before I'd built the features. The webhook scare in week two would have caught itself if I'd had the observability layer I eventually built. I spent too long flying blind.

I'd have written the architecture document before the first commit, not in week two. I wrote a version of it, but I wrote it while I was building, which meant I kept contradicting myself. Writing it first would have cost me a day and saved me three.

I'd have talked to more organizers in week one. I talked to plenty before March 17. But the questions you ask when you have an idea are different from the questions you ask when you have a prototype. I wish I'd been running the prototype questions earlier.

I wouldn't change the design partner decision. Black Is Tech was the right first partner for reasons that don't fit in this post but that I'll write about soon. Saying yes to a real deployment with a real deadline compressed my timeline in a way nothing else could have. A demo with no deadline would have become a demo forever.

What's next

Monday morning, Black Is Tech Conference 2026 goes live on Gythr. I'll be in Houston. I'll be watching the dashboards. I'll be answering Slack messages from the Black Is Tech team. I'll probably not sleep much.

I'll write about what happened after. The real case study, with real outcomes, is a post I get to write because I shipped.

If you're an event organizer reading this and wondering whether a platform that's 30 days old can be trusted with your conference: that's a fair question, and the answer is that it depends on what you care about. If you care about a long track record, we don't have one yet. If you care about a platform built by someone who has run events, who has felt the cost of broken software, and who is making decisions with the organizer's reality in mind, we might be the partner you're looking for.

If you're a founder reading this and wondering whether 30 days is enough: the first commit is the only one that matters. Everything else is downstream of deciding to start.

If you're an investor reading this and wondering about trajectory: watch what we do with the next 30.

I'll be writing it down either way.

Rebecca