One Two Three Send

Author: onetwothreeadmin

  • Gumroad’s rolling 30-day payout hold: what it means for cash flow

    Gumroad doesn’t pay you when a customer buys. It pays you 30 days after each individual sale—not 30 days after signup, not on a fixed monthly schedule. Every transaction starts its own countdown.

    If you’re used to Stripe’s two-day rolling payouts or payment processors that batch weekly, Gumroad’s model feels slower than it is. But the mechanics matter, especially when you’re scaling from a few sales a week to daily transactions. The delay doesn’t disappear once you pass some threshold. It rolls forward, sale by sale.

    How the 30-day hold actually works

    When someone buys your product on June 1, Gumroad releases that payment to your bank account on July 1. A sale on June 15 pays out July 15. There’s no aggregation, no calendar-month cutoff. Each sale has its own 30-day timer.

    For sellers with consistent daily volume, this creates a pseudo-steady state after the first month: you’re always receiving yesterday’s sales from 30 days ago. But in the early weeks, or during launch spikes, you feel the gap hard. A $5,000 launch day in week one becomes a $5,000 deposit in week five, long after you’ve paid for ads, freelancers, or software subscriptions that supported the launch.

    Gumroad’s stated reason is chargeback and fraud protection. Digital products see higher dispute rates than physical goods, and holding funds lets the platform cover refunds and contested transactions without chasing sellers for clawbacks. Fair enough—but it shifts working-capital planning onto you.

    When the delay compounds

    The 30-day hold isn’t static. If you issue a refund, Gumroad pulls from your pending balance first, then from your available balance if pending isn’t enough. That can push future payouts back further or create negative balances that offset incoming releases.

    Seasonal or campaign-driven businesses feel this more acutely. If you run a product launch in May and coast in June, your June cash flow is strong (May’s sales finally pay out) while July dries up. The mismatch between revenue-recognition timing and cash-in-hand makes monthly budgeting harder than it should be.

    There’s also a subtle tax-reporting wrinkle: Gumroad reports sale dates to the IRS, not payout dates. Your 1099 reflects when customers paid, but your bank account reflects 30 days later. For accrual accounting that’s fine; for cash-basis sole props, it’s a reconciliation headache every January.

    What you can do about it

    You can’t negotiate the hold away. Gumroad applies it universally, regardless of transaction history or volume. But you can plan around it.

    First, model your cash flow with the delay baked in. If you’re bootstrapping and every dollar counts, assume any revenue you generate today won’t hit your account for five weeks (30 days plus a few business days for bank transfer). Budget expenses accordingly. Don’t spend launch-week revenue on launch-week costs unless you have a separate cushion.

    Second, consider running a hybrid monetization stack. Use Gumroad for products where its simplicity and audience-discovery features matter—especially if you’re selling to creators who already browse the platform. But for high-ticket items, memberships, or anything with predicable monthly revenue, route payments through Stripe-connected tools like Memberful or Lemon Squeezy. Stripe’s default is a two-day rolling payout, and Lemon Squeezy batches twice a month. Both give you cash faster.

    Third, if you’re doing $10,000+ monthly on Gumroad and cash flow is genuinely constraining growth, talk to your bank about a line of credit or invoice factoring. It’s not free, but the cost of capital might be lower than the opportunity cost of delaying a hire or ad spend because you’re waiting on payouts.

    How it stacks up against alternatives

    Gumroad’s 30-day hold is longer than most competitor platforms. Lemon Squeezy pays out twice a month (on the 1st and 16th) after a short initial hold. Payhip has a 7-day hold for new accounts, then pays weekly. Stripe’s standard is two business days. PayPal is instant to your PayPal balance, though moving it to a bank account adds another day.

    The tradeoff is simplicity. Gumroad requires no developer integration, no SSL cert management, no checkout UI design. You get a link, you share it, you’re selling. For solo operators who want to ship fast and don’t want to wrestle with Stripe’s documentation, that’s worth something—especially early on.

    But once you’re past proof-of-concept and cash flow starts dictating what you can build next, the 30-day wait stops feeling like a reasonable trade. You’re not a high-risk merchant. You’re not drop-shipping gadgets from Alibaba. You’re selling ebooks, courses, templates—things with near-zero chargeback rates after the first week. The hold feels like a blunt instrument.

    If you’re already on Gumroad and the delay is biting, run the numbers on migration cost versus cash-flow gain. Moving your catalog to Lemon Squeezy or a Stripe-based tool takes a weekend, maybe two if you have complex product tiers. The faster payout cadence might free up enough working capital to pay for itself in a single quarter.

    One thing to try this week: Export your Gumroad sales CSV and map each transaction to its actual payout date (sale date plus 30 days). Compare that to your expense calendar. If you see a mismatch—launch costs in June, payouts in July—you’ve found your cash-flow pinch point. Fix it with a buffer fund, a different platform, or a line of credit. Don’t just hope it smooths out.

    Questions about payment processors, payout timing, or monetization mechanics? Reply to this email—I read every response, and reader questions drive half the articles here.

  • AI content generators charge by the token—here’s what you’re actually paying for

    AI content generators charge by the token—here’s what you’re actually paying for

    If you’re using AI to write drafts, generate social captions, or summarise research, you’ve seen the pricing: $0.002 per 1,000 tokens, $20 for 500,000 tokens, or a monthly credit pool that resets whether you use it or not. But unless you’ve dug into the billing docs, you probably don’t know what a token actually is—or why your 300-word article sometimes costs twice as much as another one the same length.

    Token-based pricing isn’t new. OpenAI, Anthropic, Cohere, and most API-first AI platforms use it. What is new is how many solo operators are now running these tools daily without understanding the unit economics. That gap shows up as surprise overage charges, underpriced client work, or abandoned workflows because “AI got too expensive.”

    Tokens are not words

    A token is a chunk of text the model processes. It’s usually a word, part of a word, or a punctuation mark. The exact split depends on the tokeniser the model uses—and different models tokenise differently.

    Claude uses a tokeniser that averages about 1.3 tokens per word in English. GPT-4 is similar. That means a 1,000-word article is roughly 1,300 tokens. But if you’re writing in a language with more complex characters, working with code, or including lots of special formatting, the ratio climbs. A Markdown-heavy draft with tables and links can push 1.8 tokens per word.

    This matters for budgeting. If you’re charging a client $50 for a 1,500-word AI-assisted article and you assume 1,500 tokens, you’ll underestimate your input cost by 30% or more once you factor in the prompt, context, and output.

    Input tokens cost less than output tokens

    Most AI platforms charge different rates for input (what you send) and output (what the model returns). As of mid-2025, Claude‘s Sonnet 3.5 charges $3 per million input tokens and $15 per million output tokens. GPT-4o is $5 input, $15 output.

    If you’re pasting a 2,000-word style guide into every prompt to keep the AI on-brand, that’s roughly 2,600 input tokens—every single time. Run that 100 times in a month and you’ve burned through 260,000 tokens before the model writes a word. At $3 per million, that’s $0.78. Not huge, but it adds up if you’re also including example posts, research notes, or previous drafts in the context window.

    Output costs more. A 1,000-word draft is 1,300 tokens of output. Generate 100 of those and you’re at 130,000 output tokens, or about $1.95 at Claude’s rates. Combined with input, a modest content operation can easily hit $50–$75/month in API costs—before you factor in revisions, which double or triple the token count.

    How to track what you’re actually spending

    Most AI platforms show token usage in the dashboard, but it’s often buried. In the OpenAI Playground, token counts appear after each response. In the API, you get them in the response payload. If you’re using a wrapper tool like Writesonic, Jasper, or Copy.ai, token reporting is inconsistent—some show it, some don’t, and some round aggressively.

    For client work or internal budgeting, track tokens at the API level. If you’re calling Claude or GPT-4 directly, log the usage object in each API response. It breaks out input tokens, output tokens, and total tokens. Export that to a spreadsheet once a week and you’ll see exactly where the spend concentrates.

    If you’re using a third-party tool, ask support how they bill tokens. Some apply a markup. Others bundle token costs into flat-rate plans but throttle you after a threshold. Jasper, for example, moved to word-based credits in 2024, but those credits map back to token estimates under the hood—and the exchange rate isn’t published.

    One non-obvious way to cut token costs

    Stop regenerating entire drafts when you only need to fix one section. Most AI tools let you highlight a paragraph and re-run just that part. If you’re using the API, trim your context window: instead of sending the full 3,000-token style guide every time, send a 200-token summary. Test whether a shorter prompt gets you 90% of the quality at 40% of the cost.

    Also: use cheaper models for simpler tasks. GPT-4o-mini costs $0.15 per million input tokens and $0.60 per million output—10x cheaper than GPT-4o. Claude’s Haiku is similarly cheap. If you’re generating meta descriptions, social captions, or reformatting lists, the cheaper model is usually fine. Save the expensive one for long-form drafts where nuance matters.

    Token pricing is transparent once you understand the math. The opacity comes from not tracking usage and not knowing which levers to pull. If you’re spending more than $20/month on AI content tools, you’re past the point where rough estimates work. Start logging tokens, compare input vs. output costs, and test cheaper models for repetitive tasks.

    Want more breakdowns like this? Subscribe to One Two Three Send and get one operator-focused deep-dive every day—no fluff, no vendor pitches.

    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.

  • Stop measuring open rate—deliverability lives in the spam folder

    Stop measuring open rate—deliverability lives in the spam folder

    Most solo operators watch open rates like a hawk. A 40% open rate feels like success. A 25% rate triggers panic and a subject-line audit.

    But open rate measures engagement among people who received your email in their inbox. It tells you nothing about the readers who never saw it because Gmail, Outlook, or Apple Mail dumped it straight into spam or the Promotions tab.

    If 30% of your list never sees your email, a 40% open rate on the remaining 70% means your true reach is closer to 28%. You’re optimising the wrong number.

    What deliverability actually measures

    Deliverability isn’t whether your ESP successfully handed off the email to the recipient’s server. That’s the delivery rate, and it’s usually high unless your domain is blocklisted.

    Deliverability is inbox placement—the percentage of delivered emails that land in the primary inbox, not spam, not Promotions, not the Updates tab.

    Your ESP’s dashboard won’t show this number by default. Most platforms report delivery rate and open rate, then stop. A high delivery rate and a decent open rate look healthy until you discover that a large share of your delivered emails went straight to spam.

    How to check where your emails actually land

    The simplest method: seed lists. Create a free account on Gmail, Outlook, Yahoo, and Apple iCloud. Add those addresses to a hidden segment in your ESP. Send every broadcast or automation to that segment, then manually check each inbox and spam folder within an hour of sending.

    Log what you see:

    • Primary inbox
    • Promotions tab (Gmail)
    • Spam folder
    • Not delivered at all

    Do this for ten consecutive sends. If more than two land in spam or Promotions, you have a placement problem, not an engagement problem.

    For a more automated approach, use a tool like GlockApps, Mail-Tester, or Litmus Spam Testing. These services give you test addresses across dozens of providers and return placement reports within minutes. Pricing changes often, so check each vendor’s own pricing page before you buy.

    What breaks inbox placement (and what doesn’t)

    Common advice blames spammy subject lines or too many exclamation points. In practice, inbox placement breaks for infrastructure reasons first, content reasons second.

    Authentication failures. If your SPF, DKIM, or DMARC records are misconfigured or missing, ISPs treat your emails as unverified. Even a single failed authentication check can trigger spam filtering. Check your DNS records using MXToolbox or dmarcian. If you’re sending from a subdomain (e.g., news.yourdomain.com), make sure your DKIM selector matches and your SPF record includes your ESP’s sending IPs.

    Low engagement history. ISPs track how recipients interact with your domain over time. If your recent emails had poor open rates or high spam-complaint rates, future emails start in spam by default. This creates a vicious cycle: spam placement lowers engagement, which worsens future placement.

    Sudden volume spikes. Sending to 5,000 subscribers after months of sending to 500 looks like a compromised account. Ramp slowly. If you’re reactivating a cold list or migrating ESPs, warm your domain by sending to your most engaged segment first, then expand over two weeks.

    Shared IP reputation. If you’re on a shared sending IP (common on lower-priced ESP plans), your placement depends partly on other senders using the same IP. One spammer on your IP can hurt your placement. Ask your provider whether your plan uses a shared or dedicated IP, and how it polices the senders it shares with.

    The non-obvious fix: prune faster

    Here’s the tactic most operators resist: remove unengaged subscribers before they hurt your sender reputation.

    If someone hasn’t opened an email in 90 days, they’re either not reading, using an email client that blocks tracking pixels, or your emails are landing in spam. Keeping them on the list lowers your engagement rate, which signals to ISPs that your content isn’t wanted.

    Set up a 90-day re-engagement automation: one plain-text email asking if they still want to hear from you, with a clear unsubscribe link. If they don’t click within seven days, remove them from your main list. Move them to a separate “cold” segment if you want to try again in six months, but stop sending regular broadcasts.

    This will drop your subscriber count. It will improve your open rate, click rate, and inbox placement. ISPs reward senders who mail engaged audiences.

    One metric to watch weekly

    If you track one number, make it your spam complaint rate—the percentage of recipients who mark your email as spam. Your ESP’s dashboard will show this, often buried under “Abuse Reports” or “Complaints.”

    Google asks bulk senders to keep the spam rate in Postmaster Tools below 0.10% (one complaint per 1,000 emails) and to avoid ever reaching 0.30% (Google’s email sender guidelines, checked October 2026).

    If your complaint rate spikes, stop sending and audit your signup flow. Are people actually opting in, or are you adding them without explicit consent? Is your unsubscribe link visible and one-click? Are you sending more frequently than you promised at signup?

    Most complaint spikes trace back to expectation mismatches, not content quality.

    Want to go deeper on email infrastructure and deliverability tactics? Reply to this email with your biggest placement headache—we’ll cover the most common issues in a future piece.

  • Analytics event naming: when consistent schemas break multi-tool funnels

    Analytics event naming: when consistent schemas break multi-tool funnels

    Most solo operators inherit analytics event-naming advice from enterprise playbooks: pick a consistent schema, document it in a spreadsheet, enforce it across every tool. The promise is clarity—one event name, one definition, one source of truth.

    The reality is messier. When you track the same event across Google Analytics 4, a CRM, an email platform, and a payment processor, identical labels often mean subtly different things. GA4’s purchase event fires on confirmation-page load. Your payment processor’s purchase webhook fires when funds clear. Your CRM’s purchase tag triggers when a deal stage changes. None of them happen at the same moment, and none of them count the same subset of transactions.

    Forcing a single name across all four systems doesn’t unify your data—it hides the gaps.

    Where naming consistency helps

    Event schemas make sense within a single platform. If you’re routing custom events into GA4, a predictable structure—category_action_label or verb_noun—keeps your reports readable and your segments reusable. The same applies to customer-data platforms that ingest events from multiple sources but store them in one database.

    Consistency also helps when you’re debugging. If every button click follows the same pattern—click_cta_header, click_cta_sidebar—you can filter by prefix and catch tracking gaps faster.

    But once you cross tool boundaries, the schema starts working against you.

    The multi-tool attribution gap

    Here’s the common scenario: you run a content site with a paid membership tier. A reader lands via organic search, opens three articles, clicks a paywall CTA, enters their email on a lead-magnet landing page, receives a nurture sequence, clicks a checkout link in email four, and completes payment.

    GA4 sees the paywall click and the checkout page view. Your email platform (MailerLite, Postmark, ConvertKit) sees the email opens and link clicks. Your payment processor (Stripe, Lemon Squeezy) sees the transaction. If you name every conversion point conversion, your attribution report shows three separate conversions with no shared context.

    You can’t merge them retroactively because the timestamps don’t align—GA4 logs in the user’s timezone, your email platform logs in UTC, and Stripe logs when the webhook fires, which might be seconds or minutes after the charge.

    Naming every step conversion or purchase makes your dashboard look unified. But when you try to calculate cost-per-acquisition or attribute revenue to a specific traffic source, you’re double- or triple-counting.

    Namespace by tool, not by intent

    A better approach: prefix event names with the tool or surface that generated them. Instead of purchase everywhere, use:

    • ga4_purchase for client-side page tracking
    • stripe_charge_succeeded for payment webhooks
    • crm_deal_closed for CRM pipeline updates
    • email_checkout_click for link tracking in transactional sequences

    This naming convention makes the gaps explicit. When you run a report and see four different revenue events for the same order, you know immediately which one to trust (usually the payment processor) and which ones are proxies.

    It also makes it easier to build rollup metrics. If you want a single “conversion” event that fires once per paying customer, you write a rule: count stripe_charge_succeeded, ignore everything else. You’re not guessing which purchase event is the real one.

    When to break the namespace rule

    There’s one case where tool-agnostic naming still makes sense: when you’re using a customer-data platform like Segment, RudderStack, or Hightouch to route events from a single source to multiple destinations.

    In that setup, the CDP is the source of truth. You send one Order Completed event with a structured payload, and the CDP forwards it to GA4, your CRM, your email tool, and your data warehouse. Each destination interprets the same event in its own way, but you’re starting from a single canonical definition.

    Even then, you’ll want to add destination-specific properties—GA4 needs transaction_id, Stripe needs payment_intent, your CRM needs deal_id—but the top-level event name can stay consistent.

    What this means for your reporting stack

    If you’ve been wrestling with attribution models that don’t add up, check your event-naming layer first. Open your GA4 events list, your email platform’s link-tracking log, and your payment processor’s webhook history. Look for overlapping names. If you see the same label in three places, assume they’re counting different things until you prove otherwise.

    Then decide which tool owns the metric. Revenue attribution? That’s your payment processor. Email engagement? That’s your ESP. Page-level behaviour? That’s GA4. Name your events to reflect ownership, not aspiration.

    The goal isn’t a beautiful schema—it’s a reporting stack where every number has one clear source and every query returns the same answer twice.

    Got a question about analytics, attribution, or tooling for solo operators? Reply to this newsletter—we read every response and use the best ones for future deep-dives.

  • ConvertKit’s visual automation builder: when branches break your flow

    ConvertKit’s visual automation builder replaced the old “sequence + rule” system in 2019, and most solo operators treat it like a flowchart app: drag some boxes, draw some lines, hit publish. It works—until you nest a few conditional branches or try to merge two paths back into one step, and subscribers start falling through cracks you didn’t know existed.

    The builder feels intuitive because it mirrors how we sketch funnels on paper. But the canvas hides execution logic that doesn’t always match what the diagram suggests. Here’s what actually happens under the hood, when to use it, and one non-obvious trick that keeps automations from breaking when you scale them.

    How the builder actually executes branches

    ConvertKit’s automation engine evaluates conditions at the moment a subscriber reaches that step. If you branch on “has tag X,” the system checks tag state right then—not when they entered the automation, and not continuously. That’s fine for simple yes/no splits, but it creates two common failure modes.

    First: timing gaps in nested branches. If you add a five-day delay before a conditional check, and the subscriber gains or loses the relevant tag during that delay, the branch decision reflects the tag state on day five—not day zero. Most operators assume the branch locks in at entry. It doesn’t.

    Second: parallel branches don’t merge cleanly. The canvas lets you draw two separate paths that converge into a single “Send email” step. Visually, it looks like both paths feed into one action. In practice, ConvertKit treats each incoming connection as a separate trigger. If a subscriber qualifies for both branches simultaneously—say, they have two tags that each route them down a different path—they’ll hit that shared email step twice and receive duplicate sends. There’s no automatic deduplication at merge points.

    When to use the visual builder vs. segments and broadcasts

    The automation builder shines when you need time-based sequencing with simple branching—onboarding flows, drip courses, or post-purchase follow-ups where the next step depends on one or two clear conditions (opened email, clicked link, purchased product). It’s purpose-built for “if this, then wait X days, then do that” logic.

    It’s the wrong tool when you need complex multi-condition logic or frequent re-evaluation. If your segmentation involves “has tag A and tag B, but not tag C, and joined before date D,” you’re better off using ConvertKit’s segment builder and sending one-off broadcasts to that segment. Segments re-evaluate in real time; automations evaluate once per step. Trying to replicate segment logic inside an automation canvas leads to branching spaghetti that’s impossible to debug when a subscriber reports they didn’t get an email.

    The other time to avoid the builder: when you need to pause or edit a live flow without stopping new subscribers. ConvertKit doesn’t let you edit an active automation. You have to duplicate it, make changes, archive the old one, and redirect new subscribers to the new version. Anyone mid-flight in the old automation stays there until they complete it or you manually move them. For high-traffic funnels, that’s a versioning nightmare. A combination of tags, segments, and scheduled broadcasts gives you more control.

    The non-obvious trick: use events, not tags, for branch conditions

    Most operators branch on tags because tags are visible and easy to apply. But tags are state—they can be added, removed, or changed by other automations, manual bulk actions, or integrations. If two automations both manipulate the same tag, you’ve introduced race conditions you can’t see on the canvas.

    ConvertKit’s event triggers—”Purchased product,” “Completed form,” “Clicked link in email”—are immutable. Once an event fires, it stays in the subscriber’s history. Branching on events instead of tags eliminates the timing-gap problem: you’re checking “did this happen” rather than “does this tag currently exist.”

    Practical example: instead of branching on “has tag: clicked-link-in-welcome-email” (which you’d apply via a separate link-trigger automation), branch directly on the event “Clicked link in [specific email].” It’s one fewer moving part, and the condition can’t be accidentally overwritten by a bulk tag removal you run three months later.

    The trade-off: events are harder to manipulate manually. If you need to retroactively mark someone as having completed a step, you can add a tag by hand; you can’t fake an event. For most use cases, that’s a feature, not a bug—it forces you to model your automation around actual subscriber behavior rather than abstract state.

    What to check before you publish

    Before you activate any automation with more than two branch points, walk through it as if you’re a subscriber who qualifies for multiple paths simultaneously. ConvertKit’s preview mode only shows you one path at a time; it won’t surface the duplicate-send issue. Manually trace each route on paper or in a separate doc.

    Also check your delays. ConvertKit’s builder lets you stack delays inside branches, and the total wait time isn’t surfaced anywhere in the UI. I’ve seen onboarding automations where the “fast track” branch accidentally included 14 days of cumulative delays because each step added “wait 2 days” without the operator realizing they’d nested four of them. Subscribers stopped engaging because the follow-up came two weeks late.

    Finally, set up a test subscriber with a disposable email and run them through the full flow in real time—don’t just use preview mode. Create the edge-case conditions: apply conflicting tags, click links out of order, purchase mid-sequence. You’ll catch merge issues and timing gaps that don’t show up in the visual review.

    If you’re running ConvertKit automations and want more tools and breakdowns like this one, subscribe to One Two Three Send. We cover the features and gotchas that don’t make it into official docs—one concrete piece per week, no fluff.

  • Productised consulting breaks when you template the wrong parts

    Productised consulting breaks when you template the wrong parts

    Productised consulting promises the appeal of recurring revenue without the chaos of custom projects. Fixed scope, fixed price, repeatable delivery. The pitch is seductive: package your expertise once, sell it many times, reclaim your calendar.

    But most solo operators who try it discover the same problem six months in: the parts they productised are the parts that needed to stay flexible. The parts they left manual are the ones begging for systems. The model doesn’t break because productisation is flawed—it breaks because operators template the wrong layer.

    The standard productisation mistake

    The typical approach goes like this: take your most popular consulting engagement, strip out the variability, write a scope document, set a flat fee, and launch a landing page. A website audit for $1,500. A content strategy sprint for $3,000. An email migration package for $2,200.

    It works for the first three clients. Then client four has a WordPress multisite setup your checklist didn’t account for. Client five wants Slack check-ins instead of email updates. Client six needs the deliverable two weeks early because they’re launching a product.

    You say yes because you need the revenue. You carve out exceptions. You adjust timelines. You rewrite sections of the template. Within two months, every engagement is a special case again, and you’re back to running a custom consulting practice with a productised label and a fixed price that no longer covers your time.

    What to productise: delivery infrastructure, not scope

    The fix is inverting the template. Don’t productise the scope—productise the scaffolding that makes delivery predictable.

    Productise your onboarding sequence: the intake form, the kickoff email, the Notion workspace structure, the Loom walkthrough you send on day one. Productise your communication cadence: update emails every Monday and Thursday, decision points flagged 48 hours in advance, async video reviews instead of meetings. Productise your handoff: the same Notion deliverable template, the same export format, the same two-week support window post-delivery.

    Let the scope flex. A site audit might include four pages for one client and forty for another. A content strategy might cover SEO for one operator and lead magnets for another. That variance is fine—it’s why clients hire you instead of buying a course. But if every client goes through the same onboarding, gets updates on the same schedule, and receives their deliverable in the same format, you’ve productised the part that actually creates leverage.

    This is how agencies scale without turning into workflow chaos. It’s also how solo operators can take on more clients without proportionally increasing coordination overhead.

    The second-order benefit: pricing becomes modular

    When you productise delivery instead of scope, pricing becomes easier to defend and easier to scale. Instead of a single flat fee, you can price along two axes: scope complexity and delivery speed.

    A basic website audit with standard delivery might be $1,200. The same audit with a 48-hour turnaround adds $600. An audit covering multisite, headless CMS, and API integrations adds another $900. The client picks the scope; you control the delivery cost by keeping the process identical across all tiers.

    This also solves the “I need it faster” problem. Clients who want to jump the queue pay for it. Clients who are fine with standard timelines get the lower price. You’re not discounting for flexibility—you’re charging for constraints.

    It’s the same reason Postmark charges per email sent, not per “email strategy.” The infrastructure is productised; the volume is variable.

    When to stick with fully productised scope anyway

    There are cases where locking down scope still makes sense. If your service is diagnostic—like a technical SEO audit or a site-speed analysis—the inputs are predictable enough that a checklist works. If your market is early-stage operators who don’t yet have complex infrastructure, variability stays low.

    But even then, the operators who run these services successfully are still productising delivery. The audit might be the same 40-point checklist every time, but the Loom walkthrough, the Notion handoff doc, and the two-week Q&A window are what make it repeatable.

    If you’re spending more time customising the template than you’d spend scoping a custom project, your productisation is backwards.

    The goal isn’t to eliminate variability. It’s to move variability into the part of the engagement where your expertise adds value—and to eliminate it everywhere else.

    Want more breakdowns on what works (and what doesn’t) when you’re running a content-driven business solo? Subscribe to One Two Three Send and get one focused article like this in your inbox each week.

  • Reddit’s new Ads API opens self-serve targeting to solo operators

    Reddit’s new Ads API opens self-serve targeting to solo operators

    Reddit rolled out a full-featured Ads API in late May 2026, and most solo operators missed it. The platform had previously gated programmatic access behind agency partnerships and minimum monthly spends well into five figures. Now you can spin up campaigns, pull performance data, and automate bid adjustments with a free developer account and a credit card that clears the $5 daily minimum.

    If you’ve been running Reddit ads through the web dashboard or ignoring the platform entirely because the manual workflow didn’t scale, this changes the math.

    What the API actually unlocks

    The new endpoints cover campaign creation, audience targeting, creative upload, bid management, and reporting. You can now script campaign launches tied to content publish dates, auto-pause underperforming ad groups when cost-per-click crosses a threshold, or pull spend and conversion data into your own analytics stack without CSV exports.

    The targeting options mirror what’s available in the dashboard—subreddit lists, interest clusters, keyword targeting, and lookalike audiences based on pixel data—but you can now template and duplicate campaigns in bulk. If you’re testing ten subreddit combinations across three creative variants, that’s thirty manual setups in the UI versus a single script run.

    Rate limits sit at 600 requests per minute for most endpoints, which is generous for a solo operator or small team. Creative assets upload through a separate media endpoint that accepts PNG, JPG, and MP4 up to 200 MB. Video ads now support 16:9 and 4:5 aspect ratios, though square still outperforms in feed placement based on Reddit’s own case studies published in April.

    Where the workflow breaks down

    The API documentation assumes you’re comfortable with OAuth 2.0 flows and can parse JSON responses without a GUI. If you’ve never touched an API before, the learning curve is steeper than clicking through Ads Manager. Reddit provides Python and JavaScript SDKs, but they’re not as polished as Meta’s or Google’s—expect to write more error-handling logic yourself.

    Conversion tracking still requires Reddit’s pixel or the Conversions API, and setup is manual. You can’t provision pixels programmatically yet, so your first campaign still involves copying a JavaScript snippet into your site footer or wiring up server-side events. If you’re running a headless CMS or a static site, the server-side route is cleaner but requires endpoint configuration that isn’t trivial.

    The API also doesn’t surface some diagnostics that show up in the dashboard. If an ad gets rejected for policy violations, the error message in the API response is often a generic code without the specific flagged term. You’ll still need to log into the web UI to see what tripped the filter.

    Pricing and when this makes sense

    Reddit ads run on a second-price auction with a $5 daily minimum per campaign. CPCs vary wildly by subreddit—anywhere from $0.20 in broad interest groups to $4+ in finance or SaaS communities. The API doesn’t change the auction mechanics, but it does let you kill spend faster when a test flops.

    This is worth the setup time if you’re running more than two campaigns a month, testing multiple subreddit clusters, or pulling ad data into a consolidated dashboard alongside Google, Meta, or other channels. If you’re spending under $500/month total and running a single evergreen campaign, the manual workflow is still faster.

    For content-driven businesses publishing on a schedule—newsletters that promote each issue, course creators launching cohorts, or affiliates running seasonal pushes—the ability to automate campaign start dates and creative swaps cuts hours of repetitive work.

    One non-obvious trick

    Reddit’s audience expansion toggle is on by default when you create campaigns through the API, even if you specify exact subreddit targeting. This means Reddit will serve your ad outside your defined subreddit list if its algorithm thinks the user matches your intent. That’s fine for awareness plays, but it torches budgets if you’re targeting a niche community for a specific reason.

    The parameter is expansion_enabled in the campaign create request. Set it to false unless you’ve explicitly decided to let Reddit’s algorithm roam. The dashboard makes this a checkbox you have to actively enable; the API flips the default.

    If you want to test this without writing code, tools like Postman or Insomnia let you authenticate and send API requests through a GUI. Reddit’s OAuth flow is standard—register an app in your account settings, grab your client ID and secret, request a bearer token, and attach it to subsequent requests. The whole setup takes about fifteen minutes if you’ve done it with another platform before.

    Have you tried Reddit’s Ads API yet, or are you sticking with another platform for paid tests? Reply and let us know—we’re tracking which ad channels solo operators actually use in 2026, and we’ll share the numbers in a future issue. Subscribe here if you want that data when it drops.

  • WordPress plugin auto-updates: when to enable and when to wait

    WordPress plugin auto-updates: when to enable and when to wait

    WordPress added automatic plugin updates in version 5.5, and the feature has quietly become one of the most misunderstood levers in the admin dashboard. Enable it everywhere and you risk pushing a breaking change to production at 3 a.m. Disable it completely and you’re one unpatched vulnerability away from a compromised site.

    The decision isn’t binary. Most operators treat auto-updates as an all-or-nothing switch, but the smarter play is selective: some plugins earn the privilege, others don’t.

    What actually happens when you enable auto-updates

    When you toggle auto-updates for a plugin, WordPress adds it to a background job that runs twice daily. If a new version is available and passes a few basic checks—compatible WordPress version, no obvious conflicts—the update executes without asking.

    The update happens during a cron event, not in real time. If your site has low traffic or your server’s cron is misconfigured, the update may delay by hours. That’s not a bug; it’s how WordPress schedules background tasks.

    WordPress sends an email after each auto-update. If you’re not seeing those, check your transactional email setup—most hosts route wp_mail() through unreliable SMTP by default. If you’re using Postmark or another dedicated transactional service, the notifications land reliably.

    One detail most guides skip: auto-updates do not create database backups before running. If a plugin update breaks your schema or corrupts data, you’re restoring from your last manual or scheduled backup. That’s why staging environments matter.

    Which plugins to trust with auto-updates

    Not all plugins carry the same risk profile. Small, single-purpose utilities—contact forms, social share buttons, analytics connectors—rarely introduce breaking changes. They touch a narrow slice of your site and update infrequently.

    Security-focused plugins are the best candidates: Wordfence, Sucuri, iThemes Security. These update often, and delaying a security patch is riskier than the update itself. The vendors test obsessively because their reputation depends on it.

    Plugins maintained by large platforms—Jetpack, WooCommerce, Yoast SEO—also qualify. They have QA teams, beta cycles, and rollback mechanisms. Auto-updating these is less risky than manually updating at random intervals.

    Avoid auto-updates for plugins that:

    • Modify your database schema (membership plugins, custom post-type builders)
    • Interact with payment processors (WooCommerce extensions, Easy Digital Downloads add-ons)
    • Control caching or performance (WP Rocket, LiteSpeed Cache—these can break rendering)
    • Hook deeply into your theme (page builders, custom fields)

    For these, the cost of an unexpected break in production outweighs the convenience of hands-off updates.

    How to test updates before enabling auto-update

    If you’re running a staging environment, clone production, enable auto-updates there first, and wait two weeks. If nothing breaks, enable it on the live site. Staging environments catch 80% of update conflicts before they hit real traffic.

    If you don’t have staging, manual-update high-risk plugins during low-traffic windows. Check your analytics for the quietest two-hour block each week—usually early morning in your primary timezone—and batch updates then. Keep your browser open for ten minutes after updating and test key workflows: checkout, form submissions, member login.

    For plugins that update frequently—weekly or more—auto-updates make sense even if they’re high-risk, because the manual burden becomes unsustainable. You’ll spend more time clicking “Update” than you’ll lose to occasional rollbacks.

    The non-obvious tip: monitor update frequency before committing

    Before enabling auto-updates, check the plugin’s update history on WordPress.org. Click “Development” in the plugin’s listing and scan the changelog. If the vendor ships five updates a month with vague notes like “bug fixes” or “performance improvements,” that’s a red flag. Frequent, low-detail updates suggest poor testing or reactive development.

    Plugins that update every 60–90 days with detailed changelogs are safer bets. The vendor is batching changes, running QA, and treating releases as events rather than continuous patches.

    One more filter: check the “Active Installations” count. Plugins with 100,000+ installs get battle-tested by a large user base. If a breaking change ships, it’s caught and patched within hours. Plugins with fewer than 10,000 installs don’t have that safety net.

    Auto-updates work best when the plugin vendor has more to lose than you do. High-profile plugins with millions of users can’t afford to break sites at scale. Niche plugins with small audiences can.

    Want more deployment and workflow tips? Subscribe to One Two Three Send—every issue covers one specific decision point for operators running content businesses.

  • Newsletter subscriber surveys: what to ask and what to skip

    You want to know what your subscribers care about. A survey feels like the obvious solution. But most operators write surveys that produce either useless vanity metrics or mountains of data they don’t have time to parse.

    The problem isn’t surveying itself—it’s asking the wrong questions, at the wrong time, in the wrong format. Here’s how to build a subscriber survey that gives you actionable editorial direction without burning goodwill or drowning in responses you can’t use.

    Ask about future content, not past issues

    The most common survey mistake is asking subscribers to rate or rank your previous newsletters. “Which issue did you like best?” or “How would you rate our content?” These questions feel safe, but they’re backward-looking and subjective.

    Instead, ask what they want to read next. Frame questions around problems they’re trying to solve or topics they’re actively researching. For example:

    • “What’s the biggest challenge you’re facing with [your niche topic] right now?”
    • “Which of these topics would help you most in the next 30 days?”
    • “What question do you wish someone would answer about [topic]?”

    You’re not polling for popularity—you’re mining for editorial gaps. The answers tell you what to write, not whether people liked what you already sent.

    Keep it to three questions, maybe four

    Survey fatigue is real. If your form scrolls, response rates drop. If it takes more than 90 seconds, you lose half your respondents before they finish.

    Limit yourself to three core questions. If you absolutely need a fourth, make it optional. Use multiple-choice wherever possible—open-text fields are harder to analyze at scale, and most subscribers won’t fill them out anyway.

    Here’s a template structure that works:

    • Question 1: Multiple-choice topic preference (4–6 options)
    • Question 2: Open-text pain point or challenge (optional)
    • Question 3: Demographic or context question (e.g., “How long have you been running your business?”)

    That’s it. You’ll get a higher completion rate and cleaner data.

    Segment your ask—don’t survey everyone at once

    Not all subscribers need to answer the same questions. If you’re running a newsletter with both beginners and experienced operators, surveying them together will muddy your results.

    Instead, segment your survey by behavior or tenure. For example:

    • New subscribers (joined in the last 30 days) get a short onboarding survey focused on their current goals.
    • Engaged readers (opened 8+ of the last 10 emails) get a deeper content-direction survey.
    • Inactive subscribers (haven’t opened in 60+ days) get a simple re-engagement question: “What would make this newsletter more useful to you?”

    Most email platforms—MailerLite, Beehiiv, ConvertKit—let you tag or segment by open rate or signup date. Use that data to send the right survey to the right group.

    Don’t survey more than twice a year

    Survey burnout is worse than survey silence. If you ask for feedback every quarter, subscribers start ignoring you. Once or twice a year is plenty—unless you’re pivoting your editorial strategy or launching a new product.

    When you do survey, close the loop. Send a follow-up email a week later summarizing what you heard and what you’re changing. It doesn’t have to be long—three bullet points and a sentence about what’s coming next. This reinforces that their input mattered and primes them to respond next time.

    One operator I know sends a yearly survey in January and a mid-year check-in in June. Both are three questions, both close with a “here’s what I heard” email. Her response rate hovers around 22%, well above the typical 10–15% for cold surveys.

    Skip the NPS question

    Net Promoter Score—”How likely are you to recommend this newsletter?”—is a corporate metric that doesn’t translate well to solo operators. It’s designed for companies with large customer bases and multi-touch attribution. For a newsletter, it’s noise.

    You don’t need a numerical score. You need to know what to write next and whether you’re solving the right problems. Save the NPS question for SaaS dashboards.

    Use survey data to build a content queue, not a strategy document

    Once responses come in, resist the urge to over-analyze. You’re not running a focus group—you’re filling your editorial calendar.

    Pull the top three topics or pain points mentioned. Schedule one article or issue for each in the next 30 days. If a question came up repeatedly in open-text responses, turn it into a Q&A or tutorial. That’s the loop: ask, write, ship.

    Survey data goes stale fast. If you wait two months to act on feedback, the problems your subscribers cared about in March might be irrelevant by May. Treat survey results like perishable inventory.

    Want more tactical breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives on the tools, tactics, and trade-offs that matter for online operators.

    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.

  • Course completion rates hover around 15%—here’s what moves the needle

    Course completion rates hover around 15%—here’s what moves the needle

    The average online course completion rate sits between 10% and 20%. If you’re running a paid course as part of your content business, that number probably feels familiar—and frustrating.

    The usual advice—gamification, drip schedules, community access—sounds good in theory. But the data from operators actually running courses tells a different story about what moves completion rates and what’s mostly noise.

    What the numbers look like in practice

    Three operators shared their course metrics over the past 18 months. All three run evergreen courses priced between $149 and $497, sold primarily to their email lists.

    Operator A: A WordPress productivity course with 847 enrollments. Completion rate: 18%. Average time to finish: 6.3 weeks. Refund rate: 4.2%.

    Operator B: An SEO fundamentals course with 1,203 enrollments. Completion rate: 23%. Average time to finish: 9.1 weeks. Refund rate: 6.8%.

    Operator C: A newsletter monetization course with 614 enrollments. Completion rate: 14%. Average time to finish: 11.4 weeks. Refund rate: 3.1%.

    The spread is narrow. All three courses include video lessons, worksheets, and some form of community or Q&A access. Pricing and production quality didn’t predict completion—the $497 course had the lowest rate.

    Three changes that actually moved the needle

    Operator B added a single check-in email at the 72-hour mark. It’s not a drip sequence. It’s one manual email sent three days after purchase asking what section the student is working on and if anything’s blocking them. Response rate: 31%. Completion rate climbed from 19% to 23% over six months. The email takes four minutes to send per cohort of 20–30 buyers.

    Operator A cut the course from 22 lessons to 14. The original version tried to be comprehensive. The shorter version focused on three workflows and cut everything else. Completion rate went from 14% to 18%. Refund rate stayed flat. Students finished faster—5.1 weeks instead of 7.8—and left better reviews.

    Operator C introduced a 48-hour «finish line» challenge. Once a month, students who’ve completed 80% or more get an email with a 48-hour window to finish the last module and submit their final project. It’s not a hard deadline—the course stays open—but the nudge works. Completion among students who receive the email: 67%. Overall course completion rose from 11% to 14%.

    What didn’t work

    All three operators tried Facebook groups or Slack communities. Operator A’s group had 18% of enrollees join; 4% posted more than once. Operator B shut down their Slack after three months—too much moderation overhead for minimal engagement. Operator C kept a Circle community but stopped treating it as a completion lever.

    Gamification—badges, progress bars, leaderboards—showed no measurable impact on completion for any of the three. Operator B’s course platform (Teachable) includes progress tracking by default. Students who completed the course had the same interaction rate with progress indicators as students who dropped off after module two.

    Drip schedules were neutral to slightly negative. Operator A tested releasing one lesson per week versus full access on day one. Completion rates were statistically identical (17.8% vs. 18.1%), but students on the drip schedule were more likely to request refunds in week two, before the course was fully unlocked.

    The completion-rate mistake most operators make

    Chasing higher completion rates assumes completion is always the right goal. It’s not.

    Operator C’s course teaches newsletter monetization. Some students buy it, watch the sponsorship module, land their first sponsor, and never finish the rest. They got what they paid for. Refund rate is low. Testimonials are strong. Completion rate is 14%.

    The better metric: outcome rate. What percentage of students achieved the result the course promised? For Operator C, 41% of students reported landing a sponsor, affiliate deal, or paid subscription tier within 90 days. That’s nearly three times the completion rate—and the number that matters for retention and referrals.

    If you’re optimizing for completion, track it. But if you’re optimizing for business results, measure the outcome your course promises and work backward from there.

    Want more operator data like this? Reply and tell us what metrics you’re trying to move—we’ll find operators who’ve solved it and share what worked.

Powered by CookieAdmin