The Data
- 30% of new users churn within 90 days
- Solo users retain at 22% at 90 days
- Users who invite a collaborator retain at 68% at 90 days
- Current Day-3 invite rate: 12%
- The invite step was positioned late in the original onboarding flow
B2B · SaaS · Prototype · Onboarding · PLG · Vibe Coding
Built a B2B SaaS onboarding prototype from scratch — hypothesis first, prototype second, analytics built in.
PM & Builder — Hypothesis, Prototype, Onboarding Design, PM Analytics Dashboard
Product
Stacks
Type
B2B Project Management SaaS
Problem
30% user churn within first 90 days
Intervention
Reposition team invite to screens 1-4 of onboarding
Goal
Increase Day-3 invite rate from 12% to 25%
The brief
Stacks is a B2B project management SaaS bleeding users. Thirty percent of new signups churn within the first 90 days — a rate that compounds fast and makes sustainable growth nearly impossible to achieve.
The data pointed to a clear culprit. Users who invite at least one collaborator are three times more likely to still be on the platform at 90 days — 68% retention versus 22% for solo users. The invite behavior was the single strongest predictor of long-term retention in the product.
The problem: the invite step was buried. Most users never reached it before they churned.
The intervention: move the team invite option to the first 3 to 4 screens of the onboarding flow and build a clickable prototype to test whether earlier exposure to the invite moment increases the Day-3 invite rate.
The hypothesis
"We believe that moving the team invite step to screens 1 through 4 of the onboarding flow will increase the Day-3 invite rate from 12% to 25% — because users who are prompted to invite a collaborator earlier in their setup experience are more likely to complete the action before losing momentum.
We will know this is true when the Day-3 invite rate reaches 25% or higher among users who go through the new onboarding flow.
We believe this matters because users who invite at least one collaborator retain at 3x the rate of solo users at 90 days (68% vs. 22%)."
The retention problem
The retention gap between solo users and team users is not a product quality problem — it is an onboarding sequencing problem. The invite behavior that predicts retention was being asked of users too late, after many had already disengaged.
The fix is not a new feature. It is a repositioning of an existing one — earlier in the flow, before momentum is lost.
The onboarding flow
Screen 1
Entry point. Single CTA: "Create your workspace." Establishes product identity: a tool built for teams who ship.
Screen 2
Name your workspace. Two-column layout with form on the left and product illustration on the right. Step 1 of 5 progress indicator.
Screen 3
"How are you planning to use Stacks?" Three options: With my team, Solo for now, Not sure yet. Branching logic: "Solo for now" advances through the flow but the invite screen is still shown as an optional step — because solo users who later invite a collaborator still benefit from the retention effect.
Screen 4
Repositioned from late in the flow to Screen 4 — the core intervention being tested. Email invite field plus a lower-friction "Share a link to your board" option, added after identifying that email-only invites created drop-off when invitees had to create their own accounts. Subtext: "Stacks works best as a team. The people who get the most out of it invite a colleague within the first 3 days."
Screen 5
"Teams that create a task on day one are 2x more likely to stay organized." Simple task input with a skip option. Establishes the core product habit after the invite moment — not before it.
The design decision
In the original flow, the invite step appeared after workspace setup, role context, and first task creation. By the time users reached it, many had already lost momentum or closed the tab.
The prototype moves the invite step to Screen 4 — before first task creation — so the social commitment happens while the user is still actively engaged in setup.
Early testing of the invite screen revealed a secondary friction point: email-only invites required the invitee to sign up, create an account, and join the workspace before they could collaborate. Many gave up before completing it, meaning the invite was sent but the collaboration never happened.
Solution: added a "Share a link to your board" option as a parallel lower-friction path. This removes the barrier to collaboration without removing the invite mechanic — and protects the integrity of the retention signal being measured.
PM analytics dashboard
The primary metric being tested. Measures the percentage of new users who invite at least one collaborator within 72 hours of signup. Baseline: 12%. Target: 25%.
The lagging indicator that validates the hypothesis. Tracks whether moving the invite step earlier converts more solo users into team users — and whether those team users retain at the expected 68% rate.
Distinguishes between invites sent and invites accepted. Tracks whether the lower-friction "share a link" option increases the rate at which invited collaborators actually join the workspace.
What I learned
The most important shift in thinking on Stacks was separating the retention problem from the feature problem. The invite mechanic already existed. The data already showed it worked. The only question was whether users were reaching it at the right moment — and they weren't. Sometimes the best product intervention is a sequencing change, not a new build.
Designing the branching logic for solo users was the most nuanced decision in the flow. The instinct was to skip the invite screen for anyone who selected "Solo for now" — but that would have removed the intervention for a segment that could still benefit from it. Keeping the invite screen as an optional step for solo users protects the measurement environment and leaves the retention pathway open.
Building the prototype in Lovable using AI-assisted development compressed the time from hypothesis to testable artifact dramatically. That speed matters in product work — not because moving fast is inherently good, but because a working prototype surfaces friction and edge cases that a PRD never will. The link sharing friction point only became visible once the flow was clickable.