1M users, VC backing, and the deliberate choice to have no paywall

The Numbers

• Total downloads: ~790K
• Daily downloads: ~1,500
• Monthly active users: ~1M at peak
• Onboarding screens: 6
• Paywall: none
• Subscription revenue: $0
• Investors: Thrive Capital, Dylan Field (Figma CEO), Scribble Ventures, Box Group, Imaginary Ventures, Conviction, Coalition, Copper, Positive Sum
• Founding team: Nathan Sharp (ex-Meta/Instagram 6+ years), Ryan Olson (ex-Instagram)
• App Store accolades: #1 photo app in 12 countries, #1 overall app in 6 countries including Germany and Sweden, Apple 2025 Cultural Impact Award finalist

Why This Teardown Is Different

Every other app in this series optimizes the same thing: getting each install to generate revenue. The 43 Flo screens, the BitePal raccoon, the Liftoff paywall loop, the Prayer Lock signature -- all of it is infrastructure for one goal: convert the user you already paid to acquire.

Retro optimizes for something else entirely: making each user bring more users. The 6 screens are not a conversion flow. They are a growth loop with an account creation wrapper. There is no paywall to close because the metric that matters to Thrive Capital is not revenue per user. It is network nodes and daily active growth.

This is not criticism. It is a description of a completely different game. Understanding that game -- what it looks like, why it works when it works, and why it fails when it fails -- is the most useful thing a revenue-focused founder can take from studying Retro.

The Full Retro Onboarding Breakdown

Phone verification on screen 1: identity before anything

Retro opens with a phone number verification. Not an email. Not a social login. A phone number and a one-time passcode.

This is the most friction-heavy opening in the entire series. Every other app tries to remove barriers on screen one. Retro installs one. The phone verification is not a UX oversight. It is a data quality decision: phone-verified accounts are real people, not bots, not duplicate accounts. For a social network where the core feature is seeing photos from friends you actually know, identity quality matters more than conversion rate.

The trade-off is explicit and accepted. Some users will bounce at the verification screen. The ones who clear it are the ones who wanted the app enough to go through the friction. That is Retro's target user: someone with enough intent to submit their phone number before they have seen a single screen of the product.

Stacked permissions: contacts, camera, notifications

After phone verification, Retro asks for three permissions in rapid succession. Contacts. Camera. Notifications.

This is the most aggressive permission stack in the series. Most apps time permission requests to demonstrated value -- Flo asks for notifications after the personalization summary, Cal AI after 30 screens of investment. Retro asks for everything upfront, before the user has experienced anything.

The reason is structural. Contacts access is the entire growth engine. Without it, the friend-finding feature -- the mechanism that drives every new user to invite others -- does not function. Camera access is the core product feature. Notifications are retention. All three are foundational, not peripheral, which is why they are requested before anything else.

The risk is real. Users who have not yet experienced the product and do not understand why you need their contacts will deny the permission. Retro accepts this risk because the alternative -- a contacts-permission ask after a long personalization flow -- produces lower-quality contacts data from users who are fatigued by the time they reach it. They would rather have genuine consent from a smaller group than coerced consent from a larger one.

Personalization: for their metrics, not your experience

Retro asks a few personalization questions during onboarding. These are minimal compared to anything else in this series. And critically, they do not produce a meaningfully different app experience for the user.

This is the tell. Every other app in this series uses personalization questions to build something the user will recognize and value: a projected weight loss curve, a ranked gym persona, a dream recall graph with their name on it. The personalization produces a visible output that justifies the questions.

Retro's questions produce user segmentation data for internal analytics. They are not for your benefit. They are for the product team's understanding of who their users are. That is legitimate and valuable for a VC-backed product optimizing for growth. It is just worth naming clearly: when personalization does not produce a visible personalized output, it is market research, not onboarding design.

Must add one friend: virality as a gate

Before Retro's core features are accessible, the user must add at least one friend. This is the most structurally aggressive virality mechanic in the series.

Most apps request referrals mid-onboarding or post-paywall. Retro makes a friend connection a prerequisite for activation. You cannot use the app until the network grows by at least one node.

The logic is defensible from a product perspective: a photo-sharing app with no friends to share with is genuinely useless. The onboarding could make this gate optional ("add friends now or later"), but making it mandatory ensures that every activated user is already connected to at least one other user -- which means the network is denser, the retention is stronger, and the churn from "I have no friends on here" is lower.

From a viral growth perspective, the mandatory-friend gate is the best single decision in Retro's onboarding. Every new user generates at least one invitation before they can access the product. At 1,500 downloads per day, that is a minimum floor on daily invitations sent.

The cost: users who have no friends to add yet -- who heard about the app but cannot think of anyone to invite immediately -- cannot activate. They bounce before they have experienced anything. That bounce is accepted as the price of network density.

Premium design: ex-Instagram, it shows

Retro is built by people who spent years at Instagram. The design reflects that.

Every screen is clean, intentional, and considered. Typography is precise. Animations are restrained and smooth. The overall aesthetic is closer to a consumer hardware product than a mobile app. Imaginary Ventures, one of Retro's investors, specifically focuses on design-led consumer companies -- which means the design bar is a funding prerequisite, not an accident.

This matters for one reason in this teardown: great design is a conversion lever in apps that have a paywall, and a trust signal in apps that do not. For Retro, which asks for phone verification and three permissions before showing any value, the design is the primary reason users proceed. An ugly app asking for your phone number and contacts looks like a scam. A beautiful app asking for the same things looks like a serious product made by serious people.

Design does conversion work even when there is nothing to convert to.

Post-onboarding: share, rate, invite -- before you have done anything

Immediately after completing onboarding and adding a friend, Retro presents a sequence of sharing and social prompts. Share the app. Rate it on the App Store. Invite more friends.

This is the most unusual placement of social proof mechanics in the series. Every other app that asks for reviews mid-onboarding does so at a moment of emotional peak -- after the first prayer, after naming the raccoon, after the projection graph. The emotional state is manufactured, specific, and high.

Retro asks for a review immediately after onboarding, before the user has done anything with the product. They have added one friend. They have not shared a single photo. They have not seen a single photo from a friend. They are being asked to rate an experience they have not had yet.

The bet is that the brand enthusiasm of early adopters -- the user who specifically sought out a private photo-sharing app that looks like it was made by people who used to work on Instagram -- is high enough at the moment of sign-up to produce positive reviews without any product experience backing them.

For the first wave of users, this works. The enthusiast who downloads a new app from ex-Instagram founders backed by Thrive Capital is predisposed to give five stars before they have opened a single shared album. Their review is a bet on the team and the concept, not an evaluation of the product.

For subsequent users who find the app organically, those early enthusiast reviews do the trust work. The review mechanics and the friend-invite prompts are both generating the same thing: network growth. Reviews attract downloads. Invites create connections. Both happen before the user has experienced the core product loop.

The VC Playbook vs. The Revenue Playbook

This is the core lesson from Retro for revenue-focused founders, and it is worth stating plainly.

Retro is not poorly designed. It is optimally designed for the game it is playing. The game is: grow the network fast enough that the network itself becomes valuable, then monetize later or exit.

This game has worked. Instagram played it. WhatsApp played it. BeReal played it until it did not. The playbook is real and has produced enormous outcomes. But it has three requirements that most founders cannot meet.

The three requirements most founders cannot meet

• Venture funding to survive without revenue. Retro raised from Thrive Capital, Imaginary Ventures, Dylan Field, and others. That is not a seed round from friends. It is an institutional bet that the team and concept are worth funding through a potentially long pre-revenue phase. Without that runway, the no-paywall strategy is not a growth strategy. It is a death strategy.
• Network effects that are genuinely structural. Retro's core feature -- seeing photos from friends -- literally does not work without a network. The mandatory-friend gate is defensible because the product is genuinely worthless to one person. Most apps are not like this. A calorie tracker with no friends is still a calorie tracker. A mood journal with no friends is still a mood journal. If your product works for one person, the network-effects justification for no paywall is weaker.
• A credible monetization path that investors believe in. The exit thesis for Retro is not "we will sell subscriptions." It is "we will build a network that is acquired, or we will eventually introduce advertising or premium features at scale." Both require the network to first exist and be sticky. Without investor belief in the sequence, there is no funding for the first phase.

Why revenue founders cannot run this playbook

For the founder reading this who does not have Thrive Capital on their cap table: Retro's onboarding is a study case in a playbook you cannot afford to run. The permission stacks, the mandatory friend gate, the review asks before product experience -- all of it is optimized for a metric (daily active users, network density) that requires a VC to fund the time between now and when that metric becomes money.

The revenue playbook this entire series documents -- paywalls, commitment devices, personalization investment, spin wheels, hold gestures -- is the alternative. It converts today's install into today's revenue, without a network-effects story, without a VC bet, and without the risk that BeReal proved: that a network built on a clever constraint can collapse just as fast as it grew.

What Retro Gets Right (That Revenue Apps Should Steal)

Despite being a different game, three things in Retro's onboarding are worth studying regardless of your monetization model.

• Phone verification as a quality filter. If your app's core experience depends on real identity -- community features, social proof, user-generated content -- consider what your current sign-up method does to account quality. Email is easy to fake. Phone numbers are not. The friction is real. So is the quality difference.
• The mandatory-friend gate as an activation mechanic. Most apps let users activate alone and then wonder why retention is low. If your product is genuinely better with social context -- accountability partners, shared goals, competitive leaderboards -- consider making one social connection a prerequisite for activation, not an optional nudge. Liftoff's referral ask mid-onboarding approaches this. Retro makes it a gate. The gate is stronger.
• Premium design as a trust mechanism for high-friction asks. Retro asks for your phone number and three permissions before showing anything. It gets away with it because the design signals credibility. If your onboarding asks for anything sensitive -- phone, contacts, camera, location -- before value is demonstrated, the design quality of those screens does real conversion work. A permission ask in a beautiful interface reads as serious. The same ask in a mediocre interface reads as suspicious.

The BeReal Lesson

BeReal hit 73 million daily active users at its peak in 2022. No paywall. VC funded. Genuinely novel mechanic. The whole world talked about it.

In 2024, it sold to Voodoo for $500M. Not the outcome investors hoped for when they funded a potential social network at consumer-internet scale.

Retro's team is better. Ex-Instagram, not first-time founders. The product is more considered. The design is more serious. The investor roster is stronger. But the category is the same: friends-only, constraint-based, anti-algorithmic photo sharing. The question that BeReal answered is: what happens when the novelty fades and the constraint becomes friction?

Retro's answer is features: journals, Rewind, collaborative albums. Each one adds stickiness on top of the core mechanic. Each one is a bet that the network, once built, has enough genuine utility to retain without the novelty.

For the founders in this series building with paywalls, spin wheels, and commitment screens: you do not have this problem. Your user pays because the product solves something specific. Their retention is not dependent on whether their friends also use it. Your churn is not correlated to BeReal's churn. That is the quiet advantage of the revenue playbook. It is slower. It is less dramatic. It does not end up as #1 overall app in six countries in a week. But it also does not depend on a network to exist, a VC to fund the wait, or a news cycle to sustain the growth.

The Takeaway

Every other teardown in this series documents how to stop the leak after the install. Retro is studying a different question entirely: how to turn each install into ten more installs. That works with VC funding, network effects, and time. Without all three, the bucket is just open at the bottom.

If you want to know where your own app leaks revenue after the install -- ranked by dollar impact -- tasu.ai maps exactly that.