PartyUp!.

Onboarding here isn't a form, it's a tour. Each slide introduces one of the app's real product moments (starting a party, the games deck, finding clubs nearby) instead of front-loading the user with sign-up fields. The bet: selling the value in the first thirty seconds removes more friction than optimising any individual input ever would.

Permission prompts are delayed until the slide that actually needs them. Location isn't requested on screen one, it's attached to the 'Find the best clubs near you' slide, so the ask lands paired with its benefit rather than floating out of context. Same pattern for notifications later in the tour.

Every frame was designed and built from scratch. No stock auth kit, no templated onboarding library, because the first screen is where the app's voice has to land hardest and a generic wizard undersells everything that comes after it.

Three tabs anchored at the bottom: tonight's party, the feed, the crew. Everything else is reachable from one of those three, and nothing is buried more than two levels deep. The layout was designed against a reachability map first, so every primary action sits inside a thumb's natural arc and the other hand stays free for a drink.

The visual system follows the context instead of the trend. Big type because bars are loud and attention is fragmented. Heavy contrast because screens get read through cigarette smoke and camera glare. A single neon accent (#c8ff00) that holds up on OLED at low brightness. Style wasn't the goal. Legibility at 1am was.

Venues aren't pins on a map, they're live. Each one has its own page that surfaces what's happening inside right now: a drink ranking for the night, a Party Moments feed of photos dropped by the people currently there, and the list of public parties you can join at that venue tonight.

Discovery runs on two layers. A map view for spatial browsing ('what's within a few blocks of here') and the venue pages for depth ('what's actually going on inside Madam's'). Treating the venue as a container for live activity rather than a marketing tile reframed the whole screen: venues compete on current energy, not on how good their hero shot looks.

The key product bet behind this model is that attaching parties to venues turns the app into something useful on both sides of the night. Organisers get a roster of who's coming. Attendees get a short list of places that are actually hosting something tonight, rather than a generic directory of bars.

Posts are parties that have already ended. Once a night closes, its room gets published as a public memory: a carousel of the best shots, the party title, and a comment thread open to anyone, not just the crew that was there. Every venue and organiser page is essentially a stack of these.

The call was to make the afterlife of a party worth as much as the night itself. A published post turns one Friday into permanent evidence of what a venue actually looks like on Friday, which sells the next edition more honestly than any marketing photo the club could commission.

At the moment of publishing, the selection and captions lock so nobody can retcon the night after the fact. Comments sit inline with the photo, captions stay short (time-capsule, not feed), and tap targets stay oversized because most of the commenting still happens at 1am on the walk home.

Games are the gravity of the app, the reason a group pulls out a phone in the first place. The interaction pattern is pass-the-phone: one device, one prompt, one person at a time, because coordinating five phones in a dark bar fails every time it was prototyped.

The engine runs entirely on-device. Wi-fi in most venues is either absent or unusable, so nothing in the gameplay loop depends on a round-trip to a server. Decks, timers, scoring and shuffle all run locally; only history syncs back up when connectivity returns.

Would You Rather, Never Have I Ever, Who Is Most Likely, dice, quick-fire challenges. Each deck was hand-written and typeset to read from two metres away, because that's the distance the phone actually ends up from the reader's face when it's being passed around a table.

The profile is a memory surface, not a bragging board. It holds the nights you've pinned, the crews you roll with, and the interests you use to find future parties. No stats, no streaks, no counters. The call was to keep the primary metric social (which nights, with whom) rather than quantitative (how many, how often), because counters change the reason people go out in the first place.

Pinning caps at five on purpose. A constraint, not a limit: scarcity forces curation, and a profile of five well-chosen nights reads more honestly than a grid of thirty. Tap targets and spacing are tuned for low-dexterity use, because the first time most people open this screen is the morning after.

The reveal is deliberate choreography. A plain 'YOU WON 2×1 DRINKS' modal gets ignored. A scratch-and-win card with a half-second pause, a haptic, and a spring read is enough to keep the group around the phone long enough for the reward to register collectively rather than individually, which is the real product goal.

The animation was tested against the target device floor, Android phones from 2019, because the crowd for this app skews young and budget. Written directly in React Native Reanimated instead of a prebuilt animation kit so every frame could be profiled. The whole sequence sustains 60fps on devices Expo's default renderers couldn't keep up with.

In a bar, sound is gone and vision is compromised, so motion has to carry the whole feedback channel. Every tap has a matched physical response, a scale, a translate or a haptic, because without it users re-tap, lose trust and drop out. This is the layer the rest of the app is built on, not a cosmetic pass at the end.

It all runs on a single custom interaction layer. Shared-element transitions for identity across screens, spring physics for naturalness, haptics sequenced to peak at the exact frame the motion settles. Hand-tuned rather than preset so the timings match the cadence of the app, a touch faster than iOS defaults because a party doesn't wait.

The marketing site is a product surface in its own right. Instead of a generic landing with three screenshots and a download button, it's structured around the two audiences that actually need to convert: partygoers who should download, and venues who should register to host.

Every section earns its place. The hero sells the promise ('All in one party app'), scrolling tiles walk through the core loop (start parties, photos & memories, play games), a 'Hot Clubs' strip borrows the venue ranking straight from the app, and a dedicated 'Do you own a club?' block breaks off into the venue self-serve flow. No stock landing-page kit, no fake customer-logo strip.

The visual system is the same one the app runs on (same dark palette, same neon accent, same big-type voice), so the site isn't a separate marketing artefact, it's the zero-install preview of what downloading actually gets you.