85 signups, 8 active groups: the activation gap nobody warned me about
Two weeks ago I launched yallacome — one app to plan your friend group's games/rides/outings AND split the cost (think WhatsApp planning + Splitwise, combined): https://yallacome.app
The twist: I'm not a developer. I made the product decisions and AI wrote the vast majority of the code. Honestly, shipping a real, working app as a non-dev is no longer the hard part. Here's what actually is.
The first two weeks, in real numbers:
• ~85 signups (mostly from me blasting my own WhatsApp groups)
• ~28 groups created, 51 people joined a group they didn't start
• BUT only 8 "active" groups (posted an event + got RSVPs in 30 days)
• Week-1 retention: ~21%
So: acquisition was the easy part. Getting people to actually use it — and come back — is the wall. Classic activation gap, and it's humbling to watch a healthy-looking signup graph hide the fact that most people poked it once and left.
What I'm trying now:
• A first-run onboarding checklist (create group → add friends → post event → split a cost)
• One-time lifecycle nudge emails ("you made a group but haven't added anyone yet")
• Made every event link a one-tap join + auto-RSVP, so shared invites convert with almost no friction
I'll report back on whether any of it moves that 21%.
Question for the room: for a social/utility app, what actually moved your retention needle early on — onboarding changes, lifecycle emails, or something else entirely? I'd rather learn from your scars than earn my own.
21% week-1 retention on something two weeks old isn't actually bad, the real signal is 28 groups forming but only 8 staying active, so people are trying it together but something happens right after the group gets made. Is the drop-off happening at the invite step, or once people are in and don't know what to log first? Onboarding checklists usually help more with the second one than the first.
This is a genuinely useful reframe — thank you. You're right that it's (2), not (1).
The invite step is actually holding up better than I feared: 51 people have joined a group they didn't create, and 13 of the 28 groups have 3+ members. So people do get in.
The drop-off is right after the group exists — it sits there with 3–4 people and nobody posts the first event or logs the first expense. Classic empty-room problem: everyone's waiting for someone else to go first.
So your instinct is spot on (and weirdly encouraging) — onboarding help lands exactly where my leak is. What I've shipped this week:
• a "create group → add friends → post event → split a cost" checklist on the home screen
• lifecycle nudges ("your group has no events yet")
• made every event link a one-tap join + auto-RSVP, so a shared invite drops people straight onto a real action instead of an empty group
The one I'm still stuck on is the intra-group cold start — a group of 4 where nobody wants to be first. Have you seen anything that reliably triggers that first action? I'm debating whether "create a group" should force you to post the first event in the same flow, so a group is never born empty.
That's a genuinely hard one, an empty group is basically dead on arrival even if the invite worked perfectly. Forcing the first event into the same flow as creating the group seems worth trying, removes the "wait for someone else to go first" moment entirely since there's no group without an event yet. Might be worth testing whether it's the creator posting first that unlocks the rest, versus everyone individually deciding to be the one who goes first.
The honest diagnosis: for a group-coordination app, your retention problem isn't onboarding or emails, it's cold-start-per-group. Splitwise/WhatsApp-hybrid apps live or die on whether the whole group shows up, not the individual. One person creates a group, but if the other 4 friends don't engage, that group is dead no matter how good your onboarding checklist is. 28 groups created, 8 active means the drop-off isn't the creator, it's everyone they invited.
So the retention lever isn't the first-run experience for the person who signed up. It's whether their friends have any reason to open the app at all. And here's the trap: for the invitee, you compete with the group chat that already works. They can already plan and roughly split in WhatsApp. Your one-tap auto-RSVP is the right instinct because it's the only move that gets an invitee to act without downloading or committing. Lean harder there: the invitee should get value before they ever "join," ideally without leaving the link.
The scar most social-utility apps share: retention comes from the network being present, not from nudging the individual. Lifecycle emails to a solo creator whose friends ignored the invite just remind them it's empty. The email that moves the needle isn't "add friends," it's getting the added friends to show up once.
That "which lever actually matters" question is what I spend my time on, I'm part of the team building Hivemind, an AI strategy copilot. Happy to go deeper on the activation model if useful. Short version: fix the invitee's first 30 seconds, not the creator's onboarding. The group is the unit of retention, not the user.
What % of invited (non-creator) people ever post or RSVP? That number, not signups, is your real health metric.
This is a useful breakdown. I like that you're not treating signups as success by itself.
I'm starting to think the real question is not "did people create an account?" but "did they reach the first moment where the product actually becomes part of their behavior?"
For your case, do you know where most groups dropped off? Was it before inviting friends, before posting an event, or after the first event?
What stood out to me is that you're measuring activation instead of celebrating signups.
The harder question isn't why people installed the app. It's what has to happen before the group feels like it would lose something by leaving. Until that moment exists, onboarding tweaks can only go so far.
Really like this framing — "would the group lose something if it left?" is a much sharper bar than "did they take an action," and you're right that checklists alone don't clear it.
For yallacome, I think the thing that creates that "we'd lose something" feeling is accumulated state: a live who-owes-who ledger plus the shared history of events and photos. Once a group has real unsettled balances and a few outings on the record, leaving means abandoning that ledger and going back to the WhatsApp + Splitwise juggle — that's the switching cost.
The catch my data shows: most groups stall before they ever get there. They form, never log the first expense, so no state accumulates and there's nothing to lose yet. So I've started thinking of it as two gates:
Checklists only help with gate 1, which is exactly your point. Gate 2 is the product's job, and I suspect I need to make that accumulated value felt earlier — e.g. surfacing "you've split AED X across 3 outings, here's your running balance" so the group can see what they'd be walking away from.
Curious how you'd approach accelerating gate 2 — is it about making the accrued value visible sooner, or genuinely adding stickier state?
That's a great question.
My instinct is that the more important choice isn't between making the value visible sooner or creating stickier state.
There's another assumption sitting underneath those two options that will probably determine which one actually works. I don't think I can explain the reasoning properly in a thread without oversimplifying it.
If you're open to it, what's the best email to reach you on?