One Two Three Send

Author: onetwothreeadmin

  • How to set up Amazon SES for sending your newsletter — a complete step-by-step guide

    How to set up Amazon SES for sending your newsletter — a complete step-by-step guide

    Amazon SES (Simple Email Service) is a low-cost way to send a newsletter at scale. Its pay-as-you-go price is $0.10 per thousand emails (AWS SES pricing, checked 27 October 2026), with no per-contact pricing. It is a sending engine rather than a full newsletter platform.

    The trade-off: you set it up yourself. AWS doesn’t hand-hold. This guide walks every step end-to-end so you don’t get stuck on the parts that catch most operators (DNS records, sandbox approval, bounce handling). Allow plenty of time the first time you do this, because DNS changes take a while to show up.

    Before you start

    • A domain you own (e.g. yourname.com). You’ll send from [email protected] or similar. SES verifies the entire domain, not individual email addresses, so this is the right approach for a newsletter.
    • Access to your domain’s DNS — wherever you registered the domain (Namecheap, GoDaddy, Cloudflare, Route 53). You’ll add several records.
    • An AWS account. Free to create. AWS asks for a payment card when you sign up; check the SES pricing page for what you’ll be charged.
    • 10 minutes patience for DNS propagation between steps.

    Step 1 — Sign in to AWS and open SES

    Go to aws.amazon.com/console and sign in (or create an account — pick “Personal” or “Business”, give them a card, you’re done).

    Once you’re in the AWS Console, type “SES” in the top search bar and click Amazon Simple Email Service. You’ll land on the SES home page.

    Step 2 — Pick your region

    This matters. SES is region-scoped — settings you make in one region don’t exist in another. Top right of the console there’s a region picker (it’ll say something like “N. Virginia” or “Oregon”).

    Pick the region closest to most of your subscribers. For a US audience: us-east-1 (N. Virginia) or us-west-2 (Oregon). For Europe: eu-west-1 (Ireland) or eu-central-1 (Frankfurt). The region affects deliverability latency but only marginally. Pick one and stick with it — moving later means re-verifying your domain.

    Step 3 — Verify your sending domain

    In the left sidebar of SES, click Verified identities, then Create identity.

    • Identity type: Domain (not Email address — domain verification covers every address on the domain).
    • Domain: enter your domain (e.g. yourname.com, no www, no https://).
    • Tick Use a custom MAIL FROM domain and enter a subdomain like mail.yourname.com. This is what shows up in bounce-handling headers — a custom MAIL FROM domain lets SPF align with your own domain for DMARC.
    • Under Advanced DKIM settings: leave Easy DKIM selected, RSA_2048_BIT. Tick Publish DNS records to Route 53 only if your DNS lives in Route 53; otherwise leave unticked.
    • Click Create identity.

    SES gives you a screen with DNS records to add. Keep this tab open — you’ll need it in the next step.

    Step 4 — Add the DNS records

    You’ll add four sets of DNS records. Log into your DNS host (Namecheap, GoDaddy, Cloudflare, etc.) in a separate tab.

    4a — DKIM records (3 CNAMEs). SES gives you three CNAME records that look like abc123._domainkey.yourname.com pointing at abc123.dkim.amazonses.com. Add all three exactly as shown. These prove emails you send are actually from you.

    4b — MAIL FROM records (2 records). One MX record on the subdomain you chose (mail.yourname.com) pointing at feedback-smtp.[region].amazonses.com with priority 10, and one TXT record on the same subdomain with value "v=spf1 include:amazonses.com ~all".

    4c — SPF on the root domain. Add (or update) a TXT record on yourname.com with value "v=spf1 include:amazonses.com ~all". If you already have an SPF record, don’t add a second one — edit the existing one to include include:amazonses.com before the closing ~all.

    4d — DMARC. This isn’t required by SES but Gmail and Yahoo now require it for bulk senders (5,000+/day). Add a TXT record on _dmarc.yourname.com with value "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; adkim=s; aspf=r;". Replace the email address with one you check.

    Wait 5–10 minutes, then back in the SES tab refresh the Verified identities page. The domain should flip to Verified with DKIM Successful. If it doesn’t after 30 minutes, your DNS records are wrong — open them in your DNS host and compare character-by-character to what SES shows.

    Step 5 — Request production access (leave the sandbox)

    By default, every new SES account is in sandbox mode: 200 emails per day, and you can only send to verified email addresses. That’s useless for a newsletter.

    In the SES console sidebar, click Account dashboard. You’ll see a banner saying you’re in the sandbox. Click Request production access (or Get set up).

    The form asks why you want to send mail. Answer specifically about how you’ll handle opt-ins, bounces and complaints. Good template:

    Mail type: Marketing

    Website URL: https://yourname.com

    Use case description: “I run a newsletter at yourname.com. Subscribers sign up via a double-opt-in form on the website and confirm via a verification email. They receive a weekly newsletter on [your topic]. Unsubscribes are honoured immediately via one-click unsubscribe headers (RFC 8058) and a footer link. I will monitor bounces and complaints via SNS topics and remove problem addresses automatically. Expected initial volume: 1,000 emails/day, growing with the list.”

    Additional contacts: “I do not buy email lists. All addresses come from people who actively signed up on my website.”

    Submit. AWS says its support team gives an initial response within 96 hours (SES production access docs, checked 27 October 2026). If they need more information, reply with specifics.

    Step 6 — Create SMTP credentials

    While you wait for production approval, set up the credentials your newsletter plugin will use to send.

    In the SES sidebar, click SMTP settings. You’ll see the SMTP endpoint for your region (e.g. email-smtp.us-east-1.amazonaws.com) and a port (use 587 with STARTTLS).

    Click Create SMTP credentials. AWS creates an IAM user behind the scenes that has permission to send mail through SES. Copy the SMTP username and password immediately — AWS shows them once and never again. Save them in a password manager.

    Step 7 — Set up bounce and complaint handling (SNS)

    This step is optional but strongly recommended. SES will email you about bounces and complaints by default, but for a real newsletter you want them processed automatically — bounces auto-removed from your list, complaints flagged for review.

    In the AWS Console, search SNS and open Simple Notification Service. Create two topics — one called ses-bounces, one called ses-complaints. Note the ARN (Amazon Resource Name) of each.

    Back in SES, open your verified domain identity, scroll to Notifications, and assign the SNS topics to Bounce and Complaint feedback. Save.

    Now you can subscribe an HTTPS endpoint (your WordPress site) to those topics to auto-process events. Most decent newsletter plugins have a webhook endpoint for this. If yours doesn’t, leave the SNS topics in place and check them manually weekly — better than nothing.

    Step 8 — Configure your newsletter plugin

    Open your newsletter plugin’s settings (in WordPress: Newsletter → Settings → Sender or Email Provider). Pick SMTP as the provider type and enter:

    • Host: email-smtp.[your-region].amazonaws.com
    • Port: 587
    • Encryption: TLS (also called STARTTLS)
    • Username: the SMTP username from Step 6
    • Password: the SMTP password from Step 6
    • From email: any address on your verified domain (e.g. [email protected])
    • From name: your newsletter’s name

    Save the settings.

    Step 9 — Send a test

    From the newsletter plugin, send a test email to your own address. If it arrives, you’re done. If it doesn’t:

    • Check the plugin’s send log for the error message.
    • If you see “535 Authentication failed”: SMTP credentials are wrong. Re-create in SES (Step 6) and re-paste.
    • If you see “Email address not verified”: you’re still in sandbox mode. Either wait for production approval, or verify your test recipient address in SES → Verified identities first.
    • If you see “Daily sending quota exceeded”: you’ve hit the 200/day sandbox limit. Same fix — wait for production approval.

    What it costs

    SES’s pay-as-you-go price is $0.10 per 1,000 emails sent. A newsletter sending about 43,000 emails a month (10,000 subscribers, one weekly issue) would cost about $4.30 a month at that rate. AWS also lists subscription-style tiers and, for new customers, up to $200 in AWS Free Tier credits that can be used on eligible services including SES (AWS SES pricing, checked 27 October 2026). Read that page for current prices.

    Common gotchas

    Sandbox limits are real. Don’t announce your launch before production access is approved. Apply the day you set SES up.

    DNS propagation is slow. If your records look right but the domain won’t verify, give it some time, since propagation depends on your DNS host.

    Don’t reuse the same SPF record. If you have one already (most domains do), edit it to include amazonses.com — don’t add a second TXT record. Multiple SPF records on the same domain break email auth entirely.

    Watch your bounce rate. AWS puts an account under review at a 5% bounce rate or a 0.1% complaint rate, and can pause sending at 10% bounces or 0.5% complaints (SES sending review FAQs, checked 27 October 2026). Process bounces. Remove invalid addresses.

    Warm up the IP. Going from zero to a very large send overnight is a bad idea. Ramp up gradually; for dedicated IPs, AWS’s standard automatic warm-up runs over 45 days (SES docs).

    Once you’re up

    That’s the whole setup. From here on, SES is the cheapest, most reliable workhorse in your stack — your newsletter plugin handles the editorial workflow, SES handles the sending, AWS bills you ten cents per thousand emails sent.

    If you’re running One Two Three Send on WordPress, the SMTP provider option above is built in — paste the SES credentials into Newsletter → Settings → Email Provider and you’re sending. Same plugin, same workflow, pay-as-you-go sending.

    Subscribe to One Two Three Send for more no-nonsense guides on the infrastructure behind running a profitable newsletter.

    Some links in this post are affiliate links — we earn a small commission if you sign up through them, at no cost to you. We only recommend tools we actually use.

  • Beehiiv’s referral program: how it works and when it backfires

    Beehiiv’s referral program: how it works and when it backfires

    Beehiiv‘s referral program is one of its flagship features—a built-in system that lets subscribers unlock rewards by forwarding your newsletter. It’s fast to set up, requires no integrations, and can drive genuine word-of-mouth growth.

    It can also quietly ruin your list quality if you don’t understand how it actually works.

    Here’s the mechanical breakdown, the non-obvious tradeoffs, and when to disable it entirely.

    How the referral system actually works

    When you enable the referral program in Beehiiv, every subscriber gets a unique referral link. That link appears automatically in your newsletter footer (or wherever you embed the merge tag). When someone signs up through that link, the original subscriber earns credit toward rewards you define—free downloads, paid tier access, physical products, whatever.

    Beehiiv tracks this server-side. No third-party pixels, no JavaScript. The platform knows who referred whom, even if the new subscriber uses a different device or email client.

    You configure reward milestones in the dashboard: 3 referrals unlocks a PDF, 10 gets a paid subscription comp, 25 gets a shirt. Beehiiv handles the tracking and sends automated emails when someone hits a tier. You fulfill the reward manually (or auto-comp paid subscriptions if you’re using Beehiiv’s native monetization).

    The feature is available on the Scale plan and above—$99/month if you’re under 10,000 subscribers, more as you grow. The Grow plan ($49/month) doesn’t include it.

    Where it works well

    Referral programs succeed when your content has shareability baked in—either because it solves urgent, specific problems (“how to fix X”) or because sharing it signals identity (“I’m the kind of person who reads this”).

    If your newsletter is tactical—SEO breakdowns, monetization teardowns, tool comparisons—referrals tend to flow naturally. Readers share because the content is immediately useful to peers in the same situation.

    If your newsletter is aspirational or community-driven—indie hacker diaries, niche hobby deep-dives—referrals work because sharing is a form of curation. “You should read this” becomes “you should be in this club.”

    The mechanic also works if your baseline engagement is already strong. If 30–40% of your list opens consistently and 5–8% click, a referral program amplifies what’s working. If your open rate is 18% and falling, referrals won’t save you—they’ll just add more cold contacts.

    Where it backfires

    The biggest risk: misaligned incentives. If your rewards are valuable enough to motivate sharing, they’re also valuable enough to motivate gaming. Subscribers will invite people who don’t care about your content—they care about the reward.

    I’ve seen lists add 400 subscribers in a week via referrals, only to watch open rates drop from 42% to 28% because half the new signups never intended to read. They clicked a friend’s link to help them hit a milestone, then ignored every send.

    Beehiiv doesn’t penalize you for this directly, but your email provider’s reputation system does. If new subscribers consistently don’t open, Gmail and Outlook start filtering you to spam—even for engaged readers.

    The second issue: reward fulfillment overhead. If you’re offering anything other than automated digital perks, you’re adding manual work every time someone hits a tier. Sending books, comping Stripe subscriptions, or giving one-on-one access doesn’t scale quietly. At 50 referrals a week, it’s a part-time job.

    Third: the program becomes the content. Once you launch referrals, a chunk of every send has to remind people the program exists, explain how it works, and show the leaderboard. That’s 80–150 words per issue that aren’t about your core topic. Some readers tune it out. Others resent the hustle.

    The non-obvious tip: test with time limits first

    Instead of launching a permanent referral program, run it as a 30-day sprint. Announce it, track it, fulfill rewards, then turn it off and watch what happens to your engagement metrics over the next month.

    If open rates stay flat or improve, and new subscribers engage at the same rate as your baseline, the program worked. If engagement drops or you see a spike in unsubscribes from recent signups, you attracted the wrong people.

    Beehiiv makes it easy to pause the program without losing historical referral data—just toggle it off in settings. The links stop working, the leaderboard disappears from your emails, and you can reactivate later if the economics make sense.

    One more thing: if you do run referrals, set a cap on reward tiers. I’ve seen operators offer “lifetime free access” at 100 referrals, then realize someone hit it by spamming Reddit. Build an upper limit—maybe 50 referrals max—so your highest reward doesn’t become a liability.

    Want to see how other operators are thinking about growth mechanics? Reply with what you’re testing—I read every response and the good ones become future pieces.

    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.

  • Monetising a product is easier than monetising attention

    Monetising a product is easier than monetising attention

    Most online operators start with the attention model: build an audience, then figure out how to extract money from their time. Newsletter sponsorships. Display ads. Affiliate links tucked into content. It feels like the natural path because it’s what you see working for others.

    But there’s a reason why operators who switch to product revenue—courses, memberships, software, templates, anything with a defined deliverable—rarely switch back. Product models scale differently, and for solo operators especially, they scale better.

    The attention tax compounds quietly

    When you monetise attention, every dollar requires continuous performance. A sponsorship pays once, then expires. Ad revenue tracks your traffic month to month. Affiliate income depends on someone else’s conversion funnel and commission structure.

    You’re not building equity. You’re renting out capacity.

    The math gets worse as you grow. To double sponsorship revenue, you need to double your audience or double your rate. Rates have ceilings—sponsors comparison-shop, and CPM benchmarks are public. So you chase growth, which means more content, more consistency pressure, more surface area to maintain.

    Then there’s the editorial drift. A reader-funded model points you toward what readers value. An attention model points you toward what scales: volume, virality, topics that pull search traffic even if they’re not what you’d choose to write about. Over time, the publication bends toward the model.

    Products let you decouple revenue from output

    Selling a product means you can earn the same amount while publishing less. A course that brings in $3,000 a month doesn’t care whether you published twice this week or not at all. A membership that delivers one deep tutorial every two weeks scales your income without scaling your content treadmill.

    This isn’t about working less—it’s about where you point your working hours. Instead of optimising for volume (another post, another sponsor, another traffic play), you optimise for conversion and retention. You spend time on the product, the onboarding flow, the member experience, the case studies that close sales.

    Products also let you serve smaller audiences profitably. A newsletter with 2,000 subscribers is almost impossible to monetise via sponsorships—your inventory is too small, your rates are too low, and sponsors want five-figure lists. But 2,000 subscribers with a $99 course and a 2% conversion rate is $4,000 in revenue from a single launch. Run that twice a year while growing the list, and you’ve got a real business.

    The chief objection: “I don’t have a product idea”

    This is almost never the real problem. If you’re writing regularly about a topic, you’re already teaching. The product is just the teaching formatted differently—less frequent, more structured, with a defined outcome.

    Start with what people already ask you to explain twice. That’s the course. Start with what you’d build for yourself if you had four hours. That’s the template or tool. Start with the workflow you’ve refined over two years that newcomers are still guessing at. That’s the membership.

    The other common block: “I don’t want to do a big launch.” Fine—don’t. Sell evergreen. Put a product page in your site footer. Mention it once per month in your newsletter. Let it convert passively while you write. You’ll be surprised how many people buy something useful without a countdown timer.

    Attention models aren’t wrong—they’re just expensive

    Sponsorships and ads work. They work especially well if you’re already at scale, if you have a team handling sales and production, or if your content velocity is naturally high and you’re not burning out.

    But for solo operators, the cost isn’t just time—it’s option value. Every hour spent chasing another sponsorship is an hour you didn’t spend building something that compounds. Every editorial decision bent toward traffic is a decision away from the tight, specific thing your best readers would pay for.

    If you’re still early, or if you’re hitting the ceiling on attention-based models and wondering what’s next, the move isn’t to optimize your sponsor deck. It’s to spend a month building the thing you’d sell if someone asked you to solve their problem directly.

    Then sell that.

    What’s one product you could ship in the next 30 days using what you already know? Reply and tell me—I read every response, and I’ll send you the follow-up guide on evergreen product funnels for solo operators.

  • When to add Beehiiv on top of your WordPress newsletter (and when not to)

    When to add Beehiiv on top of your WordPress newsletter (and when not to)

    If you already run a newsletter on WordPress, the most common question you’ll see in the operator forums isn’t “should I switch to Beehiiv“ — it’s “should I also be on Beehiiv?”. The framing matters, because Beehiiv stops looking like a competitor to a WordPress setup the moment you treat it as an acquisition channel rather than a publishing platform.

    We’ve been running both for the last several months. Here’s the honest decision framework we wish someone had handed us before we set the second one up.

    What Beehiiv actually adds (that WordPress can’t replicate)

    If you’re on WordPress, you already have the things that matter most — ownership of your subscriber list, deliverability control, your own domain, SEO that compounds on your archive, and pluggable customisation. None of those reasons go away when you add Beehiiv. So what does Beehiiv bring?

    The recommendations network. This is the single thing worth crossing the bridge for. Beehiiv’s discovery engine — both the in-post widget that suggests other newsletters to your readers, and the dedicated discovery network that surfaces your newsletter to people reading something adjacent — is the cheapest first-1,000-subscribers channel that currently exists. No WordPress plugin replicates it, including the cross-promotion plugins (we know — we’ve built one). The reason it works is network density, and you only get into that network by being on Beehiiv.

    Boosts. A pay-per-acquired-subscriber marketplace where you pay another newsletter operator to recommend you. The economics are deterministic in a way Meta and Google ads aren’t — you set a price per qualified sub, you only pay when one signs up. Boosts often outperform paid social on a CPA basis for newsletter-adjacent audiences.

    The ad network (optional revenue line). Beehiiv inserts sponsored ads into your posts and pays you a share. It’s not life-changing money at small list sizes, but it’s a real recurring revenue line with zero ongoing work — useful if you want monetisation without selling sponsorships yourself.

    That’s the value of adding Beehiiv. Now the cost.

    What it actually costs

    The plan tier you’ll end up on is somewhere in the Launch / Scale range — call it $0–$50/month depending on list size. That’s the obvious cost. The less obvious ones:

    • Time to keep two systems in sync. The bridge isn’t free. Every published issue needs to be cross-posted to Beehiiv if you want the web archive there to stay alive, and every signup on Beehiiv needs to find its way into your WordPress subscriber list (which is doable via their webhook system, but is one more thing to monitor).
    • Cognitive overhead. You’re now reading two analytics dashboards, debugging two send pipelines, and answering subscriber emails about which platform their account is on. For an individual operator this is real friction.
    • Audience confusion. If you mention your newsletter on social, which subscribe link do you give? If a reader asks “where can I read your archive?”, do you say the WordPress URL or the Beehiiv one? You’ll need a clear answer.
    • A small ongoing distraction. Beehiiv’s product is genuinely good, and once you’re inside it the upsell to use it as your primary platform (with their ad network, their paid tier infrastructure, their automation tools) is constant. Resist this if your WordPress side is working.

    When the addition is worth it

    The simple test: are you under 5,000 subscribers and actively trying to grow? Then yes, the recommendations network is probably the single highest-leverage thing you can add to your stack right now. The platform fee is negligible at that size, and the acquisition channel pays for itself within the first month if you’re publishing regularly.

    Two more specific cases where adding Beehiiv is a clear win:

    You publish about a topic that has natural cross-recommendation density on Beehiiv. Newsletter-about-newsletters, finance, sports, tech, lifestyle — these have hundreds of active publications on Beehiiv, which means the recommendations engine has something to work with. Hyper-niche B2B topics with three peer newsletters in the world won’t see much benefit.

    You want a passive revenue line that doesn’t require selling sponsorships. The Beehiiv ad network won’t replace your day job, but it’s real monthly money. For an operator who’d rather write than sell, it’s worth turning on.

    When the addition is wrong

    If your audience is past about 25,000 free subscribers or 2,500 paid, the platform fee starts to bite and the recommendations engine’s marginal value drops (your growth is mostly word-of-mouth and SEO at that scale anyway). Stick to your WordPress + Resend stack and put the saved fee toward content.

    If your newsletter is part of a larger product business — a course, an agency, an ebook funnel, a community — you don’t want subscriber records living in two places. The reconciliation overhead is more painful than the recommendations are valuable. Stay single-stack on WordPress.

    If you’ve been burnt by platform suspensions before, you have a real reason to be cautious. Beehiiv’s account-suspension issues are uncommon but documented — the difference vs WordPress is that on WordPress your worst case is a hosting bill, on Beehiiv it can be losing access to your audience without warning. The mitigation is to keep WordPress as the source of truth (which is what we do) so a Beehiiv suspension would cost you the discovery channel, not the list.

    How to set up the bridge cleanly

    If you decide to add Beehiiv, the configuration that gives you the most value with the least operational pain:

    1. Make WordPress the source of truth for subscribers. Every signup, wherever it lands, should end up in your WordPress subscriber table. Beehiiv’s API + webhooks let you wire this up — when someone signs up on Beehiiv, the webhook fires and creates the row on your side.
    2. Send the email from WordPress. You control deliverability, sender authentication, and per-issue customisation. Beehiiv’s send infrastructure is fine but you give up the levers.
    3. Use Beehiiv only as the acquisition layer and web archive. Recommendations engine on, Boosts marketplace on, ad network on if you want the revenue. But sending — the actual mail going out — runs through your WordPress stack.
    4. Cross-post each issue to Beehiiv as content. So the Beehiiv-side archive stays alive, the discovery network keeps surfacing your posts, and readers who arrive via Beehiiv have something to read. The Create Post API is on Beehiiv’s Enterprise tier today, so practically this means a copy-paste step into their editor or a manual import of the HTML.

    If you’re running One Two Three Send Pro on the WordPress side, the Beehiiv integration is built in — paste an API key and publication ID into Settings → Beehiiv, and the subscriber webhook + push side is wired up. The cross-post side is technically wired too, but it’ll only fire if you upgrade to Beehiiv Enterprise (their API restriction, not ours).

    The honest summary

    Adding Beehiiv to a WordPress newsletter is the right call for most operators between 0 and 5,000 subscribers who are actively trying to grow. It’s the wrong call once your acquisition is already working, or once your subscriber count is large enough that platform fees become meaningful.

    The pattern that works long-term is to treat the two platforms as different jobs — WordPress as your owned publishing layer, Beehiiv as a discovery channel that feeds it. That positioning protects you from the worst case on Beehiiv (account suspension, pricing changes) while still letting you use what’s genuinely best about it.

    If you’re starting from “I’m on WordPress, should I add Beehiiv too?” — the answer is probably yes, for now. Just be clear-eyed about which job each platform is doing for you, and don’t let the addition turn into a migration without you noticing.

    Some links in this post are affiliate links — we earn a small commission if you sign up through them, at no cost to you. We only recommend tools we actually use.

  • Everything that breaks the first time you take a Stripe payment for your newsletter

    Everything that breaks the first time you take a Stripe payment for your newsletter

    Stripe is the default payment processor for most online newsletter and creator businesses, and it’s worth understanding because most operators end up using it whether they planned to or not. Substack is built on Stripe. Beehiiv is built on Stripe. Kit, ConvertKit, Memberful, Lemon Squeezy — all Stripe. If you’ve ever sold a paid subscription, you’ve already met it, even if you didn’t see the dashboard.

    This post is for operators thinking about going beyond the platform — running their own paid tier on WordPress, selling a one-off product, or running a small agency that needs to invoice cleanly. We’ll cover what Stripe actually is, what it costs at newsletter scale, the four concepts that trip up most operators on first contact, the real pitfalls (activation, tax, chargebacks), and when not to use it.

    What Stripe is, in one paragraph

    Stripe is a payment infrastructure company that handles the messy middle between your website and the card networks (Visa, Mastercard, Amex). When a subscriber clicks “Subscribe $10/month” on your newsletter, Stripe collects the card, runs it through fraud checks, charges it via the bank, deals with international currency conversion, retries failed cards on a schedule, sends the customer a receipt, and shows up in your bank account a few business days later as a deposit. You never touch the card data. You never run a banking integration. You pay them roughly 2.9% + 30¢ per transaction and they handle the rest.

    What makes Stripe different from PayPal or Square is that it’s developer-first. The API is excellent, the dashboard is good (not great, but good), and it’s the one platform where every newsletter tool, course platform, and SaaS app can integrate easily. That ecosystem effect is the moat.

    What it actually costs at newsletter scale

    Stripe’s standard rate is 2.9% + 30¢ for US cards and 3.4% + 30¢ for international cards. Real averages for US-based newsletter operators end up around 2.9–3.4% all-in.

    Annual revenueStripe fees (approx)What that buys
    $10,000$300~440 charges processed, customer portal, dunning, receipts
    $50,000$1,500Same plus fraud detection on autopilot
    $250,000$7,500Volume discount eligibility (negotiable above $1M)

    For comparison, building anything close to this from scratch — fraud detection, retry logic, customer-facing portal, tax handling — costs more than the fees. The Stripe rate is the cheapest part of the whole stack. Operators who agonise over the 2.9% are usually missing what they’d spend rebuilding it.

    The four use cases for a newsletter operator

    1. Paid newsletter subscriptions

    The big one. Monthly and annual recurring subscriptions, typically $5–15/month or $50–150/year. Three patterns work for newsletters:

    • Monthly + annual + founding member. Standard Substack split. Annual gets a 17% discount. Founding member is 10x the annual price for readers who want to support the publication beyond the standard tier — surprisingly common at the right audience size.
    • Annual only. Eliminates the worst-converting tier (monthly), reduces churn, simplifies cashflow forecasting. Used by operators who want a smaller list of higher-LTV readers.
    • Pay what you want above a floor. Stripe supports this via Custom Pricing on Checkout. $5/month minimum, customer enters whatever they want above. Niche but works for community-driven newsletters.

    2. One-off products

    Ebooks, course access, sponsored slots, archive bundles. One-off charges with optional digital delivery via Stripe’s Payment Links (zero coding, drag-and-drop). For a newsletter operator selling a $29 ebook, Payment Links is the fastest route — generate a link, paste in your newsletter, done.

    3. Tipping / donations

    Some readers want to support a free newsletter without subscribing. Set up a Stripe-hosted Payment Link with custom amount enabled. One-line install in your footer: “Tip the writer →”. Closer to a Patreon model but without the platform tax.

    4. Agency / consulting invoices

    If you run an agency alongside the newsletter, Stripe Invoices replaces every invoicing tool you’ve used. Send a hosted invoice link. Client clicks, pays, you get notified, accounting reconciles via the Stripe export. Free if the invoice gets paid by card (you pay the standard processing fee), free if paid by ACH.

    The four concepts that trip up newsletter operators

    These are the four things that, in our experience, every operator runs into in their first month and doesn’t fully understand until month three.

    Checkout vs Payment Links vs Pricing Tables

    Three Stripe products that look similar but solve different problems:

    • Checkout — a Stripe-hosted page you redirect to. Best for paid subscriptions and most one-off products. Two lines of code.
    • Payment Links — a single static URL Stripe generates from the dashboard. No code at all. Best for tipping, ebooks, anything where you don’t need a custom checkout flow.
    • Pricing Table — an embedded HTML block (a couple of lines of code) that shows multiple tiers side by side. Best for subscription-with-tier-comparison pages.

    Most operators pick the wrong one because the docs make Checkout sound default. For a single product or single tier, use a Payment Link. For “monthly vs annual vs founding member” comparison, use a Pricing Table. Use Checkout when you actually need fields the others don’t support (custom metadata, B2B tax IDs, complex flows).

    Webhooks

    Webhooks are HTTP callbacks Stripe fires when something happens in your account (payment succeeded, subscription cancelled, card failed). Without webhooks, your site doesn’t know when someone pays or unsubscribes — you have to poll the Stripe API or check the dashboard manually.

    The mistake operators make: skipping webhooks because the platform “seems to work without them.” Then a subscriber cancels, Stripe stops billing, but your site keeps showing them as a paid subscriber for weeks. Or a card fails, Stripe stops collection, but your welcome email keeps going to a churned customer. Set up webhooks on day one. The single endpoint your platform exposes (e.g. /wp-json/otts-pro/v1/stripe/webhook) is the difference between a working paid-newsletter system and a broken one.

    Customer Portal

    The Customer Portal is a Stripe-hosted page where your subscribers can manage their own subscription — change card, switch from monthly to annual, cancel, view invoices. It’s free, takes about an hour to enable, and prevents 100% of “how do I cancel” support emails.

    If you don’t enable it, every cancellation request becomes a manual ticket where you log into the Stripe dashboard, find the customer, click Cancel, and email them confirmation. At 100 paid subscribers this happens once a week. At 1,000 it happens daily. Enable the Customer Portal on day one and link to it from your welcome email.

    Smart Retries / dunning

    Stripe’s “Smart Retries” feature retries failed card charges on a schedule (3 days later, 5 days later, 7 days later). Stripe also handles the customer-facing “your card failed, please update it” emails. This is dunning, and it recovers something like 30–40% of payments that would otherwise be lost.

    It’s not on by default for every account. Go to the Billing settings → Subscription and emails → enable both Smart Retries and the failed-payment emails. Most operators discover this exists after watching their MRR drop unexpectedly because expired cards weren’t being recovered.

    Setup, in the order to actually do it

    1. Create a Stripe account at dashboard.stripe.com/register. The signup is fast. Use your business email, not personal.
    2. Activate the account. Stripe asks for business details — legal name, registered address, tax ID, bank account, ID document for the responsible person. Most US accounts activate within an hour; business-entity verification can take 1–2 business days. Do this before you launch your paid tier; activation delays after you’ve taken pre-orders are stressful.
    3. Set up the bank account for payouts. Daily payouts are the default. If your bank charges per deposit, switch to weekly.
    4. Enable the Customer Portal in Settings → Billing → Customer Portal. Configure what subscribers can change themselves (recommended: cancel, update card, change plan, download invoices).
    5. Set up products + prices in the Stripe dashboard, not in code. Define a “Newsletter Subscription” product with monthly and annual prices. Price IDs (price_xxx) are what your platform references.
    6. Set up webhooks pointing at your platform’s webhook endpoint. Subscribe to at minimum: checkout.session.completed, customer.subscription.updated, customer.subscription.deleted, invoice.payment_failed.
    7. Configure tax handling via Stripe Tax. Turn it on the moment you sell internationally; for US-only sellers you can defer until you cross state-level economic nexus (commonly $100k in revenue or 200 transactions in a single state).
    8. Test in test mode before going live. Stripe provides test card numbers (4242 4242 4242 4242 always succeeds, 4000 0000 0000 0002 always declines). Run your full subscribe → cancel → resubscribe flow before flipping the switch.

    Pitfalls, in the order operators usually hit them

    1. The activation delay catches people before launch. You announce the paid tier on Twitter, send your announcement newsletter, and discover the Stripe account isn’t activated yet. New subscribers see “Payments are temporarily unavailable.” Activate the account a week before you intend to take payments.

    2. Tax registration for international and out-of-state sales. The day you take a payment from an EU resident, you’ve technically created a VAT obligation in their country once you cross the threshold. Domestically, US sellers cross state-level sales-tax obligations as soon as you trigger economic nexus (commonly $100k in revenue or 200 transactions per state). Stripe Tax handles the calculation and remittance for both — turn it on. Don’t try to handle this manually.

    3. Currency conversion losses. If your prices are in $ but a UK or EU customer pays in £ or €, Stripe converts at a slightly worse rate than wholesale. Over a year of $10k in international payments, this is roughly $250 in extra fees. For most operators it’s negligible. For high-volume operators with a heavily international audience, multi-currency pricing (separate $, £, € prices for the same tier) is worth the setup time.

    4. Chargebacks. A subscriber forgets they signed up, sees a charge on their statement, calls their bank, and disputes it. Stripe charges $15 per dispute regardless of outcome, plus the original charge gets reversed. The fix: clear billing descriptors (your statement descriptor should be your newsletter name, not “STRIPE PAYMENT”), explicit confirmation emails on first charge, and a visible Customer Portal so cancellations don’t become disputes.

    5. The “trial that never converts.” If you offer a 14-day free trial, plan for 30–50% of trials to never enter a card. Stripe’s Trial requires a card upfront by default; consider whether your business model can handle the conversion drop from card-required vs the support overhead of cardless trials.

    6. Refund policy ambiguity. Newsletter operators often forget they need a refund policy. Stripe’s terms require it. Most newsletters use “no refunds, cancel anytime to stop future charges” — fine, just put it on the pricing page.

    Long-term maintenance

    Monthly: review the Stripe dashboard’s reporting — MRR, churn, failed payments, top products. Stripe’s built-in reporting is enough for most operators; only graduate to ChartMogul or similar if you’re managing multiple products with complex cohort analysis.

    Quarterly: reconcile Stripe payouts with your accounting software. Most accounting tools (QuickBooks, Xero, Wave, FreshBooks) have direct Stripe integrations. Check that fees are categorised correctly and that you’re capturing the right amount as taxable income (revenue, not net of fees).

    Annually: review your dunning configuration. The default Stripe retry schedule is good but not optimal — if your average customer’s card expires every 36 months and you’re seeing more declines than expected, lengthen the retry window. Also review tax thresholds — if you’ve crossed a new sales-tax or VAT registration threshold, Stripe Tax will surface this but you need to act.

    When something breaks: Stripe’s status page (status.stripe.com) is reliable. If checkout’s down, check there before debugging your own code. Outages are rare but they happen.

    When Stripe is the wrong choice

    If you publish entirely on Substack or Beehiiv, you’re already on Stripe — the platform handles the integration and you don’t need to manage it directly. The platform takes 10% of your revenue for that convenience. That’s a fair trade until you outgrow the platform’s limitations.

    If your audience is heavily in countries where Stripe lacks strong local payment methods (most of South America, parts of Africa, India to a lesser extent), look at regional alternatives — Razorpay in India, Mercado Pago in Latin America. Or use Stripe with regional payment-method enabled (iDEAL, Bancontact, etc.) and accept that some markets will be harder to convert.

    If you’re selling primarily B2B with complex invoicing requirements (purchase orders, net-60 terms, custom contracts), Stripe Invoices is fine but accounting-software-native invoicing (QuickBooks, Xero) often integrates better with the rest of the B2B workflow.

    For everyone else, Stripe is the default — and like the other infrastructure decisions in this stack, that’s the highest compliment infrastructure can earn.

    Some links in this post are affiliate links — we earn a small commission if you sign up through them, at no cost to you. We only recommend tools we actually use.

  • ConvertKit’s visual automation builder vs. classic rules: which to use

    ConvertKit’s visual automation builder vs. classic rules: which to use

    ConvertKit gives you two ways to automate what happens after someone subscribes, clicks a link, or buys a product: the visual automation builder and the older rules-based system. They look different, they feel different, and they solve different problems.

    If you’ve ever clicked into Automations and felt paralyzed by the blank canvas—or built a simple rule and wondered why everyone raves about visual workflows—you’re not alone. The platform doesn’t make it obvious when to use which, and picking wrong costs you time or flexibility down the road.

    Here’s how to decide.

    What each one actually does

    The visual automation builder is the flowchart interface. You drag triggers, conditions, actions, and delays onto a canvas. It handles multi-step sequences, conditional logic, tagging, field updates, and webhook calls. You can see the whole journey at a glance.

    The rules system is text-based and hidden under Settings → Rules. Each rule is a single if-this-then-that statement: “If someone subscribes to Form A, tag them with Lead Magnet B.” No branching, no delays, no visual feedback.

    Both run in the background. Both fire instantly. But they’re built for different levels of complexity.

    When to use the visual builder

    Use the visual automation builder when your subscriber journey has more than one step, or when the next action depends on what someone does (or doesn’t do).

    Examples where it shines:

    • Onboarding sequences with conditional branches based on link clicks or form submissions
    • Lead nurture flows that tag people differently depending on which resource they download
    • Product launch sequences that change behavior based on purchase status
    • Re-engagement campaigns triggered by inactivity, with different paths for openers vs. non-openers

    The visual builder also makes debugging easier. You can see where subscribers are in the flow, spot bottlenecks, and identify where people drop off. If you’re running anything more complex than a single tag or email, the canvas pays for itself in clarity.

    One non-obvious tip: use the Wait Until condition instead of fixed delays when timing matters. Instead of “wait 3 days,” set “wait until tag is added” or “wait until custom field changes.” It keeps automations responsive to real behavior, not arbitrary calendars.

    When rules are faster (and safer)

    Rules are better when you need a single, permanent action that should never change based on subscriber behavior.

    Use rules for:

    • Auto-tagging every new subscriber to a specific form
    • Assigning a custom field (like “source” or “signup date”) the moment someone joins
    • Moving subscribers between sequences when they complete a purchase
    • Unsubscribing people from a broadcast tag when they click an opt-out link

    Rules execute faster because there’s no flowchart to traverse. They’re also harder to accidentally break—there’s no risk of pausing the wrong branch or deleting a connector by mistake.

    The biggest advantage: rules don’t require you to “start” subscribers. Visual automations only affect people who enter after you publish. Rules apply to everyone who meets the condition, past or future, unless you explicitly turn them off.

    The hybrid approach most operators miss

    You don’t have to choose. The most reliable setups use rules for foundational tagging and field assignment, then use visual automations for behavior-based sequences.

    Example: a rule tags every new subscriber with their lead magnet name. A visual automation checks that tag, then sends a welcome sequence tailored to what they downloaded. The rule ensures no one slips through; the automation handles nuance.

    This also future-proofs your setup. If you later want to add a branch for people who clicked a specific link, you’re editing an automation—not rewriting a dozen rules.

    One warning: don’t duplicate logic across both systems. If a rule and an automation both try to add the same tag based on the same trigger, you’ll get double-fires and confusing analytics. Pick one place for each action.

    Where most people get stuck

    The most common mistake is building a visual automation when a rule would’ve been cleaner—usually because the visual builder feels more “powerful.”

    If your automation is a straight line with no branches, no delays, and no conditions, it’s probably a rule. Save the canvas for when you actually need decision trees.

    The second mistake: not testing both. ConvertKit lets you preview automations, but it doesn’t simulate real subscriber movement. Before you publish, manually trigger the flow with a test subscriber and confirm every tag, email, and field change fires as expected.

    Want more breakdowns like this? One Two Three Send covers the tools and tactics solo operators actually use—no fluff, no affiliate spam. Subscribe for one article like this every week.

  • Reddit’s new search deal with OpenAI: what it means for your traffic

    Reddit’s new search deal with OpenAI: what it means for your traffic

    Reddit announced an expanded partnership with OpenAI in early May 2026, following its earlier Google search deal. The short version: OpenAI’s SearchGPT and ChatGPT will now surface Reddit content directly in conversational search results, with full access to Reddit’s Data API.

    For solo operators and small teams relying on organic traffic, this matters more than it looks.

    What actually changed

    Reddit already had a search licensing deal with Google, signed in February 2024 for a reported $60 million annually. That deal gave Google privileged access to Reddit’s real-time content and user discussions, which is why you’ve seen more Reddit threads dominating Google results over the past year.

    The OpenAI deal extends similar access to ChatGPT’s search features. When users ask questions in SearchGPT or use ChatGPT’s web browsing mode, Reddit threads can now appear as cited sources with direct attribution and links back to the original discussion.

    Reddit’s pitch: users get more authentic, community-vetted answers. OpenAI’s pitch: better, more human training data and real-time context. The reality for operators: another platform where Reddit owns the discovery layer for informational queries.

    Why this shifts your traffic strategy

    If you’ve been building SEO content around informational queries—how-tos, product comparisons, tool recommendations—you’re now competing with Reddit threads in two major search ecosystems: Google and OpenAI’s ChatGPT search.

    Reddit threads have structural advantages you can’t replicate on a blog:

    • Multiple perspectives in a single URL
    • Recency signals from ongoing discussion
    • Social proof baked into upvotes and comment depth
    • Domain authority that dwarfs most indie sites

    For queries like “best email platform for small newsletter” or “how to migrate WordPress hosts without downtime,” a well-populated Reddit thread will often outrank a solo-authored blog post—especially in AI-mediated search, where the model prioritizes diverse, conversational input.

    This doesn’t mean blog content is dead. It means the type of content that wins organic discovery is narrowing. Reddit owns broad informational queries. You need to own something else.

    Where to focus instead

    Depth over breadth. Write the piece Reddit can’t: the 2,500-word deep-dive with original data, screenshots from your own workflow, or a technical walkthrough that requires sustained focus. Reddit threads excel at breadth; they’re weak on single-author depth and narrative control.

    Named, specific problems. Target long-tail queries tied to specific tools, error messages, or edge cases. “ConvertKit automation not triggering after Zapier webhook” will get less Reddit competition than “best newsletter automation tools.”

    Proprietary insight. If you run a SaaS, publish product comparisons that include your own internal data. If you operate a newsletter, publish revenue breakdowns or sponsor outreach templates. Reddit can discuss these topics, but it can’t create the artifacts.

    Be on Reddit. If discovery is shifting to Reddit threads, show up there. Answer questions in relevant subreddits. Link to your deep content when it’s genuinely useful. Build your name as a credible voice in the thread, not just on your own domain. When ChatGPT or Google surfaces that thread, your username travels with it.

    What this means for content ROI

    Expect longer payback periods on traditional SEO content. A blog post that might have ranked on page one in six months could now take nine or twelve—or never rank at all if Reddit owns the SERP.

    That changes the math on content investment. If you’re a solo operator publishing twice a week to chase Google traffic, you might get better return from one deep piece per month plus active participation in two or three subreddits.

    It also changes attribution. Traffic that used to come from “Google / organic” might now come from “reddit.com / referral” because a user found your link in a thread cited by ChatGPT. Your analytics will show Reddit as the source, but the real discovery happened in an AI search interface. Track referral paths more carefully.

    One thing to watch: Reddit’s API pricing. Both Google and OpenAI are paying for access. If Reddit sees this as a major revenue stream, expect continued prioritization in both search ecosystems—and continued downranking of independent blogs that compete for the same queries.

    If you’re building a content-driven business in 2026, assume Reddit is now part of your search competition. Adjust your content strategy, your distribution mix, and your expectations accordingly.

    Want operator-focused breakdowns like this in your inbox? Subscribe to One Two Three Send—no fluff, just the tools and tactics that matter.

  • ChatGPT Canvas: when to write in the sidebar vs. the chat window

    ChatGPT Canvas: when to write in the sidebar vs. the chat window

    ChatGPT’s Canvas feature rolled out quietly in late 2024, and most solo operators still treat it like a slightly fancier text box. That’s a mistake. Canvas fundamentally changes how you should interact with the model when you’re drafting, editing, or iterating on long-form content.

    If you’re still pasting drafts back and forth between Google Docs and the chat window, or if you’ve tried Canvas once and dismissed it because “the chat works fine,” this is worth understanding properly.

    What Canvas actually does

    Canvas opens a split-pane interface. Your prompt stays in the left chat window. The output appears in a dedicated editing pane on the right. You can highlight sections, ask ChatGPT to rewrite specific paragraphs, adjust tone, or insert new sections—all without re-generating the entire document.

    The key difference: Canvas treats your draft as a persistent artifact you refine, not a disposable output you replace. The chat window treats every response as a new answer. Canvas treats it as an evolving document.

    That distinction matters when you’re writing newsletter drafts, landing pages, email sequences, or long-form articles. It matters less when you’re asking one-off questions or generating lists.

    When to use Canvas

    Use Canvas when you’re iterating on structure, not just tweaking words.

    If you’re drafting a 1,200-word article and you realize the second section is too technical, you don’t want ChatGPT to regenerate the whole piece. You want to highlight paragraphs 4–7 and say “make this less jargon-heavy.” Canvas lets you do that. The chat window forces you to either accept the entire rewrite or manually splice fragments together.

    Use Canvas when you need version control inside the same session.

    Canvas saves previous versions as you edit. If ChatGPT rewrites your intro and you hate it, you can roll back without losing the rest of the draft. In the chat window, once a response scrolls up, it’s effectively gone unless you scroll back and copy-paste.

    Use Canvas when you’re working on something longer than 400 words.

    Short outputs—social captions, subject lines, single-paragraph rewrites—don’t benefit much from Canvas. The overhead of opening the pane isn’t worth it. But once you’re past 400–500 words, the ability to target edits and preserve context becomes a significant time-saver.

    When to stick with the chat window

    Use the chat window for exploratory prompts.

    If you’re brainstorming headline ideas, asking ChatGPT to explain a concept, or generating a list of content angles, the chat window is faster. Canvas adds friction when you don’t need persistence.

    Use the chat window for quick rewrites or single-use outputs.

    Need three variations of a CTA? Want to rewrite one sentence five different ways? The chat window is built for rapid, disposable iteration. Canvas is built for refinement over multiple rounds.

    Use the chat window when you’re chaining prompts that don’t need a shared artifact.

    If you’re asking ChatGPT to analyze your traffic data, then draft an email, then suggest three A/B test ideas, those are separate tasks. Canvas doesn’t help. The chat window’s linear thread is easier to follow.

    The non-obvious trick: use Canvas as a scratch pad, not a final draft tool

    Here’s the workflow most operators miss: don’t start in Canvas. Start in the chat window, then move to Canvas once you have a rough structure worth refining.

    Prompt ChatGPT in the chat window with your outline, audience, and key points. Let it generate a rough first draft. If the structure is close, then open Canvas and paste it in. Now you can refine section by section without regenerating the whole thing every time you tweak the intro.

    This two-stage approach—chat for generation, Canvas for refinement—saves 20–30 minutes on any piece over 800 words. You’re not fighting the tool’s defaults. You’re using each interface for what it’s good at.

    One more thing: Canvas has a tone slider and a length adjuster in the toolbar. Most people ignore them. Don’t. If you highlight a paragraph and drag the tone slider toward “casual,” ChatGPT rewrites just that section without you writing a new prompt. It’s faster than typing “make this less formal” every time.

    When this matters for your business

    If you’re writing one newsletter a week, this probably saves you 15–20 minutes per issue. If you’re drafting landing pages, email sequences, or long-form SEO content, it’s the difference between spending two hours on a draft and spending three.

    Canvas isn’t a mandatory feature. But if you’re still copying and pasting between tools, or if you’re regenerating entire drafts because one paragraph didn’t land, you’re working harder than you need to.

    Try this: Next time you draft anything over 600 words with ChatGPT, start in the chat window and move to Canvas after the first output. Refine in Canvas. See if it’s faster. If it’s not, go back to the chat window. But most operators who test this properly don’t go back.

    If you found this useful, reply and let me know what AI tool you want broken down next. I read every response.

  • WordPress auto-updates: which ones to enable, which to avoid

    WordPress auto-updates: which ones to enable, which to avoid

    WordPress has offered automatic updates since 2013, but most operators still treat the feature like a binary choice: all on or all off. That’s a mistake. The auto-update system has four distinct layers, and each one carries different risk and reward.

    Here’s how to configure them without waking up to a broken site.

    Core updates: three tiers, three strategies

    WordPress core has three update types, and the defaults are smarter than most people realize.

    Minor releases (e.g., 6.4.1 to 6.4.2) auto-update by default. These are security and critical bug fixes. Leave this enabled. The risk of a minor version breaking your site is vanishingly small compared to the risk of running unpatched software. In eight years of managing client sites, I’ve seen exactly one minor update cause a conflict—and it was with a plugin that was already deprecated.

    Major releases (e.g., 6.4 to 6.5) are disabled by default, and you should keep them that way unless you’re running a very simple site with minimal plugins. Major versions introduce new features and can break theme or plugin compatibility. Schedule these manually, ideally in a staging environment first.

    Development and beta builds are off by default. Never enable these on a production site. They’re for testing only.

    You can control core auto-updates in Dashboard → Updates → Advanced Options, or via the WP_AUTO_UPDATE_CORE constant in wp-config.php.

    Plugin auto-updates: the risk matrix

    Since WordPress 5.5, you can toggle auto-updates per plugin. This is where most operators get it wrong—they either enable everything or nothing.

    The correct approach is risk-based. Enable auto-updates for:

    • Security plugins (Wordfence, Solid Security, etc.). Delaying a security patch is worse than the small chance of a bad update.
    • Actively maintained utilities with narrow scope—contact forms, analytics snippets, small performance helpers. If a plugin does one thing and is updated frequently, auto-update is usually safe.
    • Plugins from established vendors with good release practices. WooCommerce, Yoast, Jetpack, and similar have staged rollouts and rarely ship breaking changes in patches.

    Disable auto-updates for:

    • Page builders and theme frameworks. Elementor, Divi, Advanced Custom Fields, WPBakery—anything that touches your front-end rendering or content structure. Updates here can cascade across hundreds of pages.
    • Plugins you’ve customized via hooks or filters. Auto-updates will overwrite nothing, but new versions may deprecate the functions you’re relying on.
    • Anything that hasn’t been updated in over a year. If the developer isn’t actively maintaining it, the next update could be panicked, untested, or abandoned entirely.

    On a typical content site, I’ll have auto-updates enabled for about 60% of installed plugins. On a membership site with custom checkout flows, closer to 30%.

    Theme auto-updates: almost never

    Themes control your entire front-end. A bad update can break layouts, remove custom CSS, or interfere with child theme overrides.

    Disable auto-updates for your active theme. Period. The only exception: you’re using a bare-bones starter theme (like GeneratePress or Astra) with zero customizations, and all your design work lives in a child theme or site-specific plugin.

    You can leave auto-updates enabled for inactive themes if you want to keep them patched for security, but the smarter move is just to delete any theme you’re not using. An inactive theme is still executable code that can be exploited.

    Translation auto-updates: safe to enable

    Translation files auto-update by default, and there’s no reason to turn this off. They’re low-risk, non-executable, and keeping them current improves localization accuracy. Leave it alone.

    What happens when an auto-update fails

    WordPress has a rollback mechanism. If a plugin or theme update triggers a fatal error during activation, the system will attempt to restore the previous version and send you an email with the error log.

    This works—most of the time. But it’s not a substitute for backups. If you’re enabling auto-updates for anything beyond minor core releases, you need automated daily backups with off-site storage. Most managed WordPress hosts (including BigScoots) include this. If you’re on unmanaged hosting, use UpdraftPlus, BlogVault, or a server-level solution.

    The notification problem

    Auto-updates are only useful if you know they happened. WordPress sends email notifications for core updates and failed plugin updates, but successful plugin updates are silent by default unless you enable the auto_plugin_update_send_email filter.

    Add this to your theme’s functions.php or a site-specific plugin:

    add_filter( 'auto_plugin_update_send_email', '__return_true' );

    Now you’ll get an email every time a plugin auto-updates. If you’re running multiple sites, route these to a dedicated email address or a Slack channel via Zapier.

    One non-obvious tip: staging auto-updates

    If you’re using a host with staging environments, configure your staging site to auto-update everything—core, plugins, themes. Then schedule a weekly automated check (via uptime monitor or a simple cron job) to verify the staging site still loads.

    If staging breaks, you’ll know before the same update hits production. If it doesn’t, you can manually push the updates live with confidence. This is the closest you’ll get to zero-touch maintenance without the risk.

    Got a WordPress setup question we should cover? Reply to this email—we read every one.

    Some links in this post are affiliate links — we earn a small commission if you sign up through them, at no cost to you. We only recommend tools we actually use.

  • How to Run Three Facebook Pages Without Touching Facebook

    How to Run Three Facebook Pages Without Touching Facebook

    The single highest-leverage change most newsletter operators can make to their Facebook strategy isn’t writing better posts. It’s not switching topics. It’s not hiring a designer. It’s not posting from inside Facebook.

    Posting directly from Facebook means: open Facebook, get pulled into the algorithm for 20 minutes, write something less considered than you intended, hit Post, repeat tomorrow. The post itself is fine. What kills the operation is everything around it — the context-switching, the inconsistency, the days you forget, the algorithmic detour every time you log in to do five minutes of work.

    A scheduler fixes that by letting you write a month of content in one sitting and never log into Facebook again for posting. We use Publer for this across the Love-To-Visit network. Here’s why, how, and what to expect.

    Disclosure: the Publer link in this post is an affiliate link. If you sign up through it we may earn a referral fee. We use Publer ourselves — we wouldn’t be writing about it if we didn’t.

    Why a scheduler matters more than the content

    Most operators we talk to think their Facebook problem is the content. It almost never is. The pattern looks like this:

    • Week one: post every day, traffic spikes, motivated.
    • Week two: post most days, the spike fades, energy drops.
    • Week three: post twice. The Page goes quiet. The algorithm notices.
    • Week four: post once, “I should really get back into this.”
    • Week eight: dormant Page. Re-energise plan. Same cycle.

    This isn’t a content problem — the posts in week one were the same quality as the ones that never got written in week four. It’s a cadence problem. Facebook’s algorithm rewards consistency. Erratic posting halves your reach for the same content.

    A scheduler attacks this at the root. You don’t post on Tuesday because you remember — you post on Tuesday because Tuesday’s slot was filled three weeks ago. The cadence is no longer dependent on whether you have energy that morning.

    • Content batches got better — writing 12 posts in one sitting forces you to think about variety and themes. Writing one post a day, you reach for whatever’s top-of-mind.
    • Time spent on Facebook dropped from ~2 hrs/week to ~30 min/week. The 30 minutes is the batch session; the rest is replies. No more pulled-into-the-feed detours.

    Why we picked Publer

    There are roughly six serious schedulers in this category — Buffer, Hootsuite, Later, Loomly, SocialBee, and Publer. Here’s the case for Publer specifically:

    • Free tier is actually usable. Buffer’s free tier capped at 10 scheduled posts per Page when we last checked. Hootsuite scrapped its free plan entirely. Publer’s free tier is 5 social accounts and unlimited scheduled posts — enough to run a small Page for free, forever, if you don’t need the AI assistant or analytics.
    • Native Facebook coloured-background text posts. Most schedulers can’t post these — you get a regular text post instead. Publer supports the full set of Facebook background presets.
    • First-comment automation. Drop a link in the first comment and Facebook stops penalising the main-post reach. Publer has a dedicated First Comment field. Hootsuite makes you write a follow-up reminder; Buffer doesn’t support it at all on the free plan.
    • Bulk CSV upload. Spreadsheet of posts → 50 scheduled posts in one minute. Critical when you batch-write.
    • Recycle queue. Evergreen posts can be set to auto-recycle every N days, which keeps a small Page active even between fresh content batches.
    • The pricing. The Pro plan is $12-15/month for 10 social accounts and the AI assistant; that’s roughly half what Hootsuite charges for similar features.

    Where Publer falls short: the analytics view is decent but not as deep as Sprout Social or even Buffer’s paid tier. If you’re doing serious agency-level reporting across 50+ accounts, it’s not the right tool. For an operator running 1–10 Pages, it’s the best fit.

    The 20-minute setup

    1. Sign up. Go to Publer, free plan is fine to start. Email + password, no credit card required.
    2. Connect your Facebook Page. In Publer’s dashboard: Add Account → Facebook → Connect → pick the Page. Publer requests pages_manage_posts, pages_read_engagement, and a few others — the same scopes a custom Facebook App would need.
    3. Set your weekly schedule. Publer’s Calendar view lets you pick the times you want posts to fire each day. Three a day at 8am / 1pm / 7pm is a reasonable starting point for a brand Page.
    4. Write your first batch. Compose 5-10 posts in the Library: text, image, link, and (this is the trick) at least 2 coloured-background text posts. Mix the formats — the algorithm penalises Pages that look formulaic.
    5. Hit Schedule. Posts drop into the next open slots. Calendar view shows the whole week at a glance. Edit / move / delete is drag-and-drop.
    6. Set up first-comment for your link posts. When the post body has a link, Facebook tends to suppress reach. Move the link into the First Comment field instead and put the hook in the body. Publer fires the comment automatically when the post lands.

    Total time: roughly 20 minutes the first time, 10 minutes for each subsequent batch. A month of content for a single Page in 30 minutes is realistic once you have your post-format library.

    What batching does that daily posting can’t

    The behaviour change you get from a scheduler isn’t just convenience — it’s a different writing pattern. Daily-posting forces you into reactive content (whatever’s interesting today). Batch-posting forces you into themed content (what does this Page stand for, and what does a month of it look like?).

    For our travel Pages, a month of content typically breaks down like:

    • 40% destination spotlights — one place per post, sensory and specific.
    • 20% practical tips — “what nobody told us about renting a car in X”.
    • 15% historical / cultural facts — the hook story. These travel best.
    • 15% recurring formats — weekly photo prompt, Friday “where would you go this weekend” question.
    • 10% link drops — back to the website / newsletter, with the link in the first comment.

    You can’t think this clearly about your mix when you’re writing one post at 7am. Batching forces it.

    Honest expectations for the first 30 days

    The scheduler isn’t a growth lever. It’s a consistency lever. You’ll see:

    • Posts shipping every day, with zero willpower spent. This is the biggest win. Two months of consistent posting is worth more than two viral posts.
    • Engagement starts to compound by month two. The first month you’re rebuilding the algorithmic relationship with your audience. Don’t judge results until day 60.
    • You’ll discover formats that work. One coloured-background text post about an obscure local custom outperformed a beautiful destination photo for us by 5x. You only learn this by shipping enough volume to see signal.

    What you won’t see: 10x growth, viral posts, a sudden flood of new newsletter subscribers. Schedulers fix the operations problem. The content problem is still yours. They just stop you from hiding behind “I didn’t have time to post” when the real issue is that the Page wasn’t a priority.

    The simplest test you can run this week

    1. Sign up for Publer’s free plan (no card required).
    2. Connect one Facebook Page.
    3. Block 30 minutes on a Saturday and write 14 posts — two per day for a week.
    4. Schedule them across the next 7 days at the times you’d actually post manually.
    5. Don’t open Facebook all week. Reply only to comments via Publer’s Inbox view (it pipes Facebook DMs and post comments into one screen).
    6. Compare reach + engagement on those 14 posts to the previous 14 you posted manually.

    If the scheduled batch outperforms the manual batch, you’ve found your new permanent workflow. If it doesn’t, the issue was the content all along — in which case at least you’ve reclaimed two hours a week.

    Either way, Publer’s free plan costs nothing to test. The 30-minute batch is the cheapest experiment you can run on your Facebook strategy.

    Try it: publer.com

Powered by CookieAdmin