Shipping Event Management with AI

How AI compressed implementation time and exposed design clarity as the true bottleneck.

2026-01-09

Shipping Event Management with AI: When Design Became the Bottleneck

Executive Summary

RallyHub helps everyday pickleball players organize, join, and record casual play - sessions that matter personally but are rarely captured by formal leagues or rating systems. In this release, I shipped end-to-end event management across web and iOS, enabling users to host sessions, invite guests, manage capacity, and connect active events to match recording in the mobile app.

This work took approximately 7-8 days of focused effort over a calendar window of December 18, 2025 to January 9, 2026 (with limited work time during travel and holidays). AI-assisted development accelerated implementation significantly, but the primary constraint was not coding speed - it was design clarity. Once implementation became cheap, ambiguous workflows and missing invariants became expensive.

The central lesson is simple:

In AI-accelerated development, design decisions - not code - become the bottleneck.

1. Context: The Real Problem Being Solved

RallyHub is designed for pickleball players everywhere, with a focus on casual, social play. Most pickleball sessions are informal: friends meet at a public court, invite others via text, rotate partners, and occasionally want a lightweight record of what happened. These sessions rarely produce durable history, and most existing tools target competitive play.

RallyHub is not:

• a tournament management platform,
• a player rating system,
• or a simple "find a match" app.

Instead, it aims to become a pickleball passport - a record of play history and the connections formed along the way.

Event and session management are foundational to that vision. Players need to create sessions, invite participants (including non-registered users), manage attendance and capacity, and transition smoothly from scheduled play to active sessions where match recording happens on mobile.

2. What This Release Added

This release introduced end-to-end event management:

• Hosts can create events and invite others via a URL.
• Participants - including non-registered users - can join events from the invitation link.
• The system manages capacity and attendance behavior.
• Events integrate with the iOS app so that an active (ongoing) event can be used during match recording.

Most of the event experience lives on the web today, but events are now first-class across both web and mobile.

3. Initial Assumptions (and Why They Were Incomplete)

I started with several assumptions:

• Event management would be simple: record time and attendance.
• Guests could be treated as lightweight accounts.
• Mobile integration would be straightforward.
• Testing would be easy through E2E scenarios.

These assumptions were reasonable, but incomplete. AI made it easy to move from intent to working code quickly, which delayed confronting what the system should do in edge cases and real-world usage.

4. Where I Had to Stop and Rethink

Once implementation began, I realized I had not clearly defined user scenarios or the distinction between public and private events. I transitioned into implementation before conducting a thorough design and workflow discussion, which meant key decisions were implicit.

I did not need to reverse course entirely, but once partial functionality existed, rethinking became cognitively expensive. I was constantly balancing what already worked against what the product should actually do.

Three areas drove most of the rework:

Guest Users and Identity

Anonymous participants do not have user IDs. Supporting guests required decisions at both product philosophy and system architecture levels. I eventually supported guest sessions so users could join without registration, but implementing this after a working version existed increased cost.

Mobile Integration

I had a vague idea of how events would integrate into match recording, but the workflow was not explicit. Spending one or two hours earlier to define mobile flows and constraints would likely have avoided multiple rounds of iteration.

Event Lifecycle

Late in development, I realized users had no clear way to transition an event into an ongoing state. Lifecycle management had to be designed and implemented at the end, across both web and mobile.

AI increased the temptation to generate schemas and UI quickly because it feels like progress. The cost appears later when the system needs coherent behavior under real-world usage.

5. The Real Bottleneck: Design Ambiguity

The constraint was not implementation speed. It was ambiguity.

AI can generate schemas, RPCs, UI flows, and tests that "kind of work," creating a false sense of progress. Once those artifacts exist, unresolved questions become harder - not easier - to answer:

• What does it mean for an event to be public?
• Who is allowed to join, and under what conditions?
• What transitions exist in the event lifecycle, and who triggers them?
• What becomes immutable after publishing?
• How should capacity changes behave deterministically?
• How does guest identity evolve if a user later registers?

In AI-driven development, it is easy to build before deciding. The result is not just technical debt - it is design debt, and it compounds quickly.

6. AI-Augmented Development Workflow

Development followed a clear separation of responsibilities between decision-making, implementation, and validation.

Diagram: AI-augmented development workflow used in RallyHub. ChatGPT acts as the primary reasoning and design agent, while coding agents (Codex, Claude Code, Gemini) handle implementation, testing, and mechanical investigation. The human remains responsible for judgment, validation, and final approval.

7. Fundamental Design Decisions

Several decisions became foundational because they cut across backend, web UI, and mobile integration:

• Event state transitions
  Defining what each state means and who can trigger transitions.

• Visibility vs join policy
  Clarifying public versus private semantics and invitation behavior.

• Guest to registered identity handling
  Preserving participation history across identity transitions.

• Mutability after publish
  Enforcing which properties can change after publishing.

• Capacity enforcement rules
  Ensuring deterministic and fair behavior when capacity changes.

• E2E testing framework
  Validating workflows end-to-end rather than isolated endpoints.

8. Where AI Accelerated Development

AI provided significant leverage in several areas:

• Rapid generation and evolution of E2E test scenarios.
• Design exploration using a primary agent with full product context.
• Delegating implementation and refactoring to a coding agent.
• Investigating existing code paths before making cross-cutting changes.

In practice, this evolved into a two-agent loop: one agent for product and design clarity, and another for implementation.

9. Where AI Did Not Help

AI was less effective in two recurring ways:

• Real-world judgment
  Deciding how features should behave in messy, real-life scenarios required opinionated human direction.

• Debugging loops
  Implementation agents sometimes became stuck chasing test failures while missing issues obvious through manual inspection.

AI is powerful, but it still requires intent, constraints, and decisive guidance.

10. Process Changes Mid-Flight

At the beginning, I relied on lightweight design discussions and quickly moved into implementation. AI makes this easy by producing working-looking code even when requirements are incomplete.

Midway through, I changed my approach:

• I spent more time defining workflows and invariants explicitly.
• I forced decisions earlier, before implementation.
• I used the design agent to produce structured prompts for the coding agent.

Once I adopted this approach, velocity improved and rework decreased.

11. What Shipped

As a result of this work:

• Hosts can create events, invite friends, and rely on the system to manage capacity.
• Participants can join events from invitation URLs without installing the app.
• Guests can join without registering.
• Event lifecycle transitions are enforced consistently.
• Active events integrate directly into the iOS match-recording experience.

This is not just a feature set, but a cohesive workflow: scheduling, joining, playing, and recording.

12. What I Would Do Differently Next Time

If I were building this again, I would:

• Define event lifecycle invariants on day one.
• Clarify public and private semantics before schema changes.
• Design mobile workflows before web flows.
• Treat guest identity as a first-class concern from the start.
• Write scenario matrices before implementation.

13. General Lessons for AI-Driven Development

This release reinforced several broader truths:

• When implementation becomes cheap, decision quality becomes the dominant constraint.
• The primary risk shifts from technical debt to design debt.
• Senior value shifts from coordination to clarity ownership.
• Smaller teams can ship more - but only with early, explicit decisions.

Closing

AI did not reduce the importance of experience in this project - it amplified it. The ability to recognize ambiguity, make principled decisions, and impose structure became more valuable, not less.

This release was not only about shipping event management. It was about adapting how software development itself must work in an AI-accelerated world.