Lessons from a long zero-to-one
EventSpase was a four-year 0→1 exploration. Two pivots, a 1,900-student campus pilot, a 300-user creator beta in South Africa, and the lessons that shape how I approach 0→1 work now.
Why this case study exists
EventSpase didn’t become a category winner. I’m keeping it in my portfolio anyway, because four years of designing, shipping, researching, pivoting, and running a real React Native codebase taught me more about 0→1 product than any single launch could have. This is the long version. If you want the short version, it lives on my about page.
Problem
Events on campus weren’t failing because students didn’t care. They were failing because the information lived in too many places. Newsletters, Instagram stories, Facebook, GroupMe, screenshots in group chats. Organizers posted the same details across five platforms and still watched turnout flop. We narrowed the problem to one question.
“Can we give organizers a single, reliable event page that travels well across the internet and gives attendees instant clarity?”
Research
We treated research as the foundation. Over four years we interviewed student organizations, club leaders, founders, frequent hosts, students who attended everything, and students who missed everything. Three findings shaped the product.
First, discovery was a behavior problem, not an information problem. Announcements existed. They just lived in too many incompatible channels.
Second, the first screen decided everything. Attendees made a yes or no call in seconds. If the event didn’t explain itself immediately, it was gone.
Third, organizers were carrying the real workload. Post, share, track, follow up, learn, repeat. Early EventSpase was strong for attendees and thin for organizers. That gap became the story of the next three years.
Footage I shot for our Design Anthropology class
Three Phases
Four years, three phases, two pivots.
Phase 1, MVP and the Brown pilot (2018–2019)
I learned React Native in the summer of 2018 and built the first version to a simple standard. Create an event fast, share it fast, view it instantly. We piloted with Summer@Brown, where roughly 1,900 students used the app to find and track events on campus. The attendee flow held. People understood events faster than they could parse a poster screenshot. The build was buggy though, and the organizer flow didn’t hold. Creating an event was easy. Managing one wasn’t. We spent the following fall and spring rebuilding the platform with FSIcon at Brown.
Phase 2, social feeds and B-Lab (2019–2020)
We entered Brown’s B-Lab summer accelerator in 2020 and tried a broader social direction with feeds and a "collections" feature for saving events into themed lists. Without dense event supply, collecting felt empty. We cut it. The pandemic also evaporated our entire product surface, since in-person events were gone, so we spent that summer doing what we should have done earlier. Talking to people. That’s when I realized I’d been designing for the attendee because I was one. The organizer, who carried the actual workload, had almost nothing to come back to.
Phase 3, the creator beta (2020–2022)
During the pandemic I watched who actually cared about their event page. Creative people, especially musicians, for whom tools are identity. Their platform choice was a brand decision. We relaunched a beta aimed at musicians and nightlife hosts in South Africa, with a look and feel built for repeat hosting. About 300 users joined. It worked better than anything we’d shipped. Hosts kept making events. But "better" wasn’t enough to bridge the gap between great for one event and I use this every week, because we hadn’t built the things that would have closed that gap.
Experimental promo I animated in Keynote
Final Design
Four principles guided the final iteration. Information is clear. Fewer screens, fewer clicks. Complexity shows up only when needed. It should feel fun.
The event view
Every event surfaced the same four essentials on the first screen. Title, location, time, host. A visible guest list became the fifth. People rarely said they cared about who else was going, but a familiar name consistently tipped them from "maybe" to "yes."
Cover images, used sparingly
In the feed, the cover image was the attention anchor. It told you instantly whether you were looking at a DJ set, an art show, or a talk. Inside the event detail view, we pulled it back. Organizers often uploaded Canva posters with tiny text that conflicted with the actual event details in the app, so we let the structured data lead.
Progressive complexity
Creating an event felt closer to posting a tweet than filling out a form. We pre-filled date, time, and visibility so casual hosts could drop an event in seconds. Power controls like location detail, guest-list rules, and duration lived on secondary screens for the hosts who went looking.
Visual language
Iteration 2 was minimal and Notion-adjacent. White background, Inter, list-first structure, quiet transitions. The idea was to get out of the way. The final iteration went the other direction. Dark UI, softer corners, SF Pro Rounded, livelier haptics, more personality in loading states. Dark mode alone signaled a different product. Social, nightlife-adjacent, a little more discreet. It matched the creative segment who pick their tools the way they pick their typeface.
What I deliberately deferred
Ticketing, QR check-in, organizer insights dashboards, richer analytics, co-hosting workflows. All scoped, none shipped. I was the only frontend developer, and this predated AI-assisted coding. Ticketing in particular would have closed the loop between RSVP yes and actually showed up, but the lift was beyond what I could deliver alone. I scoped it out and shipped what I could ship well. That call was right for the timeline. It was wrong for the product, since the things I deferred were the things that would have made it compound.
What Worked, What Didn’t
What worked. The structured event page outperformed a poster screenshot every time. The four-question hierarchy of what, where, when, and who held across every event type we tested. Sub-minute event creation was the feature that kept hosts around. The dark, creator-focused redesign in Phase 3 outperformed everything before it.
What didn’t. We never proved repeat organizer use, because we hadn’t built the toolkit to earn it. RSVP funnel visibility, follow-up messaging, ticketing, check-in. That gap, between great for one event and I use this every week, is where the product stopped compounding.
What This Project Taught Me
Design for the person doing the hardest work. The attendee browses. The organizer carries the load. A product like this compounds on the organizer’s side or it doesn’t compound at all. I spent two years designing for attendees because I was one. By the time I corrected for it, I’d already shipped a product the wrong way around.
"Students" is not a segment. "Social events" is not a segment. It took me until year three to narrow to creative people running repeat events who cared that their tools reflected their identity. That specificity should have come first, not last. I now treat the audience definition as a Phase 1 design problem, not a marketing problem to figure out after launch.
Think in lifecycles, not screens. What happens after someone’s first successful event matters more than what their first event page looks like. I built screens for years before I built a workflow.
Scope discipline cuts both ways. The features I deferred weren’t deferred because they didn’t matter. They were deferred because I was one developer. The lesson wasn’t ship less. It was if the things you’re cutting are the things that make the product compound, you’re working on the wrong product.
EventSpase gave me reps I couldn’t have gotten any other way. Research, interaction design, visual systems, React Native production code, investor pitches, a B-Lab summer, a pilot, a pivot, another pivot, a shutdown. That’s the experience that lets me walk into a 0→1 problem now without flinching at the ambiguity, because I’ve already lived in ambiguity for four years.