Party Action People

Product: Party Action People
Timeline: 2023 to 2026
Project Type: Company website and the admin platform behind every summit site
Stack: Next.js, TypeScript, Convex, Convex Auth, Tailwind CSS, Slack API, ScreenshotOne, Typeform

Project Overview

Party Action People runs a family of summits on stablecoins, finance and crypto, among them Stable Summit, Vault Summit, Stablecoin Summit and Capital Summit.

I built the company website in 2023 and looked after it for the next three years. In 2026 I built something bigger: one admin platform where the team manages the speakers, sponsors and agenda of every summit website, and approves each change before it goes live.

The Company Website

• Built with Next.js and Tailwind CSS
• Every summit shown with its logo and a link to its own site
• Forms embedded from Typeform, and videos that open in a modal
• Kept up to date from 2023 to 2026: schedules, venues, logos, content and a legal documents panel

The Admin Platform

Before this, a new speaker photo, sponsor logo or agenda change meant a code change on a summit site. I built a platform so the team could do it all themselves, for every site, in one place.

Content for every site

• One dashboard for every summit website, each with its own speakers, sponsors and agenda
• Speakers pulled from SessionBoard and sessions from agenda feeds with a Sync button, and the counts of what changed shown straight back
• Speaker photos cropped in the browser
• Speakers and sponsors put in order with drag and drop
• Sponsor logo sizes tuned with sliders, so every logo looks balanced on the page

Approvals in Slack

• New and changed items wait as pending until someone approves them
• The preview site shows pending items, the live site never does
• Every new item is posted to Slack with a screenshot of how it looks on a phone, plus Approve and Reject buttons
• If a Slack message ever fails to go out, a scheduled sweep sends it again

History and digest

• A history of every change: who did it, on which site, and what changed
• A Slack summary of recent activity, on a schedule and at an hour the team picks, in their own time zone

Access

• The first person to sign up becomes the superadmin, and everyone after waits for approval
• The superadmin can approve, reject or revoke people, and reset a password, which also signs that person out everywhere

An API for the summit sites

• Each summit site reads its speakers, sponsors and agenda from the platform
• The live site gets approved content only, and the preview site also sees what is pending

Tech Stack

• Next.js and TypeScript: The dashboard and the public API
• Convex: Database, server functions, file storage and scheduled jobs
• Convex Auth: Sign in and roles
• Tailwind CSS: Styling
• Slack API: Approval messages, buttons and the activity summary
• ScreenshotOne: Phone screenshots of each new item for Slack
• Typeform: Forms on the company website

Key Technical Challenges

1. Live and preview from one database

The live sites and the preview sites read from the same data, but the preview must show unannounced speakers and the live site must never leak them. I gave each website two tokens. The live token ships in the browser, so it can only read approved content. The preview token can see pending items but can only read, never write. The two also live on different routes, so a cached live answer and a cached preview answer can never get mixed up.

2. Screenshots that show the real thing

The summit sites reveal their cards with a fade as you scroll, so the first screenshots caught each card halfway through and came out as a faint ghost. I force the card into its final state before the capture, crop to that exact card, and make the capture fail loudly if the card is missing, instead of quietly sending the wrong picture to Slack.

3. Changing the data without blanking the live sites

Adding approvals meant changing how every speaker, sponsor and session was stored, while the summit sites were live and reading from it. I did it in steps: first make the new fields optional, then move the data across, then tighten the rules again. During the move, anything without a status was treated as approved, so no live site went empty halfway through.

4. A sync that never surprises anyone

An overnight sync sounds helpful, but it could reset approvals or remove sessions while nobody was watching. So syncing only happens when someone presses the button, and it tells them exactly what it added, updated and removed.

Key Learnings

• Give the team a tool and they stop waiting on a developer
• Approval belongs where people already are, which for this team is Slack
• Security rules are safer when the code makes the wrong thing impossible, not just discouraged
• A history nobody can edit is the one people trust

Conclusion

I started with a simple company website and ended up building the platform every summit site runs on.

It taught me to think like the people who use a tool every day, and to design for the moment something goes wrong.