Why we launched a paid affiliate program before touching Google Ads

25% recurring is solid, and the "only pay on conversion" logic is right for pre-ads sequencing. On finding affiliates in practice, honest answer is I'm still early - reached out to existing customers first since they've actually used the product and can vouch credibly, and next step is inviting people who've engaged with my build-in-public posts (commenters, repliers, DMs) since they've already opted into caring about what I'm building. Deliberately skipping cold creator outreach because someone earlier in this thread mentioned getting a polite "not worth my time without a paid promo budget" response and it matches my instinct. One thing worth designing in from day one that I underweighted: payout speed matters more than commission rate for keeping affiliates promoting between wins - Net 30 lets the emotional freshness of the win fade before the check arrives. Happy to compare notes six months in.

The point about paid traffic making activation problems more expensive before you spot the leak is the part I want to underline, because it's the specific mechanism that catches most founders off guard. Ads don't just cost money, they cost signal clarity - once you're pouring cold traffic into a funnel, the noise floor rises to the point where you can't diagnose the leak anymore, because every bounce could be a targeting problem, a creative problem, a landing page problem, or a real product problem, and disentangling them takes months and more spend. Warm-first keeps the diagnostic signal legible long enough to see where the actual drop-off is happening.

Concrete example from this week: our activation blocker turned out to be a manual approval gate we'd added early on. Users signed up, hit a "pending approval" state, and bounced before we ever got to them. That fix ships in today's release - auto-approve on signup, straight into org naming, into the product. If I'd been running paid search for the last two months, the drop-off would've been buried under acquisition noise and I'd have been debugging ad creatives instead of a config gate. The diagnostic was only visible because the signup volume was small and mostly warm.

On the comparison question - this is exactly the experiment I want to run once activation is stable and we have enough affiliate volume to draw from. The specific hypothesis I want to test: does trust from the referral actually carry through the entire funnel, or does it only get people past the first friction and then converge with cold traffic at later stages. My gut says it carries through meaningfully at signup and activation, then partially decays by the time payment intent forms, because at that point the buyer is evaluating the product on its own merits rather than on the recommender's word. But I'd rather have the data than the gut.

The measurement plan is a four-stage funnel per source: click, signup, activated workspace, first paid invoice. Segmented by affiliate vs paid search vs organic vs direct. The interesting cell isn't the top of the funnel, it's the ratio of activated-workspace-to-paid-conversion by source - if warm traffic converts at 2-3x cold at that specific stage, the trust premium is real and channel spend allocation writes itself. If it converges to the same rate, the affiliate advantage is only at the top of the funnel and the calculus changes.

Happy to share the actual numbers once we have a defensible sample. Might make for a useful IH follow-up post whichever way it lands, because most of the "affiliate vs ads" content out there is either affiliate platform marketing or paid ads platform marketing, and neither has any incentive to publish an honest comparison.

This is the sharpest critique on the thread and it deserves a direct answer rather than a defense, because the underlying point is correct: warm referrals get more patience, not infinite patience, and burning a creator's credibility on a funnel you know is leaky is a debt you can't refund. That framing is right and I want to name it plainly instead of arguing around it.

The specific gap in what I posted: the org-creation blocker wasn't the popup itself, it was that we had a manual approval gate wrapped around it. Users signed up, hit a "pending approval" state, and bounced before we ever got to them. The popup was downstream of a queue that shouldn't have existed at all. That gate gets removed in today's release - auto-approve on signup, straight into naming the org, into the product from there. No queue, no waiting, no approval theater on the customer side. So the wall you correctly identified as the reason not to send affiliate traffic yet is coming down the same week the program launched, not next quarter.

Whether that timing was defensible is a fair separate question. Honest answer: I launched the affiliate page a few days before the activation fix because the two work streams weren't gated on each other, the affiliate page has near-zero cost if nobody uses it, and the people who might refer us next month are forming their opinion of the product this month. If the release ships as planned and I can point to a clean activation number by the end of the week, the sequencing works. If the release slips, your critique becomes retroactively correct and I'd have deserved it. I accepted that risk knowingly, but I want to be honest that it was a bet, not a plan that couldn't fail.

Your "no payout on free signups" callout is the one that actually matters most for program integrity long-term. The programs that get overrun by link farms almost all made the opposite call for short-term signup optics, and it takes a year to unwind. Grateful you flagged it as the right call rather than the obvious one, because in the moment it felt like leaving growth on the table.

The version of this reply I'd have written a year ago would have been more defensive. The version I'm writing now: you were right about the wall, the fix ships today, and if you want to check back in a week I'll post the before-and-after activation numbers in this thread so the claim is verifiable rather than just asserted.

This is the most actionable comment on the thread and I'm treating the whole list as a punchlist rather than commentary. Going point by point because each one lands differently.

Dev-centric promo assets is the one I've been thinking about as a nice-to-have and you're right to reframe it as table stakes. Marketing banners are useless to a dev creator - nobody's dropping a 728x90 into their newsletter. What actually gets used is code snippets they can paste directly into a post, a BuildBase-vs-custom-setup architecture comparison they can screenshot, and a copy-paste starter repo that a reader can clone and run in ten minutes. The starter repo in particular is a compounding asset because it turns the affiliate's post into a working demo, which is a different unit of proof than a written recommendation. Adding all three to the affiliate page as first-class deliverables, not buried under a "resources" tab.

Granular funnel transparency - you, plushwipes, and Andrewed independently converged on this and I'm taking it as the strongest signal on the thread. Current dashboard shows clicks and paid conversions, which is the industry default and also exactly the wrong incentive because affiliates optimize for whatever they can see. Rebuilding around the intermediate stages you listed: clicks, account created, activated workspace (past the org-creation step, which as of today's release is finally a clean signal because we removed the manual approval gate that was polluting the metric), first paid invoice. Aggregate only, no account-level customer data, so affiliates get diagnostic visibility without a privacy breach.

60-90 day cookie window is the correction I most needed to hear because I was defending 30 days on the reasoning that longer windows encourage attribution gaming, and you're right that the actual gaming risk is lower than the loss from cutting off legitimate long-lag conversions. Dev tools have exactly the evaluation pattern you described - someone bookmarks a post today, remembers it two months later when they start their next project, installs then. A 30-day window punishes the affiliate who did the education work. Moving to 60 days as the new default and keeping 90 in reserve if the data shows meaningful conversions past 60.

Multi-tier payout schemes I'd already ruled out but for weaker reasons than the ones you gave. Your framing - that they attract low-intent link aggregators - is the sharper version of what I was worrying about. Sticking with flat commission across the board.

Directory listings I was going to try because they seemed free, and your read that they yield near-zero developer conversions matches what I've heard elsewhere. Killing that from the pre-launch checklist. The time saved goes into producing the promo assets you flagged in point one, which is a much better use of the same hours.

Appreciate the "best of luck" but even more the concrete list. Comments like this compress about a year of trial-and-error for a founder who hasn't run this playbook before.

"Recruiting affiliates becomes its own product" is the specific failure mode I'm most wary of and I'm glad you named it that way, because it's easy to slip into without noticing. The version I've seen play out for other founders: three months in, the affiliate program has 40 partners, none of them are converting, and the founder is spending their week writing onboarding docs for creators instead of fixing the reason the referred traffic isn't converting. The program becomes a shadow product with its own roadmap and support burden, and the actual product's funnel is exactly where it was when the program launched. Explicitly guarding against that by keeping recruitment passive - the page exists, people who already recommend us can sign up, we're not doing outbound to creators.

The "find the ten who shipped and ask about their first hour" advice is what we're actually doing this month, and it's paying off. Real calls, not surveys, because surveys give you the answer people think you want to hear and calls give you the pause before they say the real thing. The org-creation friction came up in the first three calls without me prompting, which is why the fix ships today - auto-approve on signup, straight into org naming, into the product, no manual queue. The pattern in the calls was consistent: people who got past that first friction stayed and shipped, people who hit it bounced, and the difference between the two cohorts was almost entirely upstream of the product itself.

Your sequencing point is the one I want to internalize most: affiliates convert much better once there's a concrete story of someone going from install to production. Right now I have five of those stories internally (our own products), but external ones are what actually move a creator's audience. That's the actual gating condition for scaling the affiliate program, not commission structure or dashboard sophistication - do we have three or four external customers whose install-to-production story an affiliate can point at as social proof. Until then the program is more of a receipt for early supporters than a growth channel, and I should be honest with myself about that distinction.

The traffic-channel-vs-trust-channel distinction is the frame I was circling in the original post without naming cleanly, and it's the right one. A naked referral link is just paid acquisition with a smaller budget and worse targeting - the affiliate is functionally an ad network of one, and the economics have to compete with actual ad networks, which they can't. A creator who explains what they tried, who it worked for, and where it broke is supplying qualification before the click, which is a different unit of value and priced accordingly in what it converts to. The program should be designed around the second and passively tolerate the first, not the other way around.

On the dashboard, you and plushwipes independently arrived at the same conclusion, which I'm taking as strong signal. The default industry dashboard optimizes for clicks and free signups because those are the loudest numbers, and both are near-meaningless for a small-audience creator. What matters at our scale is the ratio of referred traffic that reaches activation and pays. Going to expose the funnel between attributed visit, activated workspace, and cashable customer as the primary view, with clicks pushed down as a diagnostic rather than a headline metric. Your point about denominator noise is the exact reason - one paid conversion out of a small cohort tells a genuine story, and a bulk of curious clicks tells a false one, and the dashboard shouldn't invert that.

On attribution after direct return - this is the piece I'm least happy with in our current setup and the honest gap in the program as it stands today. Cookie is 30-day last-click, so a buyer who reads a great post today and returns direct 45 days later gets attributed to no one, which is precisely the case where the affiliate did the hardest and most valuable part of the work. Extending the window to 60 or 90 days is the easy lever and I'm going to look at whether Endorsely supports it at the program level. Anything beyond that - first-touch attribution, multi-touch across a longer horizon, cross-device stitching - gets architecturally complicated fast when the buyer isn't logged in pre-signup and I don't have a stable identity to hang the trail on.

The compromise I'm settling on for now: extend the cookie to 60 days, plus a manual attribution override for cases where an affiliate can clearly demonstrate they were the source and the buyer confirms it. Not scalable and I know it, but it covers the "wrote a great post that converted someone six weeks later" case without pretending I can technically solve the long-tail attribution problem, which I don't think anyone actually has.

Twenty years of partner-channel scar tissue beats my "seems reasonable" gut on this one, and the mechanism you're describing is intuitive the moment you say it: the promotional cadence collapses between payouts because the win stops being emotionally live. Someone who just got paid for a referral is exactly the person most likely to write the next post, and stretching the gap between the referral and the reward drains the loop of the feedback signal that keeps affiliates promoting at all. That's not a commission problem, it's a reinforcement-timing problem, and I hadn't been thinking about it that way.

Current setup is Net 30 through PayPal Mass Payments, which is the default and, per your point, exactly the wrong default. It optimizes for our cash-flow comfort at the direct cost of the behavior we're paying to encourage. Going to look at what our processor supports for weekly or per-milestone payouts, and where PayPal can't cadence that way, whether Wise or Stripe Connect can. Even cutting to biweekly is a meaningful shortening of the reinforcement gap, and if the operational overhead is the only reason not to, that's a bad trade.

The lever-ordering point is the part I'll take away most concretely. I was about to spend cycles thinking about cookie length extensions, tier structures, and dashboard granularity, all of which matter less than getting the money into affiliates' hands while the win is still fresh. Fixing payout cadence first, then everything else. Appreciate you writing this out - the kind of comment that would've saved me a year of tweaking the wrong knobs.

This is the single most useful comment on the thread and I'm treating it as a spec, not feedback. The three-stage ledger is the right structural answer and I hadn't done any real thinking about the pending/approved/reversed split, which is exactly the kind of gap that turns into a dispute vector six months in when the first meaningful chargeback lands and the rules weren't explicit up front.

The specific points I'm going to build against:

Ledger stages match what I'm exposing to affiliates: attributed visit, activated workspace, cashable customer. Aggregate only between stages, no account-level customer data. Privacy boundary is non-negotiable and the aggregate view is enough for an affiliate to see where their funnel converts and where it drops, without leaking anything about the actual buyer.

Net revenue definition needs to be written down before any commission is calculated, not after. The current gap is that "net" is doing a lot of unspoken work - does it deduct Stripe fees, refunds within window, chargebacks, tax, or all of the above. Each of those is a defensible choice, but only if the definition is public and consistent. Going to publish the exact formula on the affiliate page.

Refund and chargeback treatment is where affiliate trust dies fastest, because reversals feel arbitrary if the rules weren't explicit. My plan: 30-day refund window matches the payout hold, so commission only becomes payable after the refund window closes. If a chargeback lands after that, commission is clawed back from the next payout, not from the affiliate's bank account. Written into the terms explicitly.

Pending, approved, reversed as three distinct dashboard states, each with a timestamp and a reason. An affiliate should be able to look at any reversed commission and see why (refund, chargeback, fraud flag, whatever) without opening a support ticket. Every state transition explainable, per your point.

Cookie length becoming less load-bearing when the rules are deterministic is the insight I hadn't fully absorbed. Most of the affiliate anxiety about attribution windows comes from the suspicion that the platform is quietly moving goalposts. If every stage transition is visible and rule-based, the cookie is just one input among several and the whole system feels fair even when the number is 30 instead of 90.

I'm going to write the "how the program works" doc against this structure and post it publicly before we onboard any serious volume. If you're open to it, I'd want to run the draft past you before it ships, because you clearly have scars from this problem that I don't have yet.

The one-step-earlier point is the right correction and I want to name it explicitly, because most founders skip it: instrument the value-delivery metric before you touch any acquisition channel, paid or otherwise. Without that number, every subsequent decision about channels, budget, or messaging is guessing dressed up as strategy. For you it's completed runs, for us it's users landing in the product after signup with a named workspace and doing something with it. Actually the update is that the manual approval gate that was killing that metric gets removed in today's release - auto-approve on signup, straight into org naming, into the product. So we're finally about to have a defensible activation number to reason from instead of one that's contaminated by an obvious upstream leak.

On affiliate visibility into activation: yes, and this is the part I underweighted in the original design. Current dashboard shows clicks and paid conversions, which is the industry default and also exactly the wrong incentive. An affiliate optimizing for clicks will send us a lot of curious traffic that bounces. An affiliate optimizing for activated workspaces will start filtering their own audience for fit before they even publish. That second behavior is what we actually want and we're not going to get it by measuring what we don't want.

The intermediate stages I want to expose: click, signup, activated workspace (has named org plus at least one meaningful action), first paid invoice. Aggregate only, no account-level data, so we respect the referred customer's privacy but affiliates can still see where their funnel converts and where it drops. If an affiliate sends 200 clicks that generate 40 signups but only 2 activations, that's a fit problem they can fix. If they send 30 clicks that generate 20 activations, they've found their audience and I want them to know it so they double down.

The engineering work to pipe those events into the affiliate dashboard is not trivial but it's the right thing to build before scaling the program, because otherwise we'll spend the next year retraining affiliate behavior around a metric that never mattered.

The "not worth my time unless there's a paid promo budget" response is the honest one and I appreciate that you shared the exact wording, because a lot of founders hear that line and think it means their product is weak. It usually just means the creator has a working economic model that affiliate can't compete with on a per-hour basis. Affiliate maths for a creator with a real audience only works when the product is already installed on their machine or already on their recommendation shortlist - anything else asks them to do unpaid R&D on speculation, which no one with distribution should reasonably say yes to.

Which is exactly why we're not doing any cold creator outreach. The affiliate page is a receipt for people already recommending us, not a sales funnel aimed at strangers with audiences. Trying to convert cold creators into affiliates either fails outright or, worse, succeeds briefly with someone who writes a lukewarm post they don't believe in, and both outcomes cost more than they return.

On the attribution question, the honest answer is that a lot of the real word-of-mouth value happens outside any cookie window and I can't attribute it. Someone reads this thread today, remembers BuildBase in eight weeks when they start their next project, installs directly - none of that goes to any affiliate. My working assumption is the cookie catches maybe a third of the actual referred value and the other two-thirds is a cost of doing distribution I have to eat. Trying to attribute perfectly would need either signup-through-link (bad UX, and no serious dev is going to route their signup through someone else's URL) or fingerprinting (worse, and a trust breach), and neither is worth the marginal accuracy.

The compromise I've settled on: 30-day last-click cookie, plus a manual override for cases where an affiliate can clearly demonstrate they were the referral source and the buyer confirms it. Not scalable, but it covers the "wrote a great post that converted someone eight weeks later" case without pretending I can technically solve it. Curious if you've seen any attribution model handle the long-tail case cleanly, because I haven't and I suspect no one has.

The signal-vs-noise framing is a cleaner articulation than what I put in the post and I'll be borrowing it. The part I want to push a bit further is the "positioning-clarity forcing function" angle, because I think it's the underrated benefit of running affiliate first.

To recruit even one thoughtful affiliate, you have to hand them a one-paragraph pitch that a stranger reading their post would find credible. If you can't write that paragraph, you don't actually know your positioning yet - you have a feature list and a hope. Cold ads let you skip that exercise indefinitely because you can A/B test your way into a headline that converts without ever articulating who the product is for. Affiliate recruitment forces the articulation up front, because a creator won't stake their credibility on ambiguity.

The measurement point extends the same way. A cold click tells you almost nothing about why someone bounced - could be pricing, positioning, funnel friction, wrong audience, any combination. An affiliate conversion (or the absence of one from a specific creator's audience) tells you something about the fit between your positioning and a known reader segment. That's a diagnostic signal, not just a revenue signal.

Concrete example from this thread: a couple of comments zeroed in on the org-creation popup as the real bottleneck, and they were right - we had a manual approval gate that killed activation before anyone saw the product. That fix ships today. If I'd been running ads for the last two months, the funnel data would've been buried under paid-traffic noise and I'd have blamed the creative instead of the config. Warm-first kept the signal legible long enough to see where the actual leak was.

Thanks - and honestly that connection was forced on us by looking at the funnel data, not by any strategic clarity up front. What almost happened was treating distribution and activation as two parallel roadmaps owned by different weeks. Once you sit with the drop-off numbers between signup and first paid invoice, the sequencing writes itself: any channel spend before the funnel is fixed is just paying to widen the leak faster.

Concrete example from this week - our activation blocker was a manual approval gate we'd added early on. Users signed up, hit a "pending approval" state, and bounced. Today's release removes it entirely: auto-approve on signup, straight into org naming, into the product. If I'd spent the last two months on ads instead, I'd have burned the budget teaching Google that our landing page doesn't convert, when the real fix was a config change.

The general principle I'm taking from this: for any channel decision, ask what the funnel would need to look like for that channel to be worth it, and if the current funnel isn't there, the channel choice is premature regardless of how attractive the CAC math looks on paper.