How a Find Venues rewrite drove a 150% increase in venue inquiries
PartySlate’s Find Venues page was the single most impactful page on the platform — the front door for couples searching for event spaces. But inquiry volume had plateaued despite steady traffic growth. The existing page was a static list with basic filters: slow to load, hard to browse, and missing the spatial context that venue search demands. Users were landing, scrolling, and leaving without converting.
The page also carried years of accumulated technical debt. The component was monolithic, tightly coupled to a legacy data-fetching layer, and nearly impossible to iterate on without risking regressions across the marketplace.
Rather than patch the existing implementation, I advocated for a full rewrite — scoped tightly to the venue page to limit blast radius while proving out patterns the team could adopt elsewhere.
The core insight was that venue search is inherently spatial. Couples don’t just want a list of venues — they want to understand where venues are relative to each other, to landmarks, to neighborhoods. I designed the new experience around an interactive map view paired with a redesigned search results panel, letting users toggle between map and list views while filters stay persistent.
I led the technical design and implementation end-to-end: component architecture, data layer, performance budget, and rollout plan. The team worked in two-week sprints, with feature-flagged releases so we could ship incrementally and measure impact at each stage.
The rewrite introduced a clean component hierarchy: SearchFilters feeds both MapView and ResultsList through shared state, with a GraphQL data layer replacing the legacy REST calls. The GraphQL schema was designed for this page’s specific query patterns — fetching venue cards with just the fields needed for list rendering, and a separate lighter query for map pins.
Shared filter state was lifted to a URL-synced context, so search state survives navigation and enables shareable links. The MapView component only loads when the user switches to map mode, keeping the default list view fast. Filter changes use optimistic UI — results update immediately with cached data while the network request resolves.
An image optimization pipeline with responsive srcsets and blur placeholders cut largest contentful paint significantly. Code splitting and tree-shaking of legacy dependencies brought the bundle size down 40%.
The rewrite shipped over six weeks and the numbers were immediate. Venue inquiries increased 150% within the first month, validating that the UX friction — not traffic — had been the bottleneck. Lighthouse accessibility climbed from 78 to 95 as we built WCAG 2.1 AA compliance into the component library rather than patching it after. Bundle size dropped 40% through code splitting and tree-shaking the legacy dependencies. Average page load time decreased by 2.3 seconds.
Beyond the metrics, the rewrite established patterns the team adopted across the platform: the shared-state filter architecture became the template for the vendor search and photo gallery pages, and the GraphQL data layer replaced REST calls over the following quarters.