One Two Three Send

Author: onetwothreeadmin

  • Stop hoarding traffic sources—concentrate on two

    Stop hoarding traffic sources—concentrate on two

    Stop hoarding traffic sources—concentrate on two
    Photo: Spatms via Wikimedia Commons (CC BY-SA 4.0)

    The typical solo operator’s traffic mix looks like this: a little organic social, some SEO, sporadic guest posts, an underfunded Facebook ad campaign, a LinkedIn presence that gets updated twice a month, and maybe a Reddit comment here and there.

    The result? Marginal traction everywhere and momentum nowhere.

    If you’re running a content-driven business alone or with a tiny team, you don’t have the bandwidth to maintain six traffic channels. You barely have enough to run two well. And running two well will deliver more than running six poorly.

    Why diversification backfires for solo operators

    Diversification makes sense when you have a team. A social manager can own Twitter and LinkedIn. An SEO lead can build out a content calendar. A paid strategist can optimize ad spend.

    When you’re alone, diversification becomes dilution.

    Each traffic channel has its own learning curve, content format, posting cadence, and algorithmic quirks. SEO requires consistent publishing, keyword research, and backlink outreach. Twitter needs daily engagement. Paid ads need creative testing and conversion tracking. LinkedIn wants long-form native posts, not links.

    Switching between them incurs a cognitive tax. You’re not just creating content—you’re context-switching between platforms that reward different behaviors. That overhead kills the compounding effect that makes any single channel work.

    Traffic doesn’t compound. But channel-specific skill does. The more reps you get on one platform, the faster you learn what works, the better your content performs, and the less time each piece takes to produce.

    Pick two, not six

    Here’s the framework: choose one owned channel and one discovery channel.

    Owned: SEO, email, or your own site. Something you control, that builds equity over time, and that doesn’t disappear if an algorithm shifts. For most operators, this is SEO—organic search traffic that arrives because you published something useful and Google indexed it.

    Discovery: Social media, paid ads, communities, or guest platforms. Somewhere people find you before they know you exist. This is where new readers come from. For most, it’s one social platform or a narrow paid strategy.

    If you’re writing a weekly newsletter and trying to grow it, your mix might be: SEO + Twitter. You publish articles on your site, optimize them for search, and share insights and threads on Twitter that link back. Both feed your email list.

    Or: SEO + LinkedIn. You write long-form posts natively on LinkedIn to build authority, and publish evergreen how-tos on your own site that rank and convert.

    Or: Email + Reddit. You don’t have a blog. You participate in niche subreddits, answer questions with real value, and your profile links to your newsletter signup.

    The pair matters less than the commitment. Two channels, both run well, will outperform six channels run inconsistently.

    What “run well” actually means

    Running a channel well means you:

    • Publish or engage on a predictable cadence
    • Track what works and do more of it
    • Understand the platform’s content format and native behavior
    • Spend enough time to see compounding return—usually 3–6 months minimum

    For SEO, that’s 2–4 articles a month, keyword-targeted, with internal links and a basic backlink strategy. For Twitter, it’s daily replies, weekly threads, and a clear niche. For LinkedIn, it’s 2–3 long posts a week that add value without asking for anything.

    If you can’t commit to that cadence on a channel, cut it.

    When to add a third

    Only after one of your two is working without you.

    That usually means you’ve automated part of it (SEO content is ranking and driving passive traffic), hired it out (someone else schedules and monitors your social), or built enough momentum that it runs on reduced effort (your Twitter replies generate inbound DMs even when you take a week off).

    Until then, adding a third channel just splits your attention and stalls progress on the two that matter.

    If you’re spread across six traffic sources right now, audit the last 90 days. Which two drove the most qualified traffic—people who actually signed up, bought, or engaged? Double down on those. Let the other four go quiet.

    You’ll lose the illusion of omnipresence. You’ll gain the reality of traction.

    Reply and tell us: which two channels are you concentrating on? We read every response.

  • Buffer vs. Publer vs. Hootsuite: scheduling APIs, queue limits, pricing

    Buffer vs. Publer vs. Hootsuite: scheduling APIs, queue limits, pricing

    Buffer vs. Publer vs. Hootsuite: scheduling APIs, queue limits, pricing
    Photo by Rubaitul Azad on Unsplash

    If you’re running content across Twitter, LinkedIn, Instagram, and Facebook, you need a scheduler that won’t drop posts, hit arbitrary limits, or charge you triple when you add a second brand account.

    Here’s how Buffer, Publer, and Hootsuite stack up for solo operators and small teams publishing 50–300 posts a month across 3–6 accounts.

    Queue depth and post limits

    Buffer’s free tier lets you schedule 10 posts per connected account. The Essentials plan ($6/month per channel) removes the queue cap but limits you to one user. If you’re managing client accounts or a team, you’ll need Team at $12/month per channel—which gets expensive fast if you’re active on four networks.

    Publer‘s free plan allows 10 scheduled posts total, but its Professional tier ($12/month) gives you unlimited scheduling across unlimited accounts and workspaces. That’s the same price Buffer charges per channel. If you’re cross-posting to five platforms, Publer saves you $48/month.

    Hootsuite’s pricing starts at $99/month for one user and 10 social accounts. The platform is built for agencies and enterprises—overkill unless you’re managing 20+ accounts or need approval workflows.

    Platform support and media handling

    All three handle Twitter, Facebook, LinkedIn, and Instagram. Publer also supports Pinterest, TikTok, YouTube, Mastodon, and Google Business—useful if you’re diversifying or testing new channels without adding another tool.

    Buffer compresses images above 5MB and doesn’t warn you before upload. If you’re scheduling high-res carousels or infographics, check the preview carefully—some detail gets lost. Publer and Hootsuite both preserve originals up to 8MB and 10MB respectively, then compress with a warning.

    Video support varies. Buffer caps video uploads at 512MB and transcodes everything to MP4. Publer allows up to 1GB and supports more native formats. Hootsuite allows 512MB but charges extra for bulk video libraries on lower tiers.

    Scheduling reliability and API quirks

    Buffer and Publer both use direct platform APIs. Posts queue client-side, then fire via webhook at the scheduled time. If the API is down (rare but it happens—Twitter’s API went dark for 90 minutes in May), your post waits in retry for up to four hours before failing silently. Neither tool emails you when a post fails unless you explicitly enable notifications in settings.

    Hootsuite uses a hybrid model: some posts go direct, others route through Hootsuite’s proxy layer for compliance monitoring. This adds 15–30 seconds of delay but catches posts that violate platform TOS before they go live. Helpful if you’re managing clients; irrelevant if you’re solo.

    One non-obvious issue: Instagram carousel scheduling fails on all three platforms if your images have mismatched aspect ratios. The API rejects the batch and gives a generic error. Publer’s preview catches this before you schedule; Buffer and Hootsuite don’t flag it until the post fails.

    Pricing summary

    • Buffer: $6/month per channel (Essentials), $12/month per channel for teams. Free tier: 10 posts per account, 3 channels max.
    • Publer: $12/month for unlimited posts and accounts (Professional). Free tier: 10 total scheduled posts, 3 accounts.
    • Hootsuite: $99/month (Professional), includes 10 accounts and one user. Free tier: 2 accounts, 5 scheduled posts.

    Who each is best for

    Pick Buffer if you’re only active on two or three platforms, post fewer than 50 times a month, and want the simplest possible interface. It’s clean, fast, and doesn’t try to upsell analytics dashboards you don’t need.

    Pick Publer if you’re cross-posting to four or more networks, testing new platforms like Mastodon or TikTok, or running multiple brands from one account. The per-channel pricing model makes it the cheapest option once you pass three active accounts.

    Pick Hootsuite only if you’re managing 10+ accounts for clients, need approval workflows, or require compliance logging for regulated industries. Everyone else is overpaying.

    One last note: all three platforms let you connect Google Analytics UTM parameters automatically. Buffer and Publer apply them at the account level; Hootsuite requires manual tagging per post unless you set up a campaign template. If attribution matters to you, test this before committing.

    Want more tool breakdowns like this? Subscribe to One Two Three Send for weekly comparisons, tutorials, and operator Q&A—no fluff, just the details that matter when you’re running a one-person content business.

    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.

  • WordPress plugin conflict logs: where errors hide and how to read them

    WordPress plugin conflict logs: where errors hide and how to read them

    WordPress plugin conflict logs: where errors hide and how to read them
    Photo by Brett Jordan on Unsplash

    When a WordPress plugin breaks your site, you usually get a white screen, a cryptic error message, or—worse—nothing at all. The checkout button stops working. The contact form silently drops submissions. A scheduled post never publishes.

    Most solo operators disable plugins one by one until something works again. That approach finds the culprit, but it doesn’t tell you why the conflict happened or whether it’ll break again after the next update.

    WordPress writes conflict and error data to several places. If you know where to look and what patterns matter, you can diagnose plugin conflicts in minutes instead of hours, and you’ll catch silent failures before readers do.

    Where WordPress writes plugin error logs

    WordPress doesn’t enable debug logging by default. When a plugin conflict occurs, the error might surface in your browser, but more often it gets written to a server log that most operators never open.

    There are three places to check:

    • debug.log in /wp-content/ — only appears if WP_DEBUG_LOG is enabled in wp-config.php. This is the primary conflict log. It captures PHP errors, warnings, notices, and deprecated function calls. Most plugin conflicts show up here first.
    • Server error logs — your hosting provider writes PHP fatal errors and web server errors here. Location varies: cPanel puts them in /logs/, managed WordPress hosts expose them in dashboards. BigScoots surfaces them in the control panel under “Error Log.” Fatal errors that kill the site bypass debug.log and land here.
    • Browser console — JavaScript conflicts don’t write to PHP logs. Open your browser’s developer tools (F12) and check the Console tab. A missing .js file, a jQuery version mismatch, or a React component error will show here, not in WordPress logs.

    If WP_DEBUG_LOG isn’t enabled, add this to wp-config.php just above the line that says /* That's all, stop editing! */:

    define('WP_DEBUG', true);
    define('WP_DEBUG_LOG', true);
    define('WP_DEBUG_DISPLAY', false);

    This writes errors to debug.log without displaying them to site visitors. Leave it on for a week. If a conflict exists, it’ll log.

    What plugin conflict entries actually look like

    A typical conflict log entry looks like this:

    [23-Jul-2026 14:32:18 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wp_mail() in /home/user/public_html/wp-content/plugins/custom-contact-form/contact.php:47

    Here’s what matters:

    • Timestamp — when the error fired. Cross-reference this with when you updated a plugin or when a visitor reported a problem.
    • Error type — Fatal errors break execution. Warnings and notices don’t stop the site, but they signal a conflict that might escalate after the next plugin update.
    • File path — tells you which plugin triggered the error. In this case, custom-contact-form is the culprit.
    • Function name — wp_mail() is undefined, which usually means the plugin loaded too early, before WordPress core functions were available.

    Not all conflicts are this clear. Sometimes you’ll see dozens of deprecation notices from a single plugin. That’s noise. Look for fatal errors and repeated warnings tied to the same plugin and function. Those are the patterns that predict breakage.

    Tracing breaking changes after plugin updates

    If your site breaks immediately after a plugin update, the log will show the new error. But if the conflict is silent—forms stop submitting, emails stop sending, scheduled posts don’t publish—you need to correlate log timestamps with plugin update times.

    WordPress logs plugin updates in the database, but doesn’t surface them in a readable timeline. If you suspect a recent update caused a conflict, check debug.log for the first error timestamp, then compare it to your plugin update history in the WordPress admin under Dashboard → Updates. That page shows recent updates, but only for the last few days.

    For longer history, query the database directly or use a plugin like WP Activity Log, which tracks every plugin activation, update, and deactivation with timestamps. Cross-reference the log with your debug.log entries. If the first error appeared within an hour of a plugin update, that’s your conflict source.

    What to do once you’ve identified the conflict

    Once you know which plugin is logging errors, you have three options:

    • Roll back the plugin — most managed WordPress hosts offer one-click plugin rollback. If yours doesn’t, download the previous version from the WordPress plugin repository’s “Advanced View” tab and upload it manually. This buys time while you wait for a patch.
    • Disable the conflicting feature — some plugins let you toggle features. If the conflict stems from a feature you don’t use, turn it off instead of disabling the entire plugin.
    • Contact the developer — if the plugin is actively maintained, report the conflict with your log excerpt, WordPress version, PHP version, and conflicting plugin name. Most developers fix conflicts within a few days if you give them clean reproduction steps.

    Don’t leave WP_DEBUG enabled indefinitely on a live site. Once you’ve identified and resolved the conflict, set WP_DEBUG and WP_DEBUG_LOG back to false. Debug logs grow large and can expose server paths to anyone who guesses the debug.log URL.

    One non-obvious tip: check for JavaScript conflicts separately

    PHP logs won’t capture JavaScript conflicts. If a plugin breaks your site’s front-end interactivity—buttons stop responding, modals don’t open, checkout forms freeze—open your browser console and look for red error messages. Common culprits: two plugins loading different versions of jQuery, or a plugin enqueueing a script that depends on another script that didn’t load.

    To confirm a JavaScript conflict, disable plugins one by one while keeping the browser console open. When the red errors disappear, you’ve found the plugin responsible.

    Want more WordPress infrastructure breakdowns like this? Reply with the hosting or plugin behaviour you want explained next—we read every response and route the best questions into future issues.

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

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

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

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

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

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

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

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

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

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

    Monthly revenue at different tiers

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

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

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

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

    When the math breaks down

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

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

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

    Who should turn it on

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

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

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

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

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

  • ConvertKit’s custom field limits: when segmentation hits a ceiling

    ConvertKit’s custom field limits: when segmentation hits a ceiling

    ConvertKit's custom field limits: when segmentation hits a ceiling
    Photo: Caladusp via Wikimedia Commons (CC BY-SA 4.0)

    ConvertKit lets you add up to 100 custom fields per account. That sounds generous until you’ve been running a newsletter for two years, tagging readers by interest, purchase history, geography, onboarding date, referral source, content preferences, and engagement tier.

    Then you hit the wall.

    The limit isn’t documented prominently. You discover it when the “Add Field” button grays out, or when an automation fails to create a new field and your sequence quietly stops working.

    What counts toward the limit

    Every custom field you create—whether it’s a text field, number, or date—counts toward the 100-field cap. This includes:

    • Active fields currently in use
    • Archived fields you’re no longer using but haven’t deleted
    • Fields created by integrations (Zapier, API calls, third-party forms)

    Deleting a field frees up a slot, but only if you’re certain no automation or segment references it. ConvertKit doesn’t warn you before deletion, and there’s no “undo.”

    Tags, by contrast, are unlimited. Subscribers are unlimited. It’s only custom fields—the structured data layer—that hits a ceiling.

    Where operators waste field slots

    Most operators I’ve audited are using 40–60 fields. The bloat comes from:

    Redundant date fields. Separate fields for “trial_start,” “trial_end,” “first_purchase,” “last_purchase,” “onboarding_completed.” You can often collapse these into tags with date-based automations, or store only the field you’ll actually query.

    One-off campaign tracking. A field for every lead magnet, webinar, or promo. If you’re not segmenting on it after 90 days, archive or delete it.

    Text fields that should be tags. A “interests” field with comma-separated values like “SEO, WordPress, email” is harder to segment than three tags. ConvertKit’s segment builder can combine tags with AND/OR logic; custom field text matching is clunkier.

    Legacy fields from old integrations. A Typeform you used once in 2024, a Zapier zap you turned off, a WordPress plugin you uninstalled. Each left fields behind.

    How to design segments that scale

    If you’re approaching the limit—or want to avoid it—here’s the structure that works:

    Use tags for categorical data. Interests, content preferences, lead sources, engagement tiers. Tags are unlimited, combinable, and easier to audit.

    Reserve custom fields for values you’ll calculate or compare. Numbers (purchase count, total spend, engagement score), dates (signup date, last click), or IDs (Stripe customer ID, external CRM reference).

    Audit every 90 days. Export your field list. Flag anything unused in the last quarter. Archive first, delete after another 30 days if no automations break.

    Document field purpose and owner. Keep a spreadsheet. Column A: field name. Column B: what it tracks. Column C: which automations or segments use it. Column D: date created. When you hit 80 fields, you’ll thank yourself.

    What happens if you hit the cap

    Automations that try to create or update a field beyond the 100th slot fail silently. The automation continues, but the field write doesn’t happen. You won’t get an error email. The subscriber moves to the next step as if nothing broke.

    If you’re relying on that field for downstream segmentation—say, tagging high-intent leads based on a quiz score—you’ll lose data without noticing until you spot the gap in your reports.

    ConvertKit support can’t raise the limit. It’s a hard platform cap, same across all pricing tiers.

    The workaround: delete unused fields, or rethink your data model. Some operators move complex segmentation logic into an external CRM (like Brevo or a dedicated CDP) and sync only the essential fields back to ConvertKit. That adds complexity, but it scales past 100.

    When to stay under 50

    If you’re running a solo operation with fewer than 10,000 subscribers, aim to stay under 50 fields. It forces clarity. Every field you add should answer: “What decision does this let me make that I can’t make with tags?”

    If the answer is “nothing,” use a tag.

    Most operators don’t need purchase history in a custom field—they need a “purchased” tag and a “last_purchase_date” field for recency-based re-engagement. That’s two slots instead of five.

    ConvertKit’s segmentation is powerful, but it rewards restraint. The ceiling exists whether you plan for it or not.

    Hit a segmentation problem you can’t solve with tags? Reply and tell us what you’re trying to track—we’ll feature operator solutions in a future issue.

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

  • Newsletter referral programs pay per signup—but measure net growth

    Newsletter referral programs pay per signup—but measure net growth

    Newsletter referral programs pay per signup—but measure net growth
    Photo by Defrino Maasy on Unsplash

    Most newsletter referral programs report one number: gross signups. Someone shares your link, three people subscribe, you see +3 in the dashboard. The referring subscriber unlocks a reward tier. Everyone’s happy.

    Except gross signups don’t tell you whether those three people are still reading 60 days later—or whether they bounced the moment the referrer claimed their prize.

    If you’re running a referral program through Beehiiv, SparkLoop, or a similar tool, you need to track net referral growth: how many referred subscribers remain engaged after the incentive window closes. Otherwise, you’re paying for churn with extra steps.

    Why gross referral counts mislead

    Referral programs reward the act of signing someone up, not the quality of that subscriber. If your reward tiers unlock at 3, 10, or 25 referrals, the person sharing your link is optimized for volume. They’ll post it in group chats, tag friends who aren’t interested, or share it in communities where your topic is tangential at best.

    Those signups count. The platform credits them. But six weeks later, half of them have unsubscribed or gone cold. Your list grew by 25, but your engaged audience grew by 12. You paid the referrer’s reward in full.

    This isn’t theoretical. One operator I spoke with ran a referral campaign offering a $50 Amazon gift card at 10 referrals. Average churn rate for referred subscribers in the first 90 days: 48%. For organic signups in the same period: 22%. The campaign grew the list by 340 subscribers. Six months later, 140 of them were still active. Cost per retained subscriber: higher than a modest Facebook ad budget would have delivered.

    What to measure instead

    Track referral cohorts separately from organic signups, and measure engagement at 30, 60, and 90 days post-signup. Most ESPs let you tag subscribers by source; if yours doesn’t, add a hidden field or custom property when someone arrives via a referral link.

    Compare:

    • Open rate at day 30: Are referred subscribers opening at the same rate as organic signups?
    • Unsubscribe rate by day 60: When does referred churn plateau?
    • Click rate on monetized content: If you’re running sponsorships or affiliate links, do referred subscribers engage with revenue-driving content?

    If referred subscribers churn or disengage faster than organic, your referral program is subsidizing vanity metrics. A list of 10,000 with 40% engagement beats 15,000 with 25% engagement in every scenario that matters: deliverability, sponsor value, product conversion.

    When referral programs still make sense

    Referral mechanics work when:

    • Your content has strong word-of-mouth fit—people genuinely want to share it, and the reward is a bonus, not the primary driver.
    • You’re willing to adjust reward tiers based on retention data, not just signup volume.
    • You can afford to treat referred subscribers as a separate, lower-intent cohort and nurture them differently in your first 90 days.

    If you’re below 1,000 subscribers and still defining your audience, a referral program will accelerate list growth but may also dilute signal. You’ll spend months figuring out what content works for two different cohorts instead of one.

    Above 5,000 subscribers, referral programs become more defensible—but only if you’re already retaining >70% of organic signups past 90 days. If your baseline retention is weak, a referral program will amplify the problem, not solve it.

    One non-obvious fix

    Delay reward fulfillment by 60 days. Instead of unlocking rewards the moment a referrer hits 10 signups, unlock them 60 days after the tenth signup—and only if at least 7 of those 10 are still subscribed.

    This shifts the incentive from volume to quality. Referrers will share your link with people more likely to stick around, because they only get paid if those subscribers stay. It also filters out referral farmers who game the system by cycling through throwaway emails.

    Most referral platforms don’t support conditional reward logic natively, but you can build it with a weekly script that checks subscriber status and manually triggers rewards. It’s friction, but it’s worth it if you’re spending four figures a year on referral incentives.

    If you’re running a referral program right now: pull your referral cohort data for the last 90 days and compare retention to organic signups. If referred churn is more than 10 percentage points higher, either tighten your reward criteria or redirect that budget to a channel with better unit economics.

    Want more breakdowns like this? Subscribe to One Two Three Send—we cover the operational details most online-business newsletters skip.

    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.

  • AI content rewriter tools break your voice—here’s the tradeoff

    AI content rewriter tools break your voice—here’s the tradeoff

    AI content rewriter tools break your voice—here's the tradeoff
    Photo by Deepak Gupta on Unsplash

    Most AI content rewriter tools promise the same thing: take your draft, smooth out the rough patches, tighten the prose, and hand back something publishable in seconds. They work. The output is cleaner. But every operator who uses them regularly hits the same problem after a few weeks: the writing stops sounding like them.

    This isn’t about quality. The rewritten version is often technically better—shorter sentences, fewer filler words, clearer structure. The problem is that it’s better in a way that erases the small habits and choices that make your voice distinct. The casual aside. The sentence fragment. The specific word you’d use instead of the synonym the model picked.

    Readers don’t consciously notice voice most of the time, but they feel it when it shifts. If your last ten posts had a consistent rhythm and suddenly post eleven reads like it came from a different person, open rates drop. Replies dry up. The content still works, but the connection weakens.

    What rewriters actually change

    AI rewriter tools—whether standalone like Wordtune or built into larger platforms like Jasper and Copy.ai—operate by rephrasing your input to match patterns the model learned from training data. That data skews toward polished, formal, widely-published writing. The model doesn’t know your tics. It doesn’t know you always use “folks” instead of “people” or that you start half your paragraphs with a dependent clause.

    Here’s what typically gets flattened:

    • Sentence rhythm. If you write in a mix of long and short bursts, the rewriter will smooth it into medium-length sentences.
    • Colloquialisms. Casual phrases get swapped for neutral equivalents. “A pain to set up” becomes “difficult to configure.”
    • Redundancy you use for emphasis. Repeating a word or idea for effect gets trimmed as inefficiency.
    • Personality markers. Em dashes, parenthetical asides, rhetorical questions—anything that breaks formal structure tends to get rewritten or removed.

    None of this is wrong. But if those elements are why your readers recognize your writing, stripping them out is a problem.

    When rewriters make sense

    There are situations where flattening your voice is the correct tradeoff. If you’re writing help documentation, product updates, or onboarding emails, clarity beats personality. Readers aren’t there for your voice—they’re there to solve a problem or understand a feature. A rewriter can take a tangled explanation and make it scannable in seconds.

    Rewriters also help when you’re stuck. If you’ve written the same paragraph three times and it still feels off, running it through a tool can break the loop. You won’t keep the output verbatim, but it gives you a new angle to edit from.

    And if English isn’t your first language, rewriters handle grammar edge cases faster than you can look them up. The risk is still there—your voice might get smoothed out—but the time saved often outweighs it.

    How to use them without losing yourself

    If you’re going to use a rewriter regularly, treat it like a first-pass editor, not a replacement for your judgment. Here’s the workflow that works:

    Write the full draft first. Don’t rewrite as you go. Get your ideas out in your natural voice, then decide which sections need help.

    Rewrite in chunks, not whole pieces. Run one paragraph or section at a time. If you feed an entire post into a rewriter, you lose control over which changes matter and which don’t.

    Edit the rewrite. Don’t publish the output as-is. Read it aloud. If a sentence doesn’t sound like something you’d say, change it back or meet halfway. The goal is to use the tool’s structure while keeping your word choices.

    Keep a voice reference. Save three or four posts you’re proud of—ones where the voice feels right. Before you hit publish on something that’s been rewritten, compare it. If the tone feels off, you’ll catch it.

    The long-term cost

    The risk isn’t just that one post sounds different. It’s that if you rely on a rewriter for every piece, you stop practicing the skill of editing your own voice. Over six months, your drafts start to sound more like the tool’s output even before you run them through it. You’re training yourself to write in a way that needs less rewriting, which means writing in a way that sounds like everyone else using the same model.

    This is fixable, but it requires noticing it’s happening. If you’ve published twenty posts in the last two months and none of them feel like you anymore, the rewriter is doing too much of the work.

    Voice is one of the few competitive advantages solo operators have. It’s free, it’s hard to replicate, and it’s why readers pick your site over the fifty others covering the same topics. Rewriters are useful tools, but they’re not neutral. Every time you use one, you’re making a tradeoff. Just make sure you’re choosing it, not defaulting to it.

    Trying to balance speed and voice in your own workflow? Reply with what you’re struggling with—I’ll cover reader questions in an upcoming piece.

  • WordPress post scheduler cron: how it works and when it fails

    WordPress post scheduling feels like magic—until a post doesn’t publish on time. You set a future date, hit schedule, and assume the post will go live at 9:00 AM sharp. Sometimes it does. Sometimes it publishes three minutes late. Sometimes it doesn’t publish at all until you manually refresh the site.

    The reason is simple: WordPress doesn’t use real cron. It fakes it. And for solo operators running lean sites with inconsistent traffic, that fake cron system breaks more often than you’d expect.

    How WordPress scheduling actually works

    When you schedule a post, WordPress stores the future publish time in the database and registers a “cron event” tied to that timestamp. But WordPress cron isn’t a server-level scheduled task—it’s a PHP script that runs only when someone visits your site.

    Every time a page loads, WordPress checks if any cron events are overdue. If one is, it spawns a background HTTP request to wp-cron.php, which processes the event queue. That queue includes scheduled posts, plugin tasks, update checks, and anything else hooked into the cron system.

    This approach works fine for high-traffic sites. If you’re getting page views every few seconds, cron events fire close to their scheduled time. But if your site gets sporadic traffic—common for new operators, niche blogs, or B2B content sites—you might not get a visitor at 9:00 AM. The post sits in the queue until someone (or something) hits the site.

    When scheduling breaks

    Three common failure modes:

    Low traffic delays publication. If your site averages ten visitors per hour and you schedule a post for 6:00 AM, it might not publish until 6:43 AM when the first human visitor triggers wp-cron.php. Search engines and RSS readers may already have crawled your site and missed it.

    Caching plugins disable wp-cron.php. Some full-page caching setups (especially aggressive CDN configs or static site generators bolted onto WordPress) block the background HTTP request to wp-cron.php. The page load completes, but the cron event never fires. Posts stay in “scheduled” status indefinitely.

    The cron queue gets clogged. If a plugin registers dozens of cron events—backup scripts, API syncs, email queue processors—and one of those tasks hangs, the entire queue stalls. WordPress processes cron events sequentially in a single request. A 30-second timeout on one event blocks everything behind it, including your scheduled post.

    How to fix it

    The cleanest solution: disable WordPress’s fake cron and use real server-level cron instead.

    Add this line to wp-config.php:

    define('DISABLE_WP_CRON', true);

    Then add a real cron job via your hosting control panel or SSH. Most hosts (including BigScoots, SiteGround, and Kinsta) let you add cron jobs through cPanel or a custom dashboard. Set it to run every 5–15 minutes:

    */15 * * * * wget -q -O - https://yoursite.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

    Or use curl if wget isn’t available:

    */15 * * * * curl -s https://yoursite.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

    Now cron events fire on schedule, regardless of traffic. Posts publish within 15 minutes of their target time (or within 5 minutes if you set the interval tighter). RSS readers and search crawlers see content when you intended.

    One non-obvious benefit: this setup also makes plugin-based automations more reliable. If you’re using WordPress to queue emails, sync data to external APIs, or run nightly cleanup tasks, real cron ensures those jobs complete even when your site is quiet.

    One thing to watch

    If you run real cron and have high traffic, you might end up triggering wp-cron.php twice in the same minute—once from the server cron job, once from a visitor’s page load. This usually isn’t a problem (WordPress locks cron execution to prevent duplicate runs), but if you’re obsessive about server load, keep DISABLE_WP_CRON enabled and let the server-level job handle everything.

    If you’d rather not touch server config, a few managed WordPress hosts (Kinsta, WP Engine) run real cron by default. Check your host’s documentation—some silently replace wp-cron.php without telling you.

    Want more infrastructure breakdowns like this? Subscribe to One Two Three Send—we explain the invisible plumbing that makes (or breaks) online businesses.

  • Stripe subscription proration logic: what customers actually get charged

    Stripe subscription proration logic: what customers actually get charged

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

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

    How Stripe calculates proration by default

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

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

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

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

    When proration breaks customer expectations

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

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

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

    Proration settings you can control

    Stripe gives you three levers:

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

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

    For most solo operators, the simplest setup is:

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

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

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

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

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

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

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

  • Traffic doesn’t compound—audiences do

    Traffic doesn’t compound—audiences do

    Traffic doesn't compound—audiences do
    Photo: Rose Abrams via Wikimedia Commons (CC BY 4.0)

    Every traffic guide tells you to chase SEO, write more posts, optimize meta descriptions, and wait for the compounding effect. The promise is simple: publish consistently, and traffic grows exponentially as old posts keep ranking.

    Except it doesn’t work that way for most solo operators.

    Traffic doesn’t compound. It decays. Google re-ranks your posts. Platforms change algorithms. Referral sources dry up. A post that drove 500 visitors last month might send 50 this month. You’re not building a snowball—you’re running on a treadmill.

    What actually compounds is audience: the list of people who opted in, the followers who see your posts directly, the group that comes back because they chose to. That’s the asset. Traffic is just a variable.

    The difference between traffic and audience

    Traffic measures eyeballs per page. Audience measures people who return. Traffic comes from discovery—search, social, referrals. Audience comes from capture—email, RSS, follows, bookmarks.

    Traffic requires you to re-earn attention every single time. Audience gives you a direct line. When you publish, your audience sees it. When you have an offer, they hear about it first. Traffic might spike and vanish. Audience sticks around.

    Here’s the math that matters: if you get 10,000 visitors this month and convert 2% to your email list, you add 200 people to an owned channel. Next month, you can reach those 200 people again—plus whatever new signups you get. That’s compounding. The 10,000 visitors? Most of them never come back.

    Why solo operators default to traffic

    Traffic is easier to measure. Google Analytics shows the chart going up. Social dashboards count impressions. It feels like progress.

    Audience-building is slower and harder to instrument. Email lists grow in double digits per week, not thousands. Social followers unfollow. RSS readers are invisible. There’s no dopamine hit from watching a subscriber count tick up by twelve.

    But traffic without conversion is just noise. You’re renting attention from Google, Meta, Reddit, or whoever sent the click. The moment they change the algorithm—or your post drops in rankings—it’s gone.

    Audience is owned distribution. It’s the only channel where you control both the message and the delivery.

    How to shift from traffic-first to audience-first

    This doesn’t mean stop doing SEO or writing for discovery. It means treating every inbound visitor as a potential long-term relationship, not just a session.

    Start with conversion rate, not traffic volume. If 5,000 visitors convert at 1%, that’s 50 new subscribers. If 2,000 visitors convert at 4%, that’s 80. The smaller number wins. Optimize your signup forms, exit-intent prompts, and content upgrades before you write another SEO post.

    Publish where your audience lives, not just where traffic might come from. If your email list is 2,000 people and your blog gets 8,000 monthly uniques, your list is still more valuable. They open, click, and buy. Random traffic just bounces.

    Measure retention, not sessions. Track how many subscribers are still opening six months later. How many social followers actually engage. How many RSS readers click through. If those numbers are low, your audience isn’t real—you just have a big list of dead contacts.

    The long game

    A 5,000-person email list that opens at 40% will outperform a blog with 50,000 monthly visitors and a 1% conversion rate. The list reaches 2,000 people on demand. The blog might convert 500 into one-time actions.

    Traffic gets you discovered. Audience gets you remembered. If you’re a solo operator building something that lasts longer than this quarter’s Google update, build the audience.

    One Two Three Send breaks down the tools and tactics that help you capture and keep attention—not just rent it. Subscribe and get one focused piece like this every day.

Powered by CookieAdmin