From Idea to First Partner: OnStage
November 2024. I had the idea, but an idea without validation is just an opinion. I knew that to build something useful I had to talk to people who actually organize events.
Luck would have it that I already knew someone: the cultural association OnStage, a group of theater and music enthusiasts who have been organizing events in Salento for years. Evenings, shows, festivals. Dozens of events per year.
What You'll Find in This Article
- How I found the first partner to validate the idea
- Agile methodology applied to a side project
- Real requirements that emerged from the collaboration
- The first sprint and initial features
Why OnStage Was the Perfect Partner
OnStage wasn't just any association. They were the ideal use case for Play the Event.
Their Profile
- 15-20 events per year
- From 30 to 200 participants
- Team of 8 organizers
- Limited budget but real needs
- No dedicated tool
Their Pain Points
- RSVP management via WhatsApp
- Participant lists on Excel sheets
- Fragmented communications
- No event history
- Difficulty tracking payments
I proposed a simple deal: you be my beta testers, I build the tool for free. They would get a custom platform. I would get real feedback from real users.
"Finally someone who understands that we're not a company but
we're not a birthday party either. We're in the middle, and nobody
thinks about us."
— Marco, OnStage president
Agile Methodology for a Side Project
I couldn't dedicate 40 hours a week to Play the Event. It was a side project, developed in the evenings and on weekends. But that didn't mean giving up on a structured approach.
I adapted Scrum to my needs: 2-week sprints, shared backlog with OnStage, demo at the end of each sprint.
SPRINT STRUCTURE (2 weeks)
MONDAY EVENING (1h)
├── Sprint Planning
├── Backlog review with OnStage (via call)
└── User stories selection for the sprint
TUESDAY-SUNDAY
├── Development (2-3h/day when possible)
├── Frequent commits
└── Deploy to staging environment
FOLLOWING MONDAY (1h)
├── Sprint Review with OnStage
├── Demo of new features
├── Feedback collection
└── Sprint Retrospective (what to improve)
ARTIFACTS
├── Product Backlog (Notion)
├── Sprint Board (Notion Kanban)
├── User Stories with acceptance criteria
└── Clear Definition of DoneThe First Meeting: Requirements Gathering
The first meeting with OnStage was enlightening. I showed up with a vague idea of an "event platform". I left with a list of concrete problems to solve.
How I Conducted the Meeting
I didn't talk about technology. I didn't show mockups. I did just one thing: I listened.
The Questions I Asked
- "Tell me about the last event you organized." Step by step, from the first idea to the end.
- "What was the most frustrating part?" What made you lose the most time?
- "If you could change one thing about the process, what would it be?"
- "What tools do you use today?" Why those specifically?
The Problems That Emerged
Problem #1: The Confirmation Chaos
For every event, they received confirmations via WhatsApp, email, Instagram messages, and in person. No centralized point. Every time they had to manually reconstruct the participant list.
Problem #2: Ghost Payments
Paid events were a nightmare. "Who paid? Who still needs to pay? How much is missing to cover costs?" All on an Excel sheet that nobody updated in real-time.
Problem #3: Fragmented Communication
Did they need to send updates to all participants? That meant sending the same message to 3 different WhatsApp groups, plus emails to those not in the groups.
Problem #4: Zero History
"How many people came to last year's event?" Nobody knew. Every event started from scratch, without historical data to rely on.
From Problems to User Stories
After the meeting, I translated the problems into user stories following the standard format.
US-001: EVENT CREATION
As an organizer
I want to create an event with date, location and description
So I have a central reference point
Acceptance Criteria:
- Form with fields: name, date, time, location, description
- Automatic generation of a shareable link
- Save to database
US-002: SIMPLIFIED RSVP
As a participant
I want to confirm my attendance with one click
So I don't have to write messages or emails
Acceptance Criteria:
- Public page accessible without login
- Buttons: I'll attend / I won't attend / Maybe
- Optional notes field (e.g., allergies, +1)
US-003: REAL-TIME PARTICIPANT LIST
As an organizer
I want to see who confirmed in real-time
So I always know how many people to expect
Acceptance Criteria:
- Automatically updated list
- Filters: confirmed, declined, pending
- Export to CSV/Excel
US-004: CENTRALIZED NOTIFICATIONS
As an organizer
I want to send a message to all participants
So I don't have to use 5 different channels
Acceptance Criteria:
- Send email to all confirmed attendees
- Customizable template
- Sent messages history
US-005: PAYMENT MANAGEMENT (v2)
As an organizer
I want to track who paid and who didn't
So I always have a clear financial picture
Acceptance Criteria:
- "Paid yes/no" field for each participant
- Total collected vs total expected
- Automatic reminder to those who haven't paidSprint 1: The MVP
With the backlog ready, I planned the first sprint. The goal was clear: build a working MVP that OnStage could use for their next event.
SPRINT 1 (2 weeks)
Goal: "An organizer can create an event and receive confirmations"
SELECTED USER STORIES:
├── US-001: Event creation (5 points)
├── US-002: Simplified RSVP (8 points)
└── US-003: Participant list (5 points)
CAPACITY: 18 points (realistic for a side project)
COMMITMENT: 18 points
TECHNICAL TASKS:
├── Project setup (Next.js + Supabase)
├── Events and participants data model
├── REST API for events CRUD
├── Event creation page
├── Public RSVP page
├── Participant list dashboard
└── Deploy to VercelThe First Demo
Two weeks later, I had something to show. It wasn't perfect. The UI was minimal. But it worked.
I did the demo for OnStage via video call. Their reactions told me everything I needed to know.
"Wait, I can just send this link and people click to confirm?
Without having to download anything?"
— Elena, OnStage organizer
"And the list updates automatically? I don't have to ask
'who said they were coming?' every time anymore?"
— Marco, OnStage president
Sprint Review Feedback
What Worked
- Shareable link without login
- One-click RSVP
- Real-time participant list
- Simple interface
What Was Missing
- Field for +1 (companions)
- Notes visible to the organizer
- Reminder for non-responders
- Improved mobile version
The Iterative Approach in Action
This is the beauty of the agile approach: I didn't have to guess what was needed. I built, showed, collected feedback, improved. Every sprint delivered real value.
SPRINT 1: Event creation + Basic RSVP + Participant list
→ OnStage uses it for "Jazz Evening" (45 participants)
SPRINT 2: +1 field + Participant notes + Email reminder
→ OnStage uses it for "Theater Under the Stars" (120 participants)
SPRINT 3: Basic payment management + CSV export + Mobile responsive
→ OnStage uses it for "Christmas Concert" (200 participants)
METRICS AFTER 6 WEEKS:
├── 3 events managed
├── 365 total participants
├── 0 "who's coming?" emails sent
├── 100% of confirmations tracked
└── Time saved: ~10 hours per eventWhat I Learned
Lessons from the OnStage Collaboration
- A real partner is worth more than 100 interviews: Watching someone use your product for a real event teaches you things no survey can tell you.
- Agile works for side projects too: Short sprints, frequent feedback, rapid iterations. You don't need a team of 10 people.
- Start with the most painful problem: For OnStage it was RSVP management. I solved that before everything else.
- Simplicity is a feature: Every time I added complexity, the feedback was "can't it be simpler?"
- Value is measured in time saved: 10 hours saved per event = tangible and measurable value.
In the Next Article
With a validated MVP and a satisfied partner, it was time to think big. How to scale from one association to hundreds of organizers?
In the next article I'll talk about architectural choices: why I chose that technology, how I structured the database to support growth, and the decisions that will define the future of Play the Event.
Key Takeaways from This Article
- Find a real partner willing to use your product
- Use agile methodology even for side projects
- Gather requirements by listening, not proposing solutions
- Build, show, collect feedback, iterate
- Measure value in time saved for users