How might we find a way to identify and manage attending events in NYC?

Situation

There are many ways to see event listings in New York City – including websites, newsletters, and Instagram feeds – but no one solution to aggregate them all into an easy-to-use interface.

Task

I analyzed the current challenges in identifying, registering, and managing events as an event attendee, and created a product to address the challenges using Lovable, an AI prototyping tool. I did this as part of the Lovable Shipped 6 week product incubator online in Summer of 2025.

Action

I created several deliverables during the project, including:

• Project Management: I set up the infrastructure to analyze, design, and develop the application, including setting up Jira and Linear to track features, bugs, and tech debt
• Research: I researched and identified the challenges and possible features to address them
• Product management: I identified a series of features as part of a product roadmap and how to pull in existing event websites into the new application, including a Go To Market strategy and Launch page to capture interest
• Design: I worked within Lovable and used prompt engineering to deliver the UI design of the application
• Development: I worked within Lovable and Supabase to address issues in development, such as authentication and security
• Etc.: I also created a 2-minute pitch video, including scripting, recording, identifying video b-roll, editing, and adding sound and visual effects, teaching myself Kdenlive in a few hours, and making the video in about 24 hours

Results

In Detail

Situation

One of the most important lessons from lockdown is that people love to connect and spend time with one another in real life. New York City is amazing for that. There are so many events, communities, and people to meet. However, there are numerous events scattered across so many places, and keeping track of them isn’t easy. How might we simplify identifying, tracking, and attending events?

---

Analysis

I, like many New Yorkers, subscribe to numerous newsletters and explore the city. I found myself dealing with events scattered so many sites:

• Applications:Web sites: Eventbrite, Luma, Eventbrite, Meetup, Partiful, Posh and more
• Mobile apps: Locals and other apps which are less popular
• Newsletters: the bane of my existence!
• Social media: Instagram in particular has lots of accounts for events, as well as Facebook and LinkedIn

Events pose a data wrangling challenge, but I also saw this as an opportunity to understand the strengths and limitations of Lovable as an AI-driven prototyping tool and possibly a partner in app development.  

I came across the Lovable Shipped site. Shipped is a 6-week global bootcamp for product development, and submitted a video application for my idea. I had started exploring Lovable before it, and I saw the Shipped community as a way to get the supportive community I desired to launch something as well as learn Lovable.  We were able to collaborate on Circle, and there were weekly calls with domain experts tied to the schedule, which was powerful.

Shipped had the following schedule:

• Week 1: Idea generation and Validation 
• Week 2: Design and Development
• Week 3: Testing and Iteration
• Week 4: Marketing Preparation
• Week 5: Final Polishing
• Week 6: Launch Preparation
• Week 7: Launch

Determining scope

In light of the short schedule, I was curious how quickly you can set up an AI-driven prototype of an application that feels realistic enough on the front end to understand product-market fit for testing the most valuable features, and what an MVP built with Lovable might look like? Can the prototype also handle any of the backend requirements? I started by looking at events to understand my goals and settled on three major areas to think through the scope for MVP:

• Visual design: Should I add icons, photos, and logos to create a comprehensive application experience, or a simple listing site that’s easy to skim? A brief competitive analysis could be helpful, as sites like Luma balance visual design and the skimmability of basic event information. For MVP, I wanted to focus on the simple listing of events and add extra UI details at post-MVP.

Hypotheses for the MVP

I also thought of a few hypotheses I wanted to explore:

• UI design: AI will likely augment my workflow around the UI design – rather than using Figma, Lovable will be able to create basic UI designs for an MVP.  I chose Lovable because it seemed to have an active community and recently acquired funding.
• Backend: Lovable will be able to handle enough of the backend work that a developer would typically do, such as security, or point me to resources to address these areas.
• Roadmap: Since I’m the end user of this product, focusing on solving my pain points is more beneficial for the MVP than focusing on product-market fit, scalability, or pricing.  Regardless of how many features I’ll build out, I do at least want to have an MVP to help me while also learning Lovable.

Goals

• Learn how to use Lovable
• Learn how to build an app to make managing my calendar easier
• Learn how to tackle product management, UX design, and research without burning out when you’re doing all three roles on a team of one
• Learn more about the Web development work that developers are usually doing

---

Solution 

As with any project, it starts with the basics of project management – staying organized is a key to being able to build quickly and carefully.

Project Management

• I set up my Parking Lot Google Sheet with tabs I, as a product designer, product manager, and project manager, would need:
  • Categories: Do the events belong to a category, and is categorizing them useful?
  • Events: the name and URL of the event with status (added to app, categorized, validated, etc.)
  • Roadmap: pains and gains and approach for features
  • Tasks: mostly some of the tweaks I would then bundle into a group of prompts

I would migrate the bugs onto Linear, which helped manage the complexity significantly. While having a roadmap on Mural and Jira made sense as I built this out, I did like having everything in one spreadsheet to start, an idea I had perfected in the InfoSec project previously.

Research

• User research:
  • I keep this lightweight and focused on pain points with the existing systems and processes, and how a proposed application might address them. I also spoke with others to understand how they perceive events through interviews and surveys. The Lovable community site ultimately became a source of numerous comments on the idea, which was encouraging to see. The research results of my Pains and Gains are presented in the Product Roadmap table below; research was transformed into user stories, which were then prioritized as MVP or post-MVP. I also captured all feedback into a Google spreadsheet and hope to import it into Aha! or other software. 

• Competitive analysis
  • Features: I conducted some preliminary research to get started and found a great discussion on what might be needed to build the application (https://www.reddit.com/r/AI_Agents/comments/1is0ap6/eventsnews_aggregator_app_idea/).  I wanted to explore how much of this could be duplicated within Lovable and its existing tools first, and worry less about what existing products might be available since my goal is to learn Lovable.
  • Branding: I created a light Mood board to understand what competitors do in this space and what skimmability looks like in terms of visual design – what are the standards to use when potentially integrating events to balance engagement with skimmability.

• Product Management:
  • Docs: I created a simple PRD using the same template I used from Civic Hall Labs, and focused on basic user stories for MVP.  I then assessed what was in and out of scope during the Product Roadmap portion. I didn’t add much detail for Acceptance Criteria so that I could focus on quickly building out a prototype rather than finishing a production-ready application.
  • I used the product roadmap spreadsheet template I created during an InfoSec project to stay organized. I eventually migrated onto a Kanban board once my scope was a bit more solid, and fell in love with a minimal Jira setup.

• Design via prompt engineering
  • I had chosen Lovable because of discussions in my GenAI learning circle, and I felt it was a solid choice to learn, as it appears to be one of the market leaders in this space (according to this video and others doing a market scan). I also didn’t want to design first in Figma and import into Lovable, as I tried to approximate how product managers might use the software as well. I also wanted to understand what kind of design patterns were built into Lovable rather than relying on a reference picture or an import from Figma.
• Branding:
  • Naming: The idea of naming this application ‘Dancecard’ originated from my knowledge of the term’s history, as well as a subtle nod to my love of dance music. This part came very early on, which felt great to experience.
  • Visual design: Google’s Skitch was key for exploring the visual design and determining if dark mode would work for the skimmability factor.  I tried branding as I went, building iteratively and focusing on a simple color scheme while developing the features.  

Features

The UI

The home page is fairly simple and corporate-feeling, but for MVP for the Lovable contest it was good.

I was able to create an interface that allowed me to quickly add event listings to the site.

Event listings

The event listings were simple – I debated the value of having a category. I will likely play around with more of the information design in the next version to fit into the brand experience of Luma. On this page, users can go directly to the event listing site, save them to a Google calendar, or save them to a short list. The ‘share with friends’ link is on its way to implementation, but I have also run into a series of bugs that are affecting the time display, which I will need to resolve.

Pitch video

I also created a pitch video in about 12 hours. This included writing a pitch script, recording it, sourcing b-roll footage and music, editing the video using KDenLive (an open-source film editor similar to Premiere), and adding captions.

Landing page for waitlist

I also created a wait list to gather interest for the idea, especially since people in the Lovable community mentioned they wanted to sign up:

---

Results

I now have an MVP that can be expanded, and can start to think through some of the limitations and opportunities with AI prototyping – and eventually launch something to share with friends.  While I have some technical challenges to address, I also have a roadmap of features to build out. Most importantly, I met the four goals I set out to achieve, and I have findings from each, which I have added in the Reflections section. I ended up about #649 out of 3900+ entries, ranked because of both meeting my weekly deliverables but also gaining points for assisting others.

---

Reflection

I had findings for all of my goals:

• Learn how to use Lovable – I became far more comfortable and understood the pros and cons of AI prototyping, how to prompt, and the value of Lovable.
• Learn how to build an app to make identifying events easier. Although I’m still far from a formal launch, the building part makes me excited to see something that won’t require clicking on 30+ email newsletters a week.
• Learn how to balance product management, UX design, and research when you’re doing all three – this is something I struggled with and is worth exploring as I move forward, as it was demanding when done by one person. It was also interesting to see how I was quickly able to pivot week to week in the work.
• Learn more about Web development work, including the tasks that developers might undertake, such as security. I learned a lot here and have infinite respect for the challenges devs have with this work.

I like

• You can quickly launch something to test and validate an idea.
  • As a designer, I am used to thinking through the flow of screens and how content is organized on a page. With this process as a product manager, I was able to try out a few things and think through the product roadmap in real-time, prioritizing what was essential as I realized how technically challenging something might be or how a simple design change could have a larger impact than I initially thought. Having a multitude of design patterns built into the LLM made a lot of this easier to grasp, and the first version created was often sufficient to validate the product-market fit.
  • The ‘all-in-one’ factor of full-stack building was beneficial. Lovable would prompt me when I needed to refactor code to improve it, and tasks like security scanning via Supabase (the accompanying database that integrates with Lovable) were fantastic. It meant that, while this isn’t a replacement for a developer, having those full-scale development tasks to consider was hugely valuable.  The goal around ‘learn more about developers might be thinking of’ was met here.
  • The Lovable team also encouraged us to provide weekly updates on one of the microsites, which was a great practice. I started noting what I built across planning, research, design, and development, and it formed the basis of a change log.  It also helped me consciously reflect on what was buildable within the product timeline, and to check in if things were still a priority.  I strongly recommend creating these weekly Weeknotes across these categories. It also meant working on this case study and focusing on documenting my learnings in this format was easier to do.

• That designing with community is amazing.
  • There were about 4,000 of us building, and while some folks skirted the system by including non-Lovable products in the contest, which already had paying members, it was still fantastic to have a community to go to and support one another on the Circle app.  We were encouraged and received points when we helped each other out and provided feedback on each other’s products.  At the most challenging moments, it was terrific to see enthusiasm for an idea, receive actionable feedback, and provide support for others.  It made me reflect that on teams, it’s essential to not only discuss the challenges but celebrate the wins. We also had guest speakers every week and seeing three female entrepreneurs sharing their story was an honor and a higlight.

I wish 

• Getting things working wasn’t such a challenge.
  • The hallucinations were a challenge – Lovable would say “Applied dark theme colors to cards, tables, and text elements”, and I found out that didn’t happen.  I would try to be as accurate in my prompts, mentioning which code to change and how (“move this box 200 pixels to the right’) or provide the hexadecimal color to change, but the changes weren’t performed. I would edit the HTML and CSS directly in the edit code mode, but the changes wouldn’t save. I found that even after I added an event feed, I would have to manually check on the original page to see if it was displaying events – and it wasn’t. I started to not only get frustrated, but also trust the application less. I’m hoping setting up agents in Toolhouse could help me check the health of a feed – I started building an agent but was unable to get it working.  There were also challenges with Circle as a community platform and that the site to submit updates often didn’t work.

• Credits are a huge issue – as is performance. If you write complicated prompts, you’ll have to clean up a lot of the work; if you write the prompts and they work well, you’ll blow through them quickly. It’s not just a case of prompt engineering needing to improve. There were multiple areas in Lovable (such as the code editor) that did not save changes, and it became a concern about how much time I was spending implementing straightforward UI changes or debugging technical challenges. The visual design is not as polished as I would have liked. I hope to resolve the technical difficulties with feeds displaying and then refresh the UI.

• Data integrity issue is still a challenge.  I have imported feeds that aren’t displaying the correct day or time, and I need to build out some quality control variables – so that if an event is older than 7 days, it knows to remove it. I’m hoping adding a few other workflow pieces to verify the content will help.

• Balance: Balancing product management, UX design, and research when you’re doing all three remains very hard.  There’s some debate on how much of a PRD you need to have done ahead of time – using ChatPRD was something I came across about halfway into development. I also tried to build out what I thought was a small scope for MVP, only to find out I could build out the features because both the UI design and tech challenges prevented me from getting that MVP built out to my satisfaction. I think figuring out this delicate balance is hopefully something to explore in the future for me.

I wonder

• How the future of the product will evolve
  • While I have a few priorities right now for my career, I feel like finding someone to help finish the app might be the right decision. Having technical help is going to allow me to build the remaining features and think about if I want to launch this or keep this within my own domain for personal use.
  • Can N8 create a workflow to fetch the feeds and use Lovable to display them? Including AI agents and workflows is the next step in my work.

Photo of crowd courtesy Josh Sorenson