SaaS & Product

Dropbox paid $1,000 for every new sign-up during their Series A. It worked. They hit 4M users in 18 months. But that was 2010, and unit economics looked different. Today, a SaaS burning $15K/month on referral payouts for a 1.2% viral coefficient is underwater. The math has shifted. What works now is the double-sided reward: both the referrer and the referred customer get money (or credit). When your customer tells a friend "I'm on Aidxn, I just got $25 credit and you will too," the friend's first reaction isn't "cool" — it's "wait, we both get paid?" That flip in incentive alignment is the hidden engine of modern viral growth. Dropbox's 2010 one-sided model could work because growth marketing was immature. Today, your competitors have referral programs too. If everyone's offering one-sided rewards, you lose. If you're offering double-sided, you win. Let's walk the failure modes of one-sided programs, why double-sided works, the exact Supabase schema to track referrals, how to build the share-to-team feature that scales to multiple users, and the math of viral coefficient so you can predict how many new customers this will bring.

Why One-Sided Referral Programs Die

Incentive misalignment kills virality

A typical referral program: "Refer a friend, get $50 credit if they sign up and pay." Your customer thinks: "I'll get $50 if my friend gives this company $100 of their money. That's an ask." It feels transactional. The referred friend thinks: "Why should I trust a company based on my friend's recommendation? And I get nothing out of it?" Misalignment. Your customer doesn't evangelize because they're asking their friend to do them a favor (switch tools, learn a new product, spend time onboarding). Your friend doesn't convert because they have no upside. The reward is tilted entirely toward the referrer, which makes it feel like a pyramid scheme, not a good deal. Psychologically, when you ask a friend to help you make money, they help hesitantly. When you ask a friend to both help you make money AND make money themselves, they help enthusiastically. That's the power of symmetry.

One-sided programs get a 0.8–1.2% viral coefficient

Viral coefficient = (% of users who refer) × (# of people each referrer brings). For a one-sided program, that's typically (3–5% of users make a referral) × (0.25–0.4 referrals that convert per active referrer). You get 0.75–2% viral coefficient if you're generous with tracking and payouts. That means: if 100 customers sign up, only 1–2 of them will bring in new customers through referrals. The rest of your growth has to come from marketing, sales, or organic search. Compare this to Dropbox (which hit 3–4× viral coefficient with one-sided payouts in 2010), and you're an order of magnitude behind. Why? Dropbox was the only player with that offer at the time. Today, Stripe, Supabase, Slack, and Figma all have referral programs. If you're the only one offering one-sided rewards, you lose share-of-voice to competitors who offer better deals.

Referrers have to close the sale (you don't help)

Your customer sends a referral link to a friend. The friend clicks it. Lands on your sign-up page. Now what? Your referral program shows "Someone invited you to try Aidxn — both of us get $25 credit if you sign up." But your sign-up page doesn't say anything about what makes you different from the competitor the friend was already considering. The referred friend has to learn your value prop, understand the pricing, convince their boss it's worth switching tools, and onboard by themselves. Your customer can't close the sale on your behalf — they're just the link. This is why referral conversion rates are so low (typically 3–8%, vs. 15–25% for free trial users). You're asking a friend to do all the work of understanding and adopting a new tool, with zero help from the product team, the sales team, or the referrer. One-sided programs don't have the juice to overcome that friction.

No network effect — each referral is isolated

Your customer refers one friend. Friend signs up. That's it. No network multiplier. If your customer refers 5 people, that's 5 separate referrals with no connection to each other. But what if your customer's friends know each other? What if they work on the same team? Suddenly, you have a network. But one-sided programs don't leverage this. They treat each referral as an atomic event. Double-sided programs that enable team sharing (share a link to your whole team, everyone gets credit) turn referrals into network effects. One person brings in three friends, those three friends bring in their team, and suddenly you've got 10 people on the account who all came in via referrals. The network compounds. That's the lever one-sided programs miss.

How Double-Sided Rewards Work (And Why Dropbox Did It, Too)

The symmetry principle

Dropbox's referral program: "You both get 250MB of free storage (worth ~$24 at the time) if your friend signs up." Both sides got the same reward. Psychologically, this is powerful because it removes the quid-pro-quo feeling. Your customer isn't "asking for a favor" — they're "sharing a deal that's good for both of us." The referred friend isn't "being sold to" — they're "getting a perk for trying something my friend trusts." The symmetry makes it feel like collaboration, not extraction. You can apply this to SaaS: instead of "refer a friend, get $50 credit," it's "refer a friend, you both get $25 credit." The cost to acquire is the same ($50), but the psychology is completely different. Your customer feels like they're being generous (letting their friend in on a good deal). The friend feels like they're getting a gift. Both feel like winners.

Double-sided programs hit 2.5–3.5× viral coefficient

When you incentivize both the referrer and the referred, you change two variables: (1) more of your existing customers will refer (6–12% vs. 3–5%), and (2) referred friends convert at higher rates (12–18% vs. 3–8%). The math: (9% of users refer) × (0.25 conversions per referrer) = 2.25% minimum viral coefficient. Reality is higher because referred customers often bring their friends too, creating a second wave. Aidxn clients who've implemented double-sided programs see 2.5–3.5× viral coefficient within 3 months. For a SaaS with 10K users and 30% monthly growth from marketing, adding a 2.5× viral coefficient program means 25% of new users come from referrals — that's an instant 8 percentage point boost to growth without increasing ad spend.

It signals quality and confidence

When a company gives the referred customer $25 in credit, it signals: "We're confident you'll like us enough to stick around." It's a form of social proof. The company is putting money behind the relationship. Contrast that with one-sided programs, which signal: "We want your friend to buy, and our customer should convince them." Slightly different vibe. When a referred customer sees "You get $25 credit," they start with goodwill toward the product. They're more likely to land on your pricing page, click around, and experiment. That small goodwill often converts into a trial, and trials convert into customers. The $25 is a gateway drug that works.

The Share-to-Team Flow (Where the Real Growth Happens)

One-to-one referrals are weak. One-to-many is powerful.

Individual referrals: "I'll text my friend and send them a link." Conversion rate: 8–12%. Your customer has to manually hunt down people to refer, which is friction. Team referrals: "Here's a link to share with my entire team. We all get $25 each if they sign up." Conversion rate: 30–45% (because your customer is pre-endorsing you to their team, and teams move together). The difference is network gravity. When your customer can say "our team is switching to Aidxn next sprint" and everyone on that team gets a perk, adoption is exponential. One person becomes five. That one person's manager sees the tool, and the manager brings their peer manager in. Suddenly you've gone from one customer to ten. Share-to-team is the hidden engine of B2B growth. Slack's growth exploded when they built the "invite your workspace" feature. Figma's adoption skyrocketed when teams could collaborate on a single document. You need the same thing for referrals: make it trivial for one person to invite their entire team and unlock credits for all of them.

How to build share-to-team (without friction)

When a referrer lands on their referral dashboard, they see a button: "Share this referral link with your team." They click it. Modal pops up with options: (1) copy the link, (2) send via email, (3) share a team invite code. If they pick "team invite code," they get a short code (like `LAUNCH2026ABC`) that they can paste in Slack, their project management tool, or email. Anyone on their team who uses that code on sign-up gets the referral credit automatically. The referred users also get credit. Build that flow, and your referral coefficient doubles because one person can bring in their entire team instead of just one friend. You're not building two products — you're just building the referral dashboard smart enough to handle multiple referrals from one link.

Time decay and expiration

A referral link should work forever (if someone joins, they joined via your customer's link and deserve credit). But a team invite code should expire after 30 days. Why? Because team compositions change. If your customer invites their team in March, and a new hire joins in June, that new hire shouldn't automatically be attributed to the original referrer. They might not even know them. Set expiration at sign-up time, not at send-time, to avoid confusion. A referred customer has 30 days from when they receive the link to sign up. After 30 days, the link is inactive (but you show them what they'd get if they join within the window).

The Supabase Schema That Tracks Everything

Here's a production-grade schema for referral tracking. Three tables: users, referral_campaigns, and referral_conversions.

users table (simplified)

You probably have this already. For referrals, add three columns:

`referral_code` (text, unique) — the short code each user can give out. Generate on sign-up: `USER_[TIMESTAMP]_[RANDOM]` or a short UUID like `ahk3j9d`.
`referred_by` (uuid, foreign key) — the user_id of whoever brought them in. NULL if organic or paid acquisition.
`referral_credit_balance` (numeric) — running balance of credits earned from successful referrals and received on sign-up. Starts at 0, increments when they refer someone, receives credits, or uses them.

referral_campaigns table

Tracks each referral offer and its rules:

`id` (uuid, primary key)
`name` (text) — "Q2 2026 Referral Push"
`referrer_credit` (numeric) — $25 in credits or discount
`referred_credit` (numeric) — $25 in credits for the new user
`active` (boolean) — is this campaign running?
`expires_at` (timestamp) — when does the campaign end?
`min_months_to_reward` (integer) — how many months does the referred customer need to stay before the referrer gets paid? (e.g., 1 month minimum prevents gaming)
`created_at` (timestamp)

referral_conversions table

The core table: one row per successful referral.

`id` (uuid, primary key)
`campaign_id` (uuid, foreign key to referral_campaigns) — which campaign did this use?
`referrer_id` (uuid, foreign key to users) — who made the referral?
`referred_id` (uuid, foreign key to users) — who was referred?
`referral_code_used` (text) — the code they entered
`status` (enum: 'pending', 'earned', 'expired') — pending = referred customer just signed up but hasn't met minimum tenure, earned = both sides get credit, expired = referred customer churned before minimum tenure
`referred_at` (timestamp) — when did the referred customer sign up?
`earned_at` (timestamp) — when did the referrer's credit unlock? (usually 1 month after referred_at)
`credit_applied_at` (timestamp) — when was the credit actually added to both users' accounts?
`referrer_credited` (boolean) — has the referrer received their credit?
`referred_credited` (boolean) — has the referred customer received their credit?
`notes` (text) — admin notes if something went wrong

Queries you'll run constantly:

Viral coefficient: `SELECT COUNT(DISTINCT referred_id) / COUNT(DISTINCT referrer_id) FROM referral_conversions WHERE status = 'earned' AND referred_at > NOW() - INTERVAL '30 days'`
Referrer leaderboard: `SELECT referrer_id, COUNT(*) as referrals_earned FROM referral_conversions WHERE status = 'earned' GROUP BY referrer_id ORDER BY referrals_earned DESC`
Conversion rate: `SELECT COUNT(*) FILTER (WHERE status = 'earned') / COUNT(*) as conversion_rate FROM referral_conversions WHERE referred_at > NOW() - INTERVAL '30 days'`

Build a dashboard on top of this and share it with your customer success team. They use it to find power advocates (customers with 3+ successful referrals) and partner with them for larger team expansion plays.

The Viral Coefficient Math (Predicting Growth)

The formula

Viral coefficient = (% of active users who refer per month) × (average # of conversions per referrer).
Example: (10% of users refer) × (0.3 people who convert per referrer) = 0.3 viral coefficient.
If you start a month with 1,000 paying customers and a 0.3 viral coefficient, you'll end the month with roughly 1,300 customers (1,000 × 1.3). Sustainable growth kicks in around 0.4 viral coefficient. Explosive growth starts at 1.0. Exponential flywheel territory is 1.5+.

How double-sided programs change the numbers

One-sided program: 5% of users refer, 0.2 conversions per referrer = 0.01 (basically nothing).
Better one-sided program: 6% of users refer, 0.25 conversions per referrer = 0.015.
Double-sided program: 10% of users refer, 0.3 conversions per referrer = 0.03.
Double-sided with team sharing: 10% of users refer (same), but 0.5 conversions per referrer (team multiplier) = 0.05.
That 0.05 coefficient compounds month-over-month. Over a year, it's a 79% boost to growth from a single channel that cost you $25 per referral instead of $50.

The breakeven point

You want viral coefficient ≥ 0.3 before you're comfortable paying out referral credits at scale. Below 0.3, you're not getting sustainable leverage. At 0.3, you're adding 30% of your monthly customer base from referrals. At 0.5+, referrals are becoming your primary growth channel (which is good because CAC is lower than paid advertising). Aim to hit 0.5 within your first 6 months. If you're below 0.3 at 3 months, you need to iterate: is your offer not compelling? Is the share-to-team flow missing? Are you not promoting the program? Dig into your data and fix it.

Six FAQs on Double-Sided Referral Programs

How much should I pay ($25, $50, $100)?

Standard rule: pay out 5–15% of your average customer LTV. If your average customer is worth $3,000 (lifetime value), pay $150–$450 per successful referral (split equally, so $75–$225 each side). If your average customer is $500 LTV, pay $25–$75 (so $12.50–$37.50 each side). The amount has to be high enough to motivate behavior, but low enough that your CAC (cost to acquire) is still better than paid advertising. Double-sided typically has 30–50% lower CAC than paid ads because the referred customer is pre-sold by your existing customer. So even if you pay $50 total (vs. $15 for a Facebook ad), your CAC is probably better because conversion and retention are higher.

Should I pay in cash, credits, or discount?

Credits are safest. They lock the customer into your ecosystem. A customer gets $25 credit for signing up, and they're more likely to stay and use it than if you gave them a $25 discount at the start. Cash payouts (Stripe transfers) work but are expensive and create tax complications. Discounts work too — "$25 off your first three months" — but are less sticky. Ideally, offer credits, but allow conversion to discount if the customer hasn't signed up for billing yet. "Claim your $25 credit now, or apply it as a discount on your first invoice" gives optionality.

What's the minimum tenure before I pay out referral credits?

1–3 months. You want to make sure the referred customer is actually sticking around. If someone signs up, gets $25 credit, and churns after 2 weeks, you've paid $50 to acquire a customer who's already gone. Set a minimum tenure (usually 1 month) and check at that milestone. If the referred customer is still active, pay out both sides. If they've churned, mark it as 'expired' and don't pay the referrer. This teaches your customers to refer actual matches, not just anyone. They'll be more careful about who they bring in because they know they only get paid if that person sticks around.

How do I prevent fraud (fake referrals)?

Fraud is rare in B2B SaaS referrals because most customers are known to each other or part of the same organization. But to prevent it: (1) require an email address at sign-up and validate it's real, (2) check if the referrer and referred user share a company domain (e.g., both @acme.com) — if they do, flag it for review, (3) set a limit on how many referrals one person can make per month (e.g., max 10), (4) manually audit the top 10 referrers every month to make sure they're legit. Most fraud is caught by common sense. If someone has 50 referrals in a month and the referred users are all sign-ups from new email addresses (not established domains), it's probably fraud.

Should I limit who can refer (e.g., only paying customers)?

Yes. Only paying customers who have been active for 30+ days can make referrals that earn credits. Why? (1) Free trial users have no skin in the game and will refer anyone, increasing fraud risk, (2) churned customers might refer people out of spite. Limit it to active paying customers with 30+ day tenure. This also increases the quality of referrals because your best customers are referring — people who've made the decision to pay and commit.

What if a referred customer is my competitor checking me out?

They still get the credit if they sign up and meet the minimum tenure. You can't police intent. But you can monitor: if you see a referral from a customer to someone at a competitor you know, and the referred user is doing suspicious things (exporting data, taking screenshots, churning immediately), flag it. You can manually claw back the credit if it's clear they weren't a legitimate user. This is rare, though. Most of the time, referrals are genuine.

The Bottom Line

A one-sided referral program gets you a 0.8–1.2× viral coefficient. A double-sided program with team sharing gets you 2.5–3.5×. The difference between these two is the difference between referrals being a tactic and referrals being a growth engine. Dropbox understood this in 2010. Stripe, Figma, and Slack have built it today. If you're a SaaS with 100+ customers and no referral program, you're leaving 20–30% of potential growth on the table. If you have a one-sided program, you're leaving 50%+ on the table. The fix takes 2 weeks to build and costs $25–$50 per referral, which is still better than $100+ CAC from paid advertising. This is where Aidxn helps SaaS teams scale referrals — we audit your current program (if you have one), model the viral coefficient based on your customer base, design and build the share-to-team flow, set up the Supabase schema, and run the first 90-day growth cycle. Clients see 2–3 point jumps in viral coefficient and 15–25% of new monthly customers from referrals within 6 months. If you're ready to turn your best customers into your distribution channel, read more about our retention infrastructure — retaining customers is step one; referrals are step two. Do both and growth becomes compounding.