Meet people through what you love doing.
A social app that replaces swiping with shared activities.
The Problem
In the Bay Area's fast-moving, work-heavy culture, making a real friend — or meeting someone worth getting to know — has quietly become one of the hardest things to do. People move for jobs and leave just as fast, and long hours leave little energy for socializing. Even meetup groups often fizzle after one exchange of numbers. Making things harder, most social apps are built around one narrow goal — a swipe, a match, a transaction — leaving little room to actually get to know someone or grow a real circle of friends. Dating apps front-load pressure into a decision before two people know anything real about each other, and event apps stop at discovery — they help you find something to do, but do nothing to help you connect with anyone once you're there.
From insight to positioning
Marshmallow's answer starts by flipping that order: instead of evaluating a profile first, you share an experience first — the event is the introduction, and connection is simply what happens afterward. That idea came from a simple observation: the strongest real-world connections rarely start with "let's evaluate each other" — they start with "let's do something together." A hiking trip, a dinner, a game night. Attraction and rapport are byproducts of shared experience, not preconditions for it.
That insight reframed the product question. Instead of asking "how do we make matching better?"
the real question became:
"What if the event itself was the matching mechanism — and the relationship, dating or friendship, was simply what happened afterward?"
That's the positioning behind Marshmallow's core model:
Event-driven Social. The event isn't a feature bolted onto a dating app — it is the app. Chat, connection, and dating all flow downstream of something real that already happened.
Design Principles
To keep every downstream decision consistent with that positioning, three working principles became the filter every feature had to pass through:
1. Interest before appearance — people connect through what they do,
not a photo.
2. Trust is earned through shared experience — deeper access unlocks after something real happens, not before.
3. Low-pressure by default — every interaction should feel lighter than the equivalent on a traditional app.
Any feature that couldn't trace back to one of these didn't make the MVP.
Visual Direction — Design as an Argument
The visual language isn't a style choice sitting on top of the product — it's an extension of the same three principles.
The name "Marshmallow" was always meant to signal something inclusive, diverse, and full of energy — not just "soft." The visual language leans into that second half: bold, saturated color-blocking rather than a muted palette, so the app feels alive rather than sleepy.
.png)
From Principle to Feature
-
Discover (MVP) — an interest-first feed, not a swipe deck. MVP recommendations are simple and rule-based; full AI personalization ("Vibe Match") ships in Phase 2.
-
Connect (MVP core · AI safety layer in Phase 2) — verified profiles, with full chat unlocking only after a shared event. Fake-profile detection and event-based icebreakers arrive with Phase 2's safety AI.
-
Create (MVP core · AI concierge in Phase 3) — anyone can host in minutes. MVP hosts write their own listings; the AI concierge that drafts titles, timing, and venue suggestions doesn't ship until Phase 3.
-
Reunite (Phase 2) — a home for people you've already met, with AI suggestions for who's worth reconnecting with. This is the one that traces back to the founding vision — Marshmallow was always meant to be a place for old friends, not just new ones — rather than to the three principles above.
MVP Priorities — What Came First, and Why Revenue Waited
The MVP had one job: prove that unlocking chat only after a shared event produces better, higher-trust conversations than unlocking it upfront. Everything else got cut until that was proven.
-
Built: event creation & discovery, RSVP, basic verified profiles, post-event chat unlock, simple recommendations.
-
Cut for now: AI matchmaking, the Reunion Hub, paid tiers, ticketing, gamification.
Monetization wasn't a priority, for a simple reason: charging users before they trust the product breaks the exact thing the product is trying to prove.
Trust had to come first — revenue could wait. Once that trust mechanism holds, the plan is straightforward: a free core, a paid tier for power users, a small cut of paid events, and
brand-sponsored experiences — added in that order, not all at once. To keep that sequencing defensible without breaking it, willingness to pay still gets tested early without charging — a Marshmallow+ waitlist, or a soft paywall on one feature — so there's a revenue signal before there's revenue.
Roadmap — Building in Sequence, Not in Parallel
Phase 1 — Prove the core loop. Assumption being tested: people will attend interest-based events through the app, and the post-event chat unlock will produce real conversations. Scope: creation, discovery, RSVP, verification, chat unlock, basic recommendations. Launched in 1–2 pilot cities.
Phase 2 — Deepen, once the loop holds. Only pursued after Phase 1 validates engagement: full AI-powered matchmaking, the Reunion Hub, safety/moderation AI, and the first monetization layer (subscriptions + ticketing commission).
Phase 3 — Scale the ecosystem. Only pursued once monetization and retention hold: AI Event Concierge, a branded-event marketplace, gamification, B2B tools, and multi-city/international expansion.
Each phase is a gate, not a milestone — the product doesn't move forward until the assumption behind it is confirmed.
Final Design Highlights
Sign In & Onboarding
Passwordless phone login with auto-filled OTP codes removes the biggest drop-off point for new users. Inline validation keeps errors friendly and recoverable, while a playful loading beat sustains momentum. First-time setup flows straight into profile creation — photos, basics, interests — and lands on a personalized Great Picks feed, so the app feels alive from the very first session.
Create Event
A single-page guided form replaces a maze of screens: photos, title, time, location, and description with live character counts. Hosts tag up to three interests, toggle private mode, and cap participants with a stepper — all with smart defaults. A celebratory success state with one-tap sharing turns publishing into a small moment of joy.
Manage Participants (Host)
Publish an event in under two minutes
A single-page guided form replaces a maze of screens: photos, title, time, location, and description with live character counts. Hosts tag up to three interests, toggle private mode, and cap participants with a stepper — all with smart defaults. A celebratory success state with one-tap sharing turns publishing into a small moment of joy.
Profile & Hobby Journey
A profile that grows with you
Beyond name and photo: MBTI, zodiac, and interest tags build a vivid first impression in seconds. The Hobby Journey timeline turns milestones — learning guitar, trying yoga — into a visual story, with an empty state that invites rather than intimidates. A shareable journey card lets proud moments travel beyond the app.
Early Signal
Early validation comes from three sources: discovery interviews, moderated prototype testing, and a 4-week closed beta in 2 pilot cities (n = 300 testers).
From install to habit (activation funnel)
Of every 100 testers who installed the beta, 68 completed onboarding — clearing our 60% target. 42 went on to RSVP to at least one event in their first week, showing the core loop works end to end. Retention settles at 38% on day 7 and 21% on day 30: early for a social product, but a promising base to build on.
Events actually happened (event health)
Supply met demand: 73% of published events reached minimum capacity. After events, 61% of unlocked chats turned into real conversations (5+ messages), supporting the thesis that shared experiences beat cold openers. The no-show rate held at 18% — below the 25% informal benchmark, though still our top watch item.
Why people bounce off existing apps (discovery interviews, n = 24)
The top complaint about current meetup apps was flaky RSVPs (17 of 24), followed by the pressure of sending the first message (15) and strangers who never show up (13). Marshmallow's design answers each directly: commitment-light event joining, chat that unlocks only after a shared event, and host-controlled guest lists.
Supply depends on a few power hosts
(host concentration)
Just 10% of hosts created 44% of all beta events. It's a classic marketplace cold-start pattern — and the reason the Reflections section proposes one-click AI event drafting: lowering the authoring barrier is the fastest way to turn casual attendees into confident hosts.
Reflection
The friction I kept seeing
During prototype testing, publishing an event took a median of 3m 42s — under our 5-minute target, but the qualitative sessions told a different story. Hosts consistently stalled on the same two fields: title and description. "I know what I want to do, I just don't know how to say it," one tester said, staring at the blank description box for nearly a minute. The form wasn't hard — it was blank-page hard. And in the beta, the supply problem made it urgent: the top 10% of hosts created 44% of all events. The barrier wasn't motivation; it was the first keystroke.
The idea: describe it once, AI drafts the rest
Instead of asking hosts to fill six fields, let them describe the event the way they'd text a friend — "candlelight R&B concert, Friday night, somewhere in Manhattan, small group" — and have AI draft the full listing in one click: a catchy title, a warm description in Marshmallow's tone, a sensible time window, 2–3 venue suggestions with addresses, and a recommended group size based on the activity type. Every field stays editable; nothing publishes without the host's tap.
Why one click, not a chatbot
I considered a conversational concierge, but testing showed hosts want speed, not conversation. A single "Draft with AI" button next to the title field keeps the existing form intact — AI accelerates it rather than replacing it. Hosts who love writing keep full control; hosts who dread it get a 90%-there draft to react to instead of a blank box. Reacting is cognitively cheaper than creating, and that difference is the whole point.
Designing for trust, not magic
Three principles guide the design: (1) Transparency — drafted fields are subtly badged as AI-suggested until the host edits them, so there's never ambiguity about authorship. (2) Brand tone guardrails — drafts are tuned to Marshmallow's warm, low-pressure voice; no clickbait, no "🔥🔥 DON'T MISS OUT 🔥🔥".
An event titled by AI should still sound like it was written by a friend. (3) Local grounding — venue and time suggestions must be real and checkable. A hallucinated address would destroy host trust faster than any blank form ever could, so suggestions are constrained to verified venue data with a "pick another" fallback.
What I'd measure
Success isn't "AI usage rate" — it's host supply: % of first-time hosts who publish within 24h of signup, and whether the host concentration curve flattens (fewer than 44% of events from the top 10%). Secondary: edit rate per drafted field — if hosts rewrite the description every time, the tone model needs work; if they accept titles but rewrite venues, the grounding needs work.
The open question I'm still sitting with
There's a tension I haven't fully resolved: Marshmallow's brand promise is authenticity — real people, real gatherings. Does AI-drafted copy dilute that? My current answer is that authenticity lives in the event itself — real people showing up — not in whether the description was drafted or typed. The host still chooses, edits, and shows up. AI removes the typing friction; it doesn't attend the hike. But I'd want to test that assumption explicitly: do guests rate AI-assisted listings as any less "genuine"? That's the study I'd run next.