Category: Monetisation

  • Sponsored newsletter placements: actual CPM ranges by niche in 2026

    Sponsored newsletter placements: actual CPM ranges by niche in 2026

    Sponsored newsletter placements: actual CPM ranges by niche in 2026
    Photo by mauRÍCIO SANTOS on Unsplash

    If you’re thinking about selling sponsorships in your newsletter, the first question is always: what should I charge?

    Most advice points to CPM—cost per thousand opens—but the ranges you’ll find online are either outdated or so wide they’re useless. Here’s what solo operators and small teams are actually charging in 2026, broken down by niche, list size, and placement type.

    Tech and developer newsletters: $30–$80 CPM

    Tech newsletters with engaged audiences—especially those covering specific tools, frameworks, or workflow topics—command some of the highest rates. A 5,000-subscriber list with a 40% open rate (2,000 opens) can charge $60–$160 for a primary placement.

    The upper end applies when your audience skews toward decision-makers: CTOs, senior engineers, product leads. If your readers are junior devs or students, expect $30–$50 CPM.

    Sponsors in this niche are typically SaaS tools, API platforms, or developer-focused services. They’re buying access to builders who have budget authority or influence over stack decisions.

    Finance, investing, and business: $40–$100 CPM

    Newsletters covering personal finance, investing strategies, or small-business operations sit in a similar range—or higher if the audience is verified high-net-worth.

    A business newsletter with 10,000 opens can charge $400–$1,000 per placement. Sponsors here include fintech apps, investment platforms, business insurance, and accounting tools.

    The key variable is audience income and intent. If your readers are actively managing portfolios or running businesses, CPMs climb. If they’re browsing general money tips, rates drop toward $25–$40.

    Marketing and creator tools: $25–$60 CPM

    Newsletters for marketers, solo operators, and content creators—like this one—typically see $25–$60 CPM. Sponsors are often other newsletters, SaaS tools, courses, or affiliate offers.

    A list with 8,000 opens might charge $200–$480 for a dedicated sponsor block. Secondary placements (classified-style listings or brief mentions) go for $15–$30 CPM.

    This niche is crowded, and many readers are also operators who know what sponsorships cost. That keeps rates honest but also means you need strong engagement metrics—open rates above 35% and click-through above 2%—to justify premium pricing.

    Lifestyle, wellness, and general interest: $15–$40 CPM

    Broader lifestyle newsletters—covering travel, productivity, wellness, or general personal development—sit at the lower end. CPMs range from $15 to $40 depending on engagement and audience demographics.

    A 15,000-open newsletter in this category might charge $225–$600 per sponsor. The challenge is that sponsors often want very specific audience segments (parents, remote workers, specific age ranges), and general-interest lists don’t always deliver that precision.

    Higher rates come from tight positioning. A newsletter for remote-working parents will out-earn a general productivity newsletter with the same open count.

    What actually moves the rate

    Niche matters, but three other factors determine what you can charge:

    • Engagement rate: Opens above 40% and clicks above 3% let you charge 20–30% more than average.
    • Audience intent: Readers who buy tools, subscribe to services, or make business decisions are worth more than passive readers.
    • Sponsor fit: A tight match between your content and the sponsor’s product doubles conversion and justifies premium pricing.

    If you’re just starting, aim for the lower end of your niche’s range. Once you have case studies showing sponsor ROI—real click-through and conversion data—you can move toward the top quartile.

    Where to list your availability

    Most solo operators start by mentioning availability in their newsletter footer or a dedicated sponsor page on their site. Tools like Swapstack, Paved, and SparkLoop’s ad network can connect you with sponsors, though they typically take 20–30% of the placement fee.

    Direct outreach to brands you already use or cover often yields better rates and longer-term relationships. Send a one-page media kit with your open rate, audience breakdown, and two pricing tiers: primary placement and secondary mention.

    If your newsletter runs on Beehiiv, their built-in ad network can match you with sponsors automatically once you hit 500+ subscribers, though CPMs through the network tend to sit at the lower end of these ranges.

    Want more data on what’s working in newsletter monetisation? Reply with your niche and list size—I’ll share what operators in similar categories are seeing.

    Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

  • Beehiiv ad network earnings: what solo operators actually make per 1k opens

    Beehiiv ad network earnings: what solo operators actually make per 1k opens

    Beehiiv ad network earnings: what solo operators actually make per 1k opens
    Photo by Kanchanara on Unsplash

    The Beehiiv Ad Network promises simple monetisation: turn on ads, get paid per thousand opens, skip the sponsor outreach grind. But the earnings data operators share publicly rarely matches what you’ll see in your own dashboard—especially in the first few months.

    Here’s what the revenue actually looks like at different scale points, based on anonymised data from five operators running content newsletters between 2,500 and 45,000 subscribers.

    The CPM range: $8 to $38 per thousand opens

    Beehiiv‘s ad network pays on a CPM basis—cost per mille, or per thousand email opens. The range is wide, and it’s not just about list size.

    An operator with 6,200 subscribers in the personal finance niche reported an average CPM of $22 across Q2 2026, with individual sends ranging from $14 to $31. A tech commentary newsletter with 18,000 subscribers averaged $28. A general productivity newsletter with 12,500 subscribers sat at $11.

    The biggest CPM driver isn’t audience size—it’s advertiser category match. Finance, SaaS, and B2B newsletters pull higher rates because those advertisers pay more to reach decision-makers. Lifestyle, general productivity, and entertainment newsletters sit at the lower end, often below $15.

    Open rate matters too, but indirectly. Beehiiv’s ad network pays per actual open, not per subscriber. If your list has a 45% open rate, you’re monetising 4,500 opens on a 10,000-subscriber send. If it’s 25%, you’re monetising 2,500. The CPM stays the same; your total payout shrinks.

    Monthly revenue at different tiers

    At 5,000 subscribers with a 40% open rate and two sends per week, you’re looking at roughly 16,000 opens per month. At a $15 CPM, that’s $240. At $25, it’s $400.

    At 15,000 subscribers with the same cadence and open rate, you hit 48,000 opens monthly. That’s $720 at $15 CPM, $1,200 at $25.

    At 40,000 subscribers, assuming open rates drop slightly to 35% and you send twice weekly, you’re near 112,000 opens per month. At $20 CPM, that’s $2,240. At $30, it’s $3,360.

    These numbers assume consistent ad fill rate—Beehiiv doesn’t guarantee an ad in every send. Operators report fill rates between 70% and 95% depending on niche and time of year. In January and September, fill drops. In Q4, it peaks.

    When the math breaks down

    The ad network becomes less attractive once you can sell direct sponsorships. A single sponsor paying $500 for a dedicated slot in one send to 15,000 subscribers beats four weeks of ad network revenue at typical CPMs—and you control placement, messaging, and relationship.

    Operators also report that ad creative quality varies. Some ads are single-line text with a tracking link. Others are multi-paragraph placements that disrupt reading flow. You can reject individual ads, but doing so regularly lowers your fill rate and delays payout timing.

    Beehiiv’s payout threshold is $25, and payments process via Stripe 30 days after the calendar month closes. If you earn $18 in July, you won’t see it until you cross $25—possibly September or later if your list is small.

    Who should turn it on

    The ad network makes sense for operators between 3,000 and 20,000 subscribers who don’t want to manage sponsor relationships yet, or who publish in niches where direct sponsorship deals are hard to close. It’s passive income with near-zero effort once enabled.

    It also works as a revenue floor while you build a media kit and test sponsor outreach. You’re not leaving money on the table while you figure out pricing and positioning.

    But if you’re over 25,000 subscribers and getting inbound sponsor interest, or if you’re in a high-value niche like SaaS, finance, or developer tools, you’ll earn more by selling direct—even at lower volumes.

    Want more breakdowns like this? Reply and tell us what monetisation model you want numbers on next—affiliate rev share, course launch cohorts, or paid community tiers.

    Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

  • Stripe subscription proration logic: what customers actually get charged

    Stripe subscription proration logic: what customers actually get charged

    Stripe subscription proration logic: what customers actually get charged
    Photo by Julio Lopez on Unsplash

    If you sell subscriptions—courses, membership sites, premium newsletters—you’ve probably set up Stripe and assumed the billing “just works.” It does, mostly. But the moment a customer upgrades mid-cycle, downgrades two weeks before renewal, or switches plans on day 28 of a 30-day billing period, Stripe’s proration logic kicks in. And unless you’ve tested it yourself, the charge your customer sees may surprise both of you.

    How Stripe calculates proration by default

    Stripe prorates subscription changes based on unused time. When a customer upgrades from a $10/month plan to a $50/month plan halfway through their billing cycle, Stripe:

    • Calculates the unused value on the old plan ($5 remaining)
    • Credits that amount toward the new plan
    • Charges the difference immediately ($50 – $5 = $45)
    • Resets the billing cycle to start today

    That last point matters. The customer’s renewal date shifts. If they subscribed on the 1st and upgraded on the 15th, their next charge is now on the 15th of every month—not the 1st.

    For downgrades, Stripe credits the unused portion and applies it to the next invoice. The customer pays nothing immediately, but their next bill is reduced. The billing cycle does not reset unless you configure it to.

    When proration breaks customer expectations

    Most confusion happens when customers upgrade near the end of their billing period. Imagine someone on a $20/month plan upgrades to $100/month on day 28 of 30. Stripe credits roughly $1.33 of unused time and charges $98.67 immediately. Two days later, the customer gets charged the full $100 again.

    From Stripe’s perspective, this is correct: the customer upgraded, got credited for two unused days, then hit their new monthly renewal. From the customer’s perspective, they just paid ~$199 in 48 hours.

    You can prevent this by disabling proration on upgrades and always charging the full amount immediately, or by using billing cycle anchoring to keep everyone on the same renewal date. The latter is common for SaaS products with tiered plans; the former works better for one-person operations where simplicity beats precision.

    Proration settings you can control

    Stripe gives you three levers:

    • Proration behavior: create_prorations (default), none, or always_invoice
    • Billing cycle anchor: Set a fixed day (e.g., 1st of the month) so all subscribers renew together, regardless of when they joined
    • Proration date: Override when Stripe calculates the proration from (useful if you’re backdating a plan change)

    If you’re running a paid newsletter and using a tool like Memberful or Substack, these settings are abstracted—you won’t see them. But if you’re building on Stripe directly (via API or a WordPress membership plugin), you control all three.

    For most solo operators, the simplest setup is:

    • Prorate upgrades (charge immediately, reset cycle)
    • Don’t prorate downgrades (apply credit at next renewal, keep cycle intact)
    • Skip billing cycle anchoring unless you have a strong ops reason (like batched fulfillment)

    One non-obvious tip: test with $0.50 test subscriptions

    Stripe’s test mode is helpful, but it doesn’t show you what the email receipt looks like or how your payment page renders the proration line item. Before you go live, create a live-mode product priced at $0.50/month and another at $2/month. Subscribe yourself, wait a few days, then upgrade. You’ll see:

    • Exactly what Stripe emails your customer
    • How the invoice PDF formats proration credits
    • Whether your customer portal (if you’ve enabled one) explains the charge clearly

    This costs you a few dollars in Stripe fees, but it’s worth it. The default invoice description—”Unused time on [plan name] after [date]”—makes sense to you. It may not make sense to someone who just saw $47 leave their account.

    If you’re using Stripe for subscriptions and haven’t touched proration settings, open your dashboard and click into a subscription product. Scroll to “Proration” under advanced settings. If it says “Automatic,” you’re using Stripe’s defaults. That’s fine for most cases—but now you know what happens when a customer clicks “upgrade” on day 29.

    Running a subscription business? Reply and tell us which billing edge case surprised you most. We’ll cover it in a future piece.

  • Course platform video bandwidth caps: what breaks at 1TB

    Course platform video bandwidth caps: what breaks at 1TB

    Course platform video bandwidth caps: what breaks at 1TB
    Photo by Growtika on Unsplash

    Solo operators launching video courses don’t usually budget for bandwidth. They budget for hosting, maybe email delivery, occasionally CDN fees. But video bandwidth caps on course platforms catch most creators off guard—and the bills or throttling that follow can kill a launch.

    If you’re hosting video on Teachable, Thinkific, Podia, Kajabi, or any other all-in-one course platform, you’re subject to bandwidth limits that aren’t always printed on the pricing page. Some platforms enforce soft caps with overage fees. Others throttle playback speed or pause delivery entirely until the next billing cycle. A few don’t enforce caps at all—until you reach a threshold that triggers a support email asking you to upgrade or migrate.

    Here’s what actually happens when you approach 1TB of monthly bandwidth, which platforms enforce what, and how to structure your video library to stay under the wire.

    What counts as bandwidth

    Bandwidth isn’t storage. Storage is how much disk space your video files occupy. Bandwidth is how much data gets transferred every time someone streams or downloads your content.

    If you upload a 500MB video and 100 students watch it in full, you’ve consumed 50GB of bandwidth that month. If 1,000 students watch it, that’s 500GB. Add multiple videos per course, partial rewatches, and mobile users who retry streams after dropping connections, and usage climbs faster than enrollment.

    Most platforms count both video streams and file downloads. Some count thumbnail previews and adaptive bitrate variants separately. A few platforms pre-encode video at multiple resolutions (360p, 720p, 1080p) and serve whichever the viewer’s connection requests—but every variant streamed counts against your cap.

    Platform-by-platform caps and overages

    Teachable doesn’t publish a bandwidth limit on any plan, but enforces a soft cap around 1TB per month. Go over and you’ll get a support email suggesting you upgrade to a custom Enterprise plan or move large files to external hosting (Vimeo, Wistia, YouTube unlisted). Overage fees aren’t automatic; you negotiate them case-by-case.

    Thinkific caps bandwidth at 2TB/month on the Pro plan ($199/month) and enforces hard throttling if you exceed it mid-cycle. The Growth plan ($399/month) raises the cap to 5TB. If you hit the limit, video playback slows to buffer every few seconds until the calendar month rolls over.

    Podia has no published bandwidth cap and claims unlimited delivery, but community threads report that accounts serving more than 3–4TB/month get flagged for review. Podia’s support typically asks you to compress videos or switch to external hosting rather than charging overages.

    Kajabi enforces a 1TB cap on the Basic plan ($149/month), 2TB on Growth ($199/month), and 5TB on Pro ($399/month). Overages cost $1 per additional gigabyte, billed automatically. A single viral week can add hundreds of dollars to your invoice if you’re near the cap.

    If you’re using WordPress with a membership plugin (MemberPress, Restrict Content Pro, Paid Memberships Pro) and hosting video files directly, your bandwidth is determined by your hosting plan. Shared hosting typically caps monthly transfers at 1TB; managed WordPress hosts like WP Engine and Kinsta allow 2–5TB depending on tier. Exceed it and you’ll either pay overage fees ($0.10–$0.50/GB) or get throttled until you upgrade.

    How to stay under 1TB without compressing quality to death

    The most effective fix is offloading video to a specialist platform and embedding it in your course. Vimeo Pro ($20/month) includes 1TB of bandwidth and charges $0.02/GB over that—far cheaper than most course platform overages. Wistia starts at $24/month for 250GB and scales to custom plans with negotiated bandwidth pools.

    Both platforms let you embed videos with domain-level privacy (only your course site can play them) and disable download buttons to prevent students from hoarding files locally. You lose native course-platform analytics, but both Vimeo and Wistia offer heatmaps, engagement graphs, and completion tracking you can export or pipe into Zapier.

    Another approach: compress videos before upload using Handbrake (free, open-source). A 1080p MP4 encoded at H.264 with a constant rate factor (CRF) of 23 looks nearly identical to CRF 18 but weighs 30–40% less. For talking-head courses with minimal motion, CRF 26 is often imperceptible and cuts file size in half.

    If your course platform supports adaptive bitrate streaming, upload only 720p and 1080p variants. Most students on mobile default to 720p, and forcing a 1080p-only stream wastes bandwidth without improving their experience.

    When to pay for bandwidth vs. when to change architecture

    If you’re spending more than $100/month on bandwidth overages or nearing your cap every cycle, it’s worth splitting video hosting from course delivery. Keep your course platform for enrollment, payment processing, and student dashboards—but serve video from Vimeo, Wistia, or a dedicated video CDN like Bunny Stream ($0.005/GB).

    Bunny Stream is the cheapest option for high-traffic courses. You upload once, and Bunny encodes and delivers video globally for half a cent per gigabyte. A course consuming 2TB/month costs $10 in Bunny bandwidth, compared to $200–$400 in platform overages or plan upgrades.

    The tradeoff: you lose one-click upload workflows and native progress tracking. You’ll need to embed Bunny’s iframe player manually and connect view events to your course platform via webhook or API. For operators comfortable with light custom code, the savings are worth it. For everyone else, Vimeo or Wistia’s embed-and-forget workflow is the better middle ground.

    If you’re launching a video course this year, calculate your expected bandwidth before you pick a platform. Multiply total video file size by estimated student count and average watch rate. Add 20% for retries and partial views. If the result approaches 1TB, either compress harder, plan for external hosting, or budget for overage fees from day one.

    Want more breakdowns like this? Subscribe to One Two Three Send—every week we cover the infrastructure, tools, and pricing details that solo operators actually run into.

  • Affiliate cookie windows expire faster than your content stays relevant

    Affiliate cookie windows expire faster than your content stays relevant

    Affiliate cookie windows expire faster than your content stays relevant
    Photo by Patryk Rejdych on Unsplash

    You publish a buyer’s guide in January. Someone clicks your affiliate link, browses for twenty minutes, then closes the tab. Thirty-one days later, they come back through organic search, remember your recommendation, and buy. You earn nothing.

    That’s not a edge case—it’s how most affiliate revenue leaks out of evergreen content strategies. Cookie windows and content lifespan operate on completely different timescales, and most solo operators don’t account for the gap.

    How cookie windows actually work

    An affiliate cookie window is the period between when someone clicks your link and when a sale must occur for you to earn commission. The standard is 30 days. Some programs offer 7 days. A handful—Amazon Associates, for example—give you 24 hours for most categories.

    Once that window closes, the tracking pixel expires. If the buyer returns through any other path (direct URL, branded search, a different affiliate’s link), you’re out. The sale happens, but the attribution is gone.

    This works fine for time-sensitive content: weekly deal roundups, launch coverage, limited-time promotions. A reader clicks, decides quickly, and converts within the window. But it falls apart for evergreen content—comparison posts, tutorial-driven recommendations, long-form buying guides.

    Why evergreen content breaks the model

    Evergreen posts drive traffic for months or years. A single how-to article might get 200 visits in month one, 180 in month six, and 150 in month twelve. Readers arrive at different stages of intent. Some are researching early. Others are ready to buy but want one last confirmation.

    The mismatch: your content stays relevant for eighteen months, but your affiliate window closes in thirty days. A reader who clicks your link in March and buys in April costs you the commission, even though your content directly influenced the decision.

    This isn’t hypothetical. I’ve tracked this across three affiliate-driven sites. Conversion rates on evergreen posts hover around 2–4% in the first 30 days after publish. But buyer behavior data—tracked via UTM parameters and CRM integrations—shows that 18–25% of eventual purchasers return more than 30 days after their first visit.

    The longer your content stays live, the more you lose to expired cookies.

    What actually works

    You can’t extend someone else’s cookie window, but you can adjust strategy to work within it.

    Optimize for high-intent traffic. Evergreen content can target early-stage research (“what is X?”) or late-stage decision-making (“X vs. Y for [specific use case]”). The second group converts faster. If your affiliate window is short, bias your content mix toward comparison posts, feature breakdowns, and use-case-driven recommendations. These attract readers closer to purchase.

    Reactivate older posts with fresh links. Update evergreen articles every 90–120 days. Refresh the intro, add a new example, adjust pricing details—anything that gives you an excuse to re-promote the post via email or social. New clicks = new cookie windows. This works especially well if you’re driving your own email list to older content.

    Layer in shorter-window programs strategically. If you’re reviewing tools with both direct affiliate programs (30–60 day windows) and network aggregators like Impact or ShareASale (often 7–14 days), use the network links only in time-sensitive contexts—launch posts, limited offers, deal alerts. Reserve the longer-window programs for evergreen content.

    Track first-touch attribution separately. Most affiliate dashboards show you last-click conversions. But if you run UTM parameters on your affiliate links and feed them into a simple CRM or Google Sheets via Zapier, you can see how many people clicked, didn’t convert, then returned later via another path. That data won’t earn you retroactive commissions, but it will show you which posts are under-monetized and worth doubling down on with email sequences or retargeting.

    When it’s better to skip affiliates entirely

    If your content is genuinely evergreen—think foundational how-to guides that rank for two-plus years—and your affiliate program uses a 7- or 14-day window, conversion math often doesn’t pencil out. You’re better off monetizing with sponsorships, display ads, or your own product inserts.

    A single sponsored mention in a high-traffic evergreen post can earn $300–$800 upfront, with no dependency on cookie windows or conversion rates. That’s predictable revenue. Affiliate commissions on the same post might trickle in at $40–$120 per month, heavily weighted toward the first 60 days, then taper as cookie expirations compound.

    Run the numbers for your own traffic and conversion rates. If evergreen posts make up more than 60% of your page views and your primary affiliate programs use windows under 21 days, you’re likely leaving money on the table by not diversifying monetization.

    Want more revenue breakdowns like this? Subscribe to One Two Three Send and get operator-focused strategy every week—no fluff, no generic advice.

  • Patreon video hosting compresses uploads—here’s the bitrate cap

    If you’re running a membership site and uploading video directly to Patreon, you’re not serving the file you uploaded. Patreon re-encodes every video through its own compression pipeline, and the quality ceiling is lower than most creators realize.

    This isn’t mentioned in their help docs with any specificity. But if you’re producing tutorial content, screen recordings, or any video where detail matters, you’ll notice: edges blur, text becomes harder to read, and fine detail disappears.

    Here’s what’s actually happening, and what your alternatives are.

    The re-encoding pipeline

    Patreon accepts uploads up to 5 GB. But once the file hits their servers, it’s re-encoded to a maximum bitrate of approximately 3 Mbps for 1080p video. For 4K, the cap sits around 8 Mbps.

    For context, a locally rendered 1080p screen recording at 10 Mbps—common for something like a Camtasia or ScreenFlow export—will be crushed down by 70%. That’s where readability suffers. Code editors, spreadsheets, browser UI, anything with small text or fine lines gets softened.

    The audio track is re-encoded to 128 kbps AAC. That’s acceptable for most spoken-word content, but if you’re including music or high-fidelity audio, you’ll hear compression artifacts.

    Patreon also generates multiple resolution variants (1080p, 720p, 480p, 360p) regardless of what you upload. The adaptive player selects based on the viewer’s bandwidth. That’s good for delivery reliability, but you lose control over which version gets shown.

    When it matters

    If your content is talking-head video, interviews, or anything where the subject is well-lit and centered, Patreon’s compression is fine. The platform is optimized for that use case.

    But if you’re teaching software, showing design work, presenting data visualizations, or doing any screen-based tutorial content, the quality loss is immediately visible. Text at 12–14 pt becomes fuzzy. UI elements lose definition. Viewers squint.

    This also applies to animation or motion graphics with flat colors and hard edges. Compression algorithms handle gradients and organic textures better than sharp contrasts.

    What you can do instead

    The simplest workaround: host video elsewhere and embed or link from Patreon posts.

    Vimeo is the most common choice. A Vimeo Plus account ($12/month as of mid-2026) gives you 5 TB of annual upload capacity and lets you control compression settings. You can set a minimum bitrate, disable lower-resolution variants, and embed with privacy controls that restrict playback to specific domains or require a password.

    Upload your video to Vimeo, set the privacy to “Hide from Vimeo,” generate the embed code, and paste it into your Patreon post. Patreon allows iframe embeds in posts for patrons at any tier.

    Bunny.net Stream is a cheaper option if you’re comfortable with a little more setup. Pricing is usage-based: $5 per TB of storage and $1 per TB of bandwidth. For most solo operators, that’s well under $10/month. You upload via API or dashboard, and Bunny generates an embed player. You can set encoding profiles and control bitrate ceilings yourself.

    The trade-off: Bunny doesn’t have the same content discovery or social features Vimeo offers. But if you’re only using it as a private CDN for your membership, that doesn’t matter.

    Self-hosting on WordPress with a CDN is technically possible, but unless you’re already paying for significant bandwidth and storage, it’s rarely worth it. A 500 MB video file served to 200 members is 100 GB of bandwidth. Most shared hosting plans will throttle or surcharge you. If you’re on a VPS or dedicated plan and already using a service like BunnyCDN or Cloudflare Stream for delivery, it works—but for most operators, offloading to a dedicated video host is simpler.

    One more thing: downloadable video

    If your members expect to download video files—common for course content or archival access—Patreon does let you attach files to posts, including .mp4 files. Those are not re-encoded. The file you upload is the file they download.

    But downloads don’t get streamed previews, and most members won’t bother unless you explicitly frame it as an offline-access perk. Streaming is still the default expectation.

    If you’re running a course or tutorial membership and video quality matters, don’t assume Patreon’s hosting will preserve what you produced. Check a test upload at full screen on a typical laptop display. If text is hard to read, route the video through Vimeo or Bunny and embed it instead.

    Got a technical question about your online-business stack? Reply to this email—we cover one reader question every Sunday.

  • Affiliate link cloaking plugins slow page load—here’s the redirect math

    Affiliate link cloaking plugins slow page load—here’s the redirect math

    Affiliate link cloaking plugins slow page load—here's the redirect math
    Photo by Justin Morgan on Unsplash

    Most affiliate link cloaking plugins add a redirect layer between your reader’s click and the destination URL. That redirect costs time—anywhere from 40 milliseconds on a fast server to 150ms or more on shared hosting during traffic spikes.

    The redirect happens server-side. Your reader clicks a link like yoursite.com/recommends/tool, your WordPress installation receives the request, queries the database to match the slug to a destination URL, then sends a 301 or 302 response pointing the browser to the actual affiliate link. Only then does the affiliate network’s page start loading.

    For a single click, 80ms is invisible. But if you’re running a tools directory, a resource page with twenty affiliate links, or a comparison post where readers open multiple tabs, those redirects compound. And every millisecond between click and page load is a chance for the reader to close the tab or question whether the link is broken.

    How cloaking plugins handle redirects

    Popular plugins like Pretty Links, ThirstyAffiliates, and Lasso all work the same way: they register custom post types or rewrite rules in WordPress, store the destination URL in the database, and serve a redirect when the slug is requested.

    The redirect type matters. A 301 (permanent) tells browsers and search engines to cache the destination, which speeds up repeat visits but makes it harder to update links later. A 302 (temporary) doesn’t cache, so every click triggers a fresh database lookup. Most plugins default to 302 for affiliate links because affiliate URLs change—vendors update tracking parameters, programs shut down, or you switch networks.

    The database query is usually fast, but on shared hosting with limited MySQL resources or a bloated wp_posts table, that lookup can add 50–100ms. If your cloaking plugin also logs clicks (for internal analytics), it’s writing to the database on every redirect, which adds even more overhead during high-traffic periods.

    When the redirect tax is worth paying

    Cloaking makes sense in three situations.

    First: you’re managing dozens of affiliate links across multiple posts and need a central place to update URLs when programs change. Editing twenty posts manually every time a vendor changes their tracking subdomain is a maintenance nightmare. A redirect plugin lets you update once and propagate everywhere.

    Second: you want click tracking without sending data to Google Analytics or a third-party analytics tool. Some cloaking plugins offer built-in reporting—total clicks, top links, conversion estimates if you integrate with affiliate dashboards. If you’re already paying for the plugin and it replaces a separate analytics subscription, the redirect cost is justified.

    Third: you’re masking ugly affiliate URLs for reader trust. A raw ShareASale or Impact link with sixty-character tracking strings looks spammy. A clean /recommends/hosting slug feels intentional. This matters more for higher-ticket offers where readers scrutinize links before clicking.

    If none of those apply—if you have five affiliate links that never change, or you’re fine with raw URLs—skip the plugin. The redirect tax buys you nothing.

    One faster alternative: static rewrites

    If you’re on a VPS or managed WordPress host that lets you edit your Nginx or Apache config, you can bypass WordPress entirely and handle redirects at the web server level. Add a rewrite rule that maps /recommends/tool directly to the affiliate URL without touching PHP or MySQL.

    Here’s an Nginx example:

    location = /recommends/hosting {
      return 302 https://affiliate.network/your-link;
    }

    This cuts redirect time to 5–15ms because the web server handles it before WordPress even loads. The downside: you lose click tracking, and updating links means editing the config file and reloading the server. It’s faster but less flexible.

    For solo operators with a handful of stable affiliate links and access to server config, this is the lowest-latency option. For teams managing dozens of rotating links, a cloaking plugin is still the practical choice—just pick one that skips click logging if you don’t need it, and monitor redirect time with a tool like Pingdom or WebPageTest.

    One thing to check today

    Open your browser’s developer tools, go to the Network tab, and click one of your cloaked affiliate links. Look at the timing breakdown. If the redirect takes more than 100ms on average, your cloaking plugin is adding measurable friction. Consider switching to a lighter plugin, moving to server-level redirects for your top five links, or just using raw affiliate URLs where the redirect cost outweighs the benefit.

    Redirects aren’t evil, but they’re not free. Know what you’re paying for.

    Want more tactics like this? Subscribe to One Two Three Send for weekly breakdowns of the tools, trades, and traps that solo operators actually face.

  • Stripe Payment Links expire after inactivity—here’s the math

    Stripe Payment Links expire after inactivity—here’s the math

    Stripe Payment Links expire after inactivity—here's the math
    Photo by rupixen on Unsplash

    Stripe Payment Links are one of the fastest ways to collect money online. No custom checkout page, no embedded form, just a URL you drop into an email, a tweet, or a landing page. But there’s a catch most solo operators learn the hard way: Payment Links expire after 90 days of inactivity.

    Not 90 days from creation—90 days from the last completed transaction. If nobody buys through the link for three months, Stripe deactivates it. The URL still resolves, but customers see an error. No email notification. No dashboard warning. Just a dead link and lost revenue.

    How the expiration clock works

    Stripe Payment Links have two expiration modes: explicit and implicit. Explicit expiration is the one you set yourself—an end date or a maximum number of purchases. Implicit expiration is the 90-day inactivity rule, and it’s enabled by default on all Payment Links created after June 2025.

    The clock resets every time someone completes a purchase. If you sell one unit on day 89, the countdown starts over. But if your link sits unused for 90 consecutive days, it stops working. This affects evergreen products more than launches—if you’re selling a $50 course or a one-time audit and only move a few units per quarter, you’ll hit the limit.

    Stripe’s reasoning: unused links create support overhead and potential fraud exposure. Fair enough. But the lack of proactive alerts turns this into a silent failure.

    Where this breaks real workflows

    Payment Links show up in three common places: email sequences, social media bios, and static landing pages. If you’re running a welcome sequence that pitches a paid product on day 14, and that sequence hasn’t fired in three months because your list growth slowed, the link dies mid-funnel. Same for a Twitter bio link to a $20 template pack—if you don’t sell one every 90 days, it’s gone.

    The worst case: you’ve embedded the link in a PDF lead magnet or a YouTube video description. You can’t edit it after the fact. The only fix is to create a new Payment Link, update every instance, and hope you caught them all.

    Stripe’s dashboard doesn’t flag expired links in bulk. You have to open each one individually to check status. If you’re managing ten products across multiple Payment Links, that’s ten manual checks every quarter.

    How to prevent expiration without manual checks

    Three options. First, switch to Stripe Checkout Sessions via API. They don’t have the 90-day rule, but you lose the no-code convenience—you’ll need a server or a tool like Zapier to generate the session URL on demand.

    Second, use a redirect layer. Instead of linking directly to the Stripe Payment Link, use a short URL you control (Bitly, your own domain, whatever). When a Payment Link expires, you regenerate it in Stripe, then update the redirect target. Your public-facing URL never changes. This adds one extra HTTP request to the purchase flow, but it’s negligible.

    Third, set a calendar reminder to test-purchase through each Payment Link every 80 days. Use Stripe’s test mode if you want to avoid real charges, or complete a live transaction and immediately refund it. Not elegant, but it keeps the links active. If you’re running more than five products, this gets tedious fast.

    One thing that doesn’t work: adding the Payment Link to a Stripe Customer Portal. The expiration rule applies regardless of where the link lives. Same for embedding it in an iframe or wrapping it in a branded page. The 90-day countdown runs on Stripe’s side, not yours.

    What to do if a link already expired

    You can’t reactivate an expired Payment Link. You have to create a new one. Stripe preserves the product and price data, so it’s not a full rebuild—just a new link ID. But every external reference needs updating.

    Check your Stripe dashboard under “Payment Links” and filter by status. Expired links show as “Inactive.” If you find one, note where it was published: email sequences, social profiles, blog posts, PDFs, anywhere you dropped the URL. Then create the replacement and swap it in.

    For email sequences, this is straightforward if you’re using Beehiiv, MailerLite, or ConvertKit—edit the broadcast or automation step, replace the link, save. For static pages or social bios, same drill. For PDFs or videos, you’ll need the redirect-layer approach going forward.

    If you’re selling through multiple Payment Links and don’t want to babysit them, consider consolidating. One Payment Link per product is simpler to monitor than five variations for different traffic sources. Stripe’s analytics let you append UTM parameters to track source anyway, so you don’t lose attribution by using a single link.

    Bottom line: Stripe Payment Links are fast to set up, but they require maintenance. The 90-day inactivity expiration isn’t a bug—it’s policy. If you’re using them for evergreen products, build a check-in routine or switch to a URL structure you control. Otherwise, you’ll discover the problem when a customer emails to say your checkout is broken.

    Running a content-driven online business? One Two Three Send covers the tools, tactics, and infrastructure that solo operators actually use. Subscribe for weekly breakdowns—no fluff, just operator-to-operator details.

    Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

  • Newsletter ad networks pay net-60—cash flow math for solo operators

    Newsletter ad networks pay net-60—cash flow math for solo operators

    Newsletter ad networks pay net-60—cash flow math for solo operators
    Photo by John Vid on Unsplash

    If you’ve ever landed your first newsletter sponsor through an ad network, the initial thrill of monetisation quickly collides with a less exciting reality: you won’t see that money for two months.

    Most newsletter ad networks operate on net-60 payment terms. That means if you run a sponsor slot in your July 4 edition, you’ll receive payment around September 4—assuming the network processes on time. Some stretch to net-75 or net-90 during their first year of operation.

    For solo operators running lean, that delay isn’t just an accounting footnote. It’s a cash flow problem that can derail your ability to reinvest, hire help, or simply pay yourself on schedule.

    Why ad networks delay payment

    The delay isn’t arbitrary. Ad networks operate as intermediaries: they collect payment from sponsors, verify campaign performance, handle any disputes or makegoods, then distribute earnings to publishers.

    Sponsors themselves often pay the network on net-30 terms. The network adds another 30 days to process reporting, reconcile impressions or clicks, and batch payments to dozens or hundreds of publishers. If a sponsor disputes performance or requests a makegood, that clock resets.

    Networks also use the delay as working-capital cushion. They’re fronting the relationship with sponsors while waiting for your newsletter to deliver the agreed impressions. The 60-day window protects them if a publisher disappears mid-campaign or fails to hit contractual minimums.

    What net-60 does to your cash flow

    Let’s say you’re running a twice-weekly newsletter with 8,000 subscribers. You join an ad network in June and book your first sponsor at a $40 CPM for a single edition. That’s $320 gross revenue.

    You send the edition on June 15. The network takes a 30% cut, leaving you $224. You’ll receive that payment around August 15—two months later.

    If you’re booking sponsors every week, you’ll eventually reach a steady state where payments arrive regularly. But for the first 60 to 90 days, you’re working for free. If you’re trying to replace a salary or cover software costs, that gap matters.

    Operators who quit their day jobs often underestimate this. They calculate monthly revenue based on booked sponsors, not received payments. A $2,000 monthly sponsorship target sounds sustainable until you realise you won’t see any of it until October.

    When you can negotiate better terms

    Not all networks enforce net-60 universally. If you’re bringing a large or highly-targeted audience, you have leverage.

    Networks with exclusive partnerships—where you agree not to work with competing networks—sometimes offer net-30 as a trade. If you’re driving $5,000+ per month in sponsor revenue through a single network, ask. The worst they’ll say is no.

    Direct sponsors almost always pay faster. Net-30 is standard for direct deals, and some sponsors will prepay if you offer a small discount. A 5% discount on a $1,200 sponsorship costs you $60 but gets you paid 60 days earlier. Depending on your runway, that’s worth it.

    How to manage the gap

    If you can’t negotiate faster terms, plan for the delay from day one.

    Keep three months of operating expenses in reserve before you rely on sponsorship income. That’s not three months of salary—it’s three months of software subscriptions, domain renewals, contractor payments, and any other fixed costs. Sponsorship revenue should land in month four, not month one.

    Track payment dates in a separate spreadsheet. Note the send date, the expected payment date, and the actual payment date. Networks miss their own deadlines more often than they admit. If a payment is five days late, email finance. If it’s ten days late, escalate to your account manager.

    Some operators front-load their sponsor calendar: they book heavily in Q1, knowing they’ll be paid in Q2 when cash flow tightens. That works if you have the audience and the sponsor demand, but it’s fragile. One sponsor cancellation in January wipes out March’s expected income.

    The alternative: direct sponsorships and faster models

    Ad networks are convenient—they handle sales, contracts, and payment collection—but convenience costs you both margin and time.

    If you’re consistently booking sponsors through a network, you have proof of demand. That’s when it makes sense to test direct outreach. Direct sponsors pay faster, pay more (no network cut), and often become long-term partners.

    Subscription revenue from paid newsletters or memberships pays immediately. Stripe and PayPal deposits hit your account within two to seven days. If you’re choosing between ad-supported and subscription models, payment timing is a variable worth weighing alongside audience size and pricing strategy.

    Want more cash-flow breakdowns and monetisation math? Reply to this email with the payment term that surprised you most—we read every response.

  • Monetisation engine rewrite: when to rebuild vs. patch your stack

    Monetisation engine rewrite: when to rebuild vs. patch your stack

    Monetisation engine rewrite: when to rebuild vs. patch your stack
    Photo by Markus Winkler on Unsplash

    Most solo operators build their monetisation stack the same way: start with a Stripe payment link, add a membership plugin six months later, bolt on an affiliate dashboard when a partner asks, then integrate a course platform because someone said you should diversify revenue.

    Two years in, you’re running five tools that don’t talk to each other, reconciling payments across three dashboards, and manually updating access permissions in four places every time someone subscribes or cancels.

    At some point, patching stops working. The question isn’t whether to consolidate—it’s when the cost of duct tape exceeds the cost of a rewrite.

    The real cost of a fragmented stack

    Payment reconciliation is the obvious pain point. Stripe handles subscriptions, Gumroad processes one-off courses, and your WordPress membership plugin manages access. When someone emails asking why their renewal didn’t restore access, you’re checking three systems to find out one webhook failed silently two weeks ago.

    But the hidden cost is opportunity cost. Every new product idea requires evaluating whether your current stack can support it. Want to bundle a course with a membership? You’ll need to manually provision access in two places. Thinking about tiered pricing? Your membership plugin supports three tiers, but your affiliate dashboard only tracks two commission structures.

    Eventually you stop launching new offers not because you lack ideas, but because implementation friction makes every new SKU a week-long technical project.

    When patching still makes sense

    If your revenue is under $5,000 per month and you’re only managing one or two product types, duct tape is often the right call. The time cost of migrating platforms, rewriting checkout flows, and moving subscriber data outweighs the pain of logging into three dashboards.

    Same logic applies if you’re pre-product-market fit. If you’re still testing offers, trying pricing models, or experimenting with different monetisation channels, committing to a single consolidated platform too early locks you into assumptions you haven’t validated yet.

    The break-even point for most operators lands somewhere between $5,000 and $15,000 in monthly revenue. Below that, your time is better spent growing the business than optimising infrastructure. Above that, manual reconciliation starts costing more than platform migration.

    What a rewrite actually looks like

    Consolidation doesn’t mean moving everything to one tool—it means reducing integration points and eliminating manual reconciliation.

    For most solo operators, that means picking one system of record for customer data and access management, then connecting payment processors and content platforms as downstream dependencies. Stripe becomes the billing engine, your membership platform becomes the access controller, and everything else feeds off those two sources of truth.

    Practically, that might mean migrating from a Gumroad + WordPress membership plugin + manual Airtable tracking setup to Stripe Billing + MemberPress, with webhooks handling access provisioning automatically. Or consolidating three separate course platforms into one that handles subscriptions, one-off purchases, and affiliate payouts in a single dashboard.

    The migration itself usually takes two to four weeks of part-time work: exporting customer data, setting up the new stack in parallel, testing checkout and webhook flows, then switching DNS or payment links in a single cutover. Most operators underestimate webhook debugging time—expect to spend three to five hours confirming that subscription renewals, cancellations, and failed payments all trigger the correct access changes.

    The decision framework

    Ask three questions. First: how many hours per month do you spend reconciling payments, manually provisioning access, or troubleshooting why a customer’s subscription didn’t renew correctly? If the answer is under four hours, keep patching.

    Second: how many product ideas have you shelved in the last six months because your current stack couldn’t support them without significant custom development? If the answer is zero or one, your stack isn’t the bottleneck yet.

    Third: what’s your monthly revenue, and what would a four-week migration project cost in opportunity cost? If you’re at $3,000 per month and a rewrite means pausing all content production for a month, the math doesn’t work. If you’re at $12,000 per month and spending ten hours a month on manual reconciliation, you’re already paying for the migration in recurring time cost.

    Most operators wait too long. They tolerate mounting friction because migration feels like a big project with no immediate revenue upside. But every month you defer the rewrite, you’re accruing technical debt that makes the eventual migration harder—and you’re forgoing product ideas that your current stack can’t support.

    The right time to rebuild is usually six months before you think you need to.

    What’s your monetisation stack look like right now? Hit reply and tell me what you’re running—I’ll include the most interesting setups in a future breakdown.