One Two Three Send

Author: onetwothreeadmin

Social media scheduling APIs break drafts—here’s what gets lost
Photo by Walls.io on Unsplash

Social media scheduling tools promise seamless queue management across platforms. But if you’re building custom workflows—Zapier automations, Make scenarios, or direct API integrations—you’ll quickly discover that “draft” doesn’t mean the same thing to every tool.

Most social schedulers expose a publish endpoint and a queue endpoint. What they don’t expose cleanly: draft state, revision history, or partial edits. When you push a post via API, it’s either scheduled or it’s not. The in-between states that exist in the web UI often vanish when you automate.

What draft state actually means

In most scheduling tools, a draft is a post that exists in the database but hasn’t been assigned a publish time. It’s a holding area. You can edit it, attach media, add tags, then decide later whether to schedule or delete it.

But APIs don’t mirror this workflow. Most tools require you to pass a scheduled_at timestamp when you create a post via API. If you don’t, the post either publishes immediately or throws an error. There’s no “save this as a draft and let me come back to it” option.

Publer is one exception—it allows null scheduling via API and treats those posts as drafts. But even there, you can’t retrieve draft metadata like “last edited by” or “created from automation.” The web UI shows that context; the API doesn’t return it.

What breaks when you automate

Here’s a common workflow: you use an AI tool to generate social copy variations, push them to your scheduler as drafts, then manually review and approve each one before it goes live.

If your scheduler’s API doesn’t support true draft state, you’re forced to pick a workaround:
- Schedule everything far into the future (e.g., December 31, 2030), then manually move posts forward. This clutters your queue and makes it hard to see what’s actually scheduled.
- Store drafts in a separate tool (Notion, Airtable, a Google Sheet), then manually copy-paste into your scheduler. This defeats the purpose of automation.
- Push directly to the platform API (Twitter, LinkedIn, Instagram) and skip the scheduler entirely. This works, but you lose centralized analytics and multi-platform posting.
None of these are clean. All of them add friction back into a workflow you were trying to automate.

Which tools handle drafts cleanly

I tested five popular schedulers to see which ones preserve draft state when you create posts via API:
- Publer: Full draft support. You can POST to /posts with no date field, and it saves as a draft. You can retrieve drafts via GET and update them later.
- Buffer: No draft support. Every API call requires scheduled_at or the post publishes immediately. The web UI has a drafts tab, but you can’t create drafts programmatically.
- Later: Partial support. You can create “unpublished” posts, but they’re tied to a specific calendar slot. Moving them requires a separate PATCH request, and there’s no way to bulk-retrieve unpublished items.
- Hootsuite: No API access to drafts. You can create scheduled posts, but anything without a timestamp is rejected.
- Metricool: Similar to Buffer—scheduled or live, no in-between.
If draft state matters to your workflow, Publer is the only tool in this group that treats it as a first-class API feature.

How to route around it

If you’re locked into a scheduler that doesn’t support drafts via API, here’s what works:

Use a staging tag. Create a unique tag like draft-pending and attach it to every post you create programmatically. Schedule everything for a distant date, filter your queue by tag, and batch-review. When you approve a post, remove the tag and reschedule it.

Build a lightweight draft layer. Store draft content in Airtable or Notion, mark each row as “approved” or “pending,” then trigger a Zapier or Make automation that only schedules posts marked approved. This adds a table to maintain, but it gives you full control over state.

Use webhooks to pull, not push. Instead of pushing drafts into your scheduler, set up a webhook that fires when you mark a draft “ready” in your CMS or AI tool. The webhook calls your scheduler’s API at that moment—no orphaned drafts, no clutter.

None of these are as clean as native draft support, but they’re predictable and won’t break when your scheduler updates its API.

What to ask before you automate

Before you wire up a social scheduling automation, check the API docs for these three things:
- Can I create a post without a scheduled_at timestamp?
- Can I retrieve posts that haven’t been scheduled yet?
- Can I update a draft after creation without republishing it?
If the answer to any of those is no, plan your workaround before you build. Draft state isn’t a nice-to-have—it’s the difference between a smooth review process and a queue full of junk you can’t easily filter.

Want more tooling breakdowns like this? Reply and tell me which API quirks cost you the most time—I’ll cover it in a future piece.

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.
2 July 2026
WordPress comment spam plugins create database bloat you can’t see

Photo: Matinbeigi via Wikimedia Commons (CC BY-SA 4.0)

Most WordPress comment spam plugins work the same way: they intercept bot submissions, run a quick validation check, then silently block the junk. Clean dashboard, no moderation queue overflow, problem solved.
Except the logs don’t disappear. They accumulate in your database, often in custom tables the plugin created during activation. A site that publishes two posts a week might generate 40 rows of real comments per month—and 4,000 rows of blocked spam attempts that still get written to disk.
The performance cost sneaks up slowly. MySQL queries take an extra 100ms, then 200ms. Backups grow from 50MB to 800MB. Your host starts warning you about inode limits. And because the spam logs live in separate tables, you won’t notice them in your Posts or Comments admin screens.
What gets logged and where
Popular plugins like Akismet log every checked comment, whether it’s marked as spam, passed, or auto-deleted. That metadata includes IP address, user agent string, submitted content, referrer, and timestamp. Each log entry runs 1–3KB depending on comment length.
If your site receives 200 spam attempts per day—a conservative estimate for any public WordPress install older than six months—that’s 6,000 rows per month, or roughly 12MB of log data before indexing overhead.
Some plugins store logs in wp_commentmeta, which inflates core WordPress tables. Others create dedicated tables like wp_akismet_log or wp_antispam_data. A few write to flat files in /wp-content/uploads, which can break backup scripts that assume uploads only contain media.
The worst offenders don’t surface log size in their settings panels. You have to SSH in and run SELECT COUNT(*) queries or inspect table sizes via phpMyAdmin to know how much space the plugin has claimed.
When bloat starts breaking things
Database bloat doesn’t crash your site. It degrades it in ways that look like other problems.
Slow admin page loads get blamed on a bad theme. Backup timeouts get blamed on host resource limits. Jump-to-comment anchor links that take two seconds to resolve get blamed on browser caching.
The real bottleneck: MySQL has to scan larger indexes every time it touches the comments table, even if your query filters by post ID. If the spam log shares a table with legitimate comment metadata, every comment-related query pays the performance tax.
One operator I spoke with last month had 1.4 million rows in their Akismet log spanning four years. Their live site showed 800 published comments. The log table alone consumed 2.8GB—more than the rest of their WordPress database combined. Clearing it dropped full-page cache generation time from 11 seconds to under three.
Manual cleanup and plugin-level controls
Most comment spam plugins include a log retention setting buried two or three tabs deep. Akismet’s lives under Settings → Akismet Anti-Spam → Privacy. The default is often “Keep logs indefinitely” or a vague “Delete old entries automatically” that triggers annually.
Set retention to 30 or 60 days unless you’re actively investigating spam patterns or running forensic analysis. Logs older than eight weeks have near-zero diagnostic value—you’ve either already fixed the issue or decided to live with it.
For immediate cleanup, you can truncate plugin log tables directly via SQL. Example for Akismet:
TRUNCATE TABLE wp_akismet_log;
Back up your database first. Some plugins store legitimate config data in the same table as logs, though most separate the two. If you’re unsure, export the table schema and first 100 rows before running destructive queries.
After truncation, run OPTIMIZE TABLE wp_akismet_log; to reclaim disk space. MySQL marks deleted rows as free space but doesn’t shrink the table file until you explicitly optimise.
Better: switch to lightweight validation
If you’re not monetising comments and don’t rely on them for community interaction, turn off comments site-wide and uninstall the spam plugin entirely. You’ll shed the performance overhead and eliminate the log problem at the source.
If you need comments on select posts, use a JavaScript-based honeypot or time-delay check instead of a server-side plugin that logs every request. Tools like Cloudflare Turnstile or hCaptcha validate humans without writing to your database.
For high-traffic sites where moderation and spam filtering are non-negotiable, run your anti-spam checks in a separate microservice or worker process that doesn’t touch your WordPress database. Log to a dedicated logging service with automatic retention policies—Logtail, Papertrail, or even a self-hosted Loki instance—so old data expires without manual intervention.
What you should do this week: SSH into your WordPress install or open phpMyAdmin. Check table sizes for any plugin with “spam,” “akismet,” “antispam,” or “comment” in the name. If any table exceeds 100MB and you’re not actively debugging spam issues, truncate it and set retention to 30 days. Your backups will thank you.
Hit reply if you’ve found other plugins that hoard logs silently—we’ll cover the worst offenders in a future piece.

2 July 2026
AI chat context windows: when to clear history and start fresh
Photo by kuu akura on Unsplash

Most solo operators treat AI chat tools like an ongoing conversation—asking follow-ups, refining prompts, building on earlier responses. That’s how the interface encourages you to work. But every AI model has a context window limit, and once you hit it, output quality drops fast.

The problem isn’t obvious. The chat doesn’t warn you. The model doesn’t stop working. It just starts forgetting earlier instructions, mixing up references, and producing vaguer answers. You assume the prompt was bad. Usually, the issue is that you’re six thousand words deep into a thread that should have been split three responses ago.

How context windows actually work

Every message you send—and every response the model generates—consumes tokens from a fixed budget. When you ask a follow-up question, the AI re-reads the entire conversation to understand what you mean. That’s why it remembers what you said five messages ago. It’s also why long threads cost more and perform worse.

Claude offers a 200,000-token context window on its paid tier. ChatGPT’s GPT-4 variant runs at 128,000 tokens on the higher plans. Gemini Advanced sits at 1,000,000 tokens. Those numbers sound huge—until you realize that a single 3,000-word article draft, plus your original instructions and two rounds of edits, can easily consume 8,000 to 12,000 tokens. Add in a few exploratory prompts, a pasted reference doc, and some back-and-forth clarifications, and you’re at 30,000 tokens before you notice.

The model doesn’t cut you off when the window fills. Instead, it starts trimming early messages to fit new ones. That means the setup instructions you wrote at the start—your tone guide, output format, audience description—get dropped first. The AI still responds, but it’s now working from a partial brief.

When to clear and start a new thread

Start fresh when you switch tasks. If you’ve been drafting email subject lines and now want to outline a blog post, open a new chat. The model will treat old context as relevant even when it isn’t, and you’ll waste tokens on irrelevant history.

Clear the thread when the AI starts giving generic answers. If responses lose specificity or start repeating earlier phrasing, you’ve likely hit diminishing returns. The model is spending more tokens re-processing old material than synthesizing new output.

Reset after major revisions. If you’ve pasted in a 2,000-word draft, asked for edits, then pasted a revised version and asked again, you’re now carrying two full copies of similar text in the context window. That’s expensive and confusing for the model. Better to start a new thread with just the current draft and a clean instruction set.

Reset when you’re working from a template. If you use the same system prompt across multiple projects—like a content brief generator or a headline testing script—save that prompt separately and paste it into a fresh chat each time. Don’t try to reuse a thread from last week. Stale context will bleed into new work.

What to save before you reset

Most platforms don’t let you export a single message easily, so copy anything you want to keep before clearing history. That includes:
- System prompts or instruction sets you plan to reuse
- Finalized drafts or code snippets
- Reference lists, outlines, or structures the AI generated that you’ll build on later
- Any custom terminology or style rules the model learned during the thread
If you’re on a paid plan with conversation folders or project workspaces, use those to organize threads by task type. Claude‘s Projects feature lets you set persistent instructions that apply to every new chat in that project, so you don’t have to re-paste your brand voice guide every time. ChatGPT’s custom instructions work similarly, though they apply account-wide rather than per-project.

For operators running high-volume workflows—like batch processing content ideas or generating dozens of ad variants—consider switching to API access instead of the chat interface. The API forces you to manage context explicitly, which makes it easier to control what gets included in each request. You’ll pay per token either way, but you’ll stop accidentally burning budget on dead context.

One non-obvious trick

If you’re midway through a long thread and don’t want to lose progress, try summarizing the conversation so far and asking the AI to confirm understanding. Paste that summary into a new chat as your starting prompt. You’ll preserve the useful context while dropping the cruft. This works especially well when you’ve gone through multiple rounds of iteration and only the final decisions matter going forward.

Most solo operators underestimate how much old context drags on new output. Clearing threads isn’t a failure—it’s maintenance. Treat it like clearing your browser cache: unsexy, invisible, and essential for performance.

Got a workflow trick that keeps your AI threads clean? Hit reply and share it—we’ll feature the best ones in a future roundup.

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.
1 July 2026
Newsletter referral programs: when you pay more than you earn

Photo by Christian Agbede on Unsplash

Newsletter referral programs sound like free growth. A reader shares your newsletter, someone new subscribes, the referrer gets a reward, and you gain a subscriber at zero acquisition cost. Except the math rarely works that way.
Most operators launch referral programs without calculating what each referred subscriber actually costs—in rewards, platform fees, fulfillment time, and opportunity cost. By the time you tally it up, you’re often paying more per subscriber than a simple paid ad would have cost, and you’ve added ongoing operational overhead that doesn’t scale.
What referral rewards actually cost
The common referral ladder looks like this: refer three friends, get a free sticker; refer ten, get a bonus post or template; refer fifty, get a one-on-one call or a course. The reward tiers feel modest when you write them, but each tier carries a real cost.
Digital rewards—bonus posts, templates, courses—cost time. If you’re giving away a $50 course for ten referrals, and that course took you twenty hours to build, you’re amortizing that time across every reward you give. If fifty people hit the ten-referral tier, you’ve given away 500 referred subscribers in exchange for work you could have sold for $2,500. That’s $5 per referred subscriber in forgone revenue, before you factor in platform fees.
Physical rewards—stickers, books, swag—cost money and logistics. A $3 sticker plus $1.50 domestic shipping is $4.50 per reward. If your referral threshold is three subscribers per sticker, that’s $1.50 per referred subscriber in direct cost. International shipping doubles or triples that.
High-value rewards—calls, coaching, custom work—cost time that doesn’t scale. A thirty-minute call for fifty referrals means you’re giving fifty referred subscribers in exchange for half an hour. If your hourly consulting rate is $200, that’s $4 per referred subscriber. If ten people hit that tier, you’ve just committed five hours to calls instead of client work or content production.
Platform fees and tracking overhead
Most newsletter platforms charge for referral program features. Beehiiv includes referral tracking in paid plans starting at $49/month. SparkLoop, the most popular third-party referral tool, starts at $50/month for up to 5,000 subscribers. If you’re running a 2,000-subscriber newsletter and paying $50/month for referral infrastructure, that’s $600/year before a single referral converts.
If your referral program generates 200 new subscribers in a year—a strong outcome for most newsletters under 5,000 subscribers—you’ve paid $3 per subscriber in platform fees alone. Add reward costs and you’re above $5 per subscriber, which is higher than Facebook or Twitter ad costs for most niches.
Then there’s tracking overhead. Referral programs require you to monitor tiers, validate referrals, fulfill rewards, and respond to questions. That’s recurring operational work that doesn’t exist if you acquire subscribers through other channels.
When referral programs actually work
Referral programs make sense in three scenarios. First, when your product has network effects and referrals improve the experience for everyone—think community newsletters or local event lists where more subscribers mean more user-generated content or better event turnout.
Second, when your audience is highly engaged and already sharing without incentives. If you’re seeing organic shares and word-of-mouth growth, a referral program can amplify behavior that’s already happening. But if nobody’s sharing organically, a referral program won’t create that behavior—it’ll just add cost to a channel that isn’t working.
Third, when your reward costs are near zero and your LTV is high. If you’re selling a $500/year subscription product and your referral reward is access to a digital archive you’ve already built, the incremental cost per reward is negligible and the payback period is short.
For most operators running free or low-cost newsletters, none of those conditions apply. You’re better off spending that $600/year on a lead magnet, a small ad budget, or guest post outreach.
The alternative: direct reciprocity
If you want referral-style growth without the overhead, focus on direct reciprocity instead of tiered rewards. When someone shares your newsletter, thank them publicly or privately. When someone sends you a great subscriber, write them a personal note or give them a shout-out in your next issue. When someone consistently promotes your work, offer them something valuable—but make it contextual and personal, not part of a points system.
This approach doesn’t scale to thousands of referrers, but it doesn’t need to. Most newsletters see 80% of referrals come from fewer than 20 people. Build direct relationships with those people. Skip the automation, skip the platform fees, and skip the operational overhead.
Referral programs aren’t inherently bad, but they’re not free growth. Before you launch one, calculate what each referred subscriber will actually cost you—in money, time, and opportunity cost. If the math doesn’t beat your other acquisition channels, don’t build the program. Build the relationship instead.
What’s your experience with referral programs? Reply and let us know what worked—or what didn’t. And if you found this useful, subscribe to get future breakdowns delivered twice a week.

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.

1 July 2026
Productivity tools bill by seat—when solo means paying for five

Photo by Jonathan Cosens Photography on Unsplash

Most productivity and project management tools price themselves for teams. That’s fine when you have a team. But when you’re a solo operator wearing every hat, you’re often stuck paying for seats you’ll never fill—or locked out of features gatekept behind “Business” tiers that assume you have colleagues.
The seat-based pricing model makes sense for software companies. Predictable revenue per user, clean upsell path as teams grow. But it punishes the operator who just needs task management, a client portal, and a place to store SOPs without paying for five phantom users.
Where seat-based pricing hurts solo operators
Take Monday.com. The free tier caps at two seats and strips out timeline views, automations, and integrations. The next tier starts at $9 per seat per month, minimum three seats—so you’re paying $27 monthly even if you’re working alone. ClickUp offers a free solo plan, but custom fields and advanced automations require the Unlimited tier at $7 per member monthly, also with a minimum seat count depending on billing cycle.
Notion bucks this: $10 monthly for a Plus plan with no seat minimum, though collaboration features don’t matter much when you’re the only person in the workspace. Airtable charges $20 per seat monthly for the Team plan, but caps the free tier at 1,000 records per base—easily hit if you’re managing a content calendar, CRM, and product roadmap in one account.
The problem compounds when you add Slack (free tier works, but search history caps at 90 days), Loom (free tier limits videos to five minutes), or Figma (free tier allows three files). None of these tools are expensive at face value. But stack four of them, each assuming you’ll eventually add team members, and you’re paying $80 monthly for capabilities you’d use at 30% capacity.
Flat-rate and usage-based alternatives
A few tools sidestep seat pricing entirely. Obsidian charges $50 yearly for Sync, no per-user penalty. Raindrop.io charges $28 annually for Pro, one flat rate regardless of how many bookmarks you store or devices you sync. Superhuman is $30 monthly per inbox, not per person—so if you only manage one email address, you pay once.
Usage-based pricing works better in some categories. Zapier charges by task runs, not seats. Make (formerly Integromat) bills by operations. You pay for what you automate, not how many people could theoretically log in. Same with Postmark—pricing tiers based on email volume, not sender count.
But usage-based models have their own trap: unpredictable monthly costs. If you’re running a high-automation workflow and a Zap misfires in a loop, you can burn through your task allotment in hours. Seat-based pricing at least caps your bill.
When to pay for seats you don’t need
Sometimes the per-seat tax is worth it. If a tool saves you ten hours monthly and costs $40 for three seats you’ll never use, the arbitrage is obvious. The calculus breaks when free or flat-rate alternatives exist that do 90% of the job.
Example: Trello’s free tier handles unlimited boards and cards. The $5-per-seat Standard plan adds custom fields, advanced checklists, and bigger file uploads. If you don’t need those, don’t pay. But if you’re managing client work and need Butler automations (locked behind Standard), the per-seat charge becomes unavoidable.
Another angle: if you’re planning to hire or bring on a VA within six months, seat-based pricing makes sense. You’re paying for future capacity. But if you’re committed to staying solo or outsourcing project-by-project, you’re subsidizing features you won’t touch.
Audit what you’re actually using
Pull up your SaaS subscriptions. For each tool with seat-based pricing, ask: would a flat-rate or usage-based alternative cover the same workflow? If you’re paying for three Asana seats but only you log in, switch to Todoist ($5 monthly, flat) or keep using Asana’s free tier until you actually need Premium features.
If you’re paying for Slack because that’s what everyone uses, but you’re the only person in the workspace, switch to email or a basic task manager. If you’re on a ClickUp Team plan for one person, downgrade and use Notion or Airtable’s free tier until you hit a feature wall that genuinely blocks work.
The goal isn’t to avoid paying for software. It’s to pay for what you use, not for seats the pricing model assumes you’ll fill. Solo operators don’t need team collaboration features. We need tools that price for one, ship fast, and don’t upsell phantom capacity.
What productivity tools do you pay for solo? Reply with the one subscription you’d cut if a flat-rate alternative existed—I’ll feature a few in a future roundup.

1 July 2026
SEO content briefs bloat without distribution clauses
Photo by 1981 Digital on Unsplash

Content briefs have become the operational backbone of SEO-driven online businesses. You spec the keyword, set the word count, list the headers, and hand it off to a writer or AI tool. The piece gets published, indexed, and then… nothing happens.

The problem isn’t the research or the writing. It’s that most briefs treat distribution as someone else’s problem. They specify what to write but ignore how the content will reach readers beyond organic search. That gap costs you traffic, backlinks, and the compounding effects that turn a solid article into a referral engine.

Why briefs skip distribution

SEO content briefs evolved from agencies optimising for clients who measured success by rankings and organic sessions. The writer’s job was to satisfy search intent and hit keyword density targets. Distribution—social sharing, outreach, newsletter inclusion—lived in a separate swim lane, often handled by a different team or not at all.

That division made sense when content teams had 15 people. For solo operators and small teams, it’s structural debt. You’re the writer, the editor, the SEO lead, and the distribution manager. If the brief doesn’t prompt you to think about distribution during the planning phase, you’ll publish and move on. Two weeks later, the post has 40 pageviews and zero inbound links.

The fix isn’t to bolt a distribution checklist onto the end of your brief. It’s to bake distribution constraints into the content structure before you write.

What a distribution clause looks like

A distribution clause is a single section in your brief—usually 3–5 bullet points—that answers: How will this piece spread beyond Google?

Here’s what it includes:
- Primary shareability hook: What one sentence, stat, or contrarian claim will make someone want to link or quote this? Write it in the brief before you write the article.
- Outreach targets: List 3–5 specific sites, newsletters, or operators who’d care about this topic. If you can’t name them, the topic might be too broad or too niche.
- Social/email angle: How will you frame this for your own newsletter or social channels? If the article can’t carry a compelling subject line, it won’t drive repeat traffic.
- Republish or excerpt plan: Can a section of this piece work as a standalone post on Medium, LinkedIn, or a guest slot? Spec that upfront.
- Linkable asset: Does the article include a chart, data table, or tool comparison that others will reference? If not, add one.
These aren’t aspirational. They’re constraints. If you can’t fill out the clause, the brief isn’t ready.

When it changes what you write

Adding a distribution clause doesn’t just remind you to promote the piece. It reshapes the content itself.

Example: You’re writing a comparison of WordPress caching plugins. Your original brief specifies 1,800 words, keyword density for “WordPress caching,” and a table comparing five plugins. Standard SEO play.

Now add a distribution clause. Your outreach targets include two WordPress hosting review sites and a performance-focused newsletter. Your shareability hook is a load-time test showing one plugin slowing a site by 300ms under certain conditions. Suddenly, you’re not writing a neutral comparison—you’re writing a piece with a counterintuitive finding that those sites will want to link to. You structure the article to lead with the unexpected result, bury the methodology in an appendix, and pull the data table into a standalone image optimised for social sharing.

Same keyword. Same word count. Completely different content architecture, because you planned distribution before you wrote the first sentence.

How to retrofit existing briefs

If you’re already using a content brief template—whether it’s a Notion doc, a Google Sheet, or a prompt you feed into an AI tool—add a “Distribution” section immediately after “Target keyword” and before “Outline.”

For AI-assisted workflows, include the clause in your prompt. Example:

“Before outlining, identify: (1) the single most shareable claim in this piece, (2) three sites or newsletters that would link to it, and (3) one chart or data point that makes the piece link-worthy.”

If the AI or your own brainstorming can’t answer those three questions, either the topic needs refinement or the piece won’t spread. Kill it or rework it before you write 1,500 words.

The compound effect

Content with built-in distribution hooks doesn’t just get more initial traffic. It builds backlink velocity, which lifts your domain authority and helps other posts rank. A single well-distributed piece can pull up a category of related content.

Operators running lean don’t have the budget to publish 40 articles a month and hope three break out. You need a higher hit rate. Distribution clauses raise the floor. Every piece you publish has a plan to reach readers beyond the search algorithm.

Start with your next brief. Add the section. If you can’t fill it out, don’t write the article yet. That discipline alone will cut your content calendar by a third—and double the traffic on what remains.

One Two Three Send covers the tools, tactics, and trade-offs for running a content-driven online business. Subscribe to get the next piece in your inbox.
30 June 2026
Course platforms charge per student—here’s the breakpoint math

Photo: No machine-readable author provided. Avatar assumed (based on copyright claims). via Wikimedia Commons (CC BY-SA 3.0)

Most solo operators pick a course platform based on feature lists or interface design. Then they hit 200 students and realize they chose the wrong pricing model.
Course platforms use three billing structures: flat monthly fees, per-transaction percentages, and hybrid models that switch thresholds mid-growth. Each works beautifully at one scale and becomes expensive at another. The trick is knowing which breakpoint you’re approaching—and when to migrate before it costs you.
Flat fee vs. percentage: the crossover point
Teachable’s free plan takes 10% + $1 per transaction. The $59/month Basic plan drops that to 5%. The $159/month Pro plan eliminates transaction fees entirely.
If you sell a $99 course, Teachable’s free plan costs you $10.90 per sale. At 15 sales per month, that’s $163.50 in fees. The $159 Pro plan saves you $4.50—but only if you stay above that threshold every single month.
Podia charges $39/month with zero transaction fees at any volume. For the same 15 sales, you pay $39 flat. Teachable’s free tier costs you $163.50. That’s a $124.50 difference.
But scale to 100 sales per month. Podia still charges $39. Teachable Pro at $159 with no transaction fees costs $159. Now Podia wins by $120/month. The crossover happens around 18–20 sales per month for a $99 product on this comparison.
The math shifts with price point. A $29 course on Teachable’s free plan costs $3.90 per transaction. At 50 sales per month, that’s $195 in fees. Teachable Pro at $159 breaks even at 41 sales. Below that, you’re paying for a plan you don’t need yet.
Hybrid models hide the real cost
Thinkific’s free plan allows unlimited students but takes 10% + $1 per sale if you use their payment processing. Switch to the $49 Basic plan and fees drop to zero—but only if you bring your own Stripe account and pay Stripe’s 2.9% + $0.30.
That 2.9% never goes away. Thinkific’s $49 plan isn’t zero-fee; it’s shifted-fee. For a $99 course, Stripe takes $3.17. Add the $49 monthly platform cost, and your first 16 sales are just covering the subscription.
Kajabi charges $149/month with no transaction fees and includes email marketing, landing pages, and automation. If you’re paying for ConvertKit ($25/month) and Podia ($39/month) separately, Kajabi’s $149 starts looking reasonable at $64/month baseline. But only if you actually use the email tools. Most operators don’t migrate their list and end up paying for redundant infrastructure.
When to switch—and when to stay
Migration costs time. Expect two weeks to move a course with video hosting, email sequences, and payment workflows. If you’re within $30/month of breaking even on a new platform, wait. The opportunity cost of rebuilding usually outweighs the savings until the gap hits $50–75/month sustained over a quarter.
Transaction fees hurt most when your product price is low and volume is inconsistent. A $29 course selling 10 units one month and 60 the next makes flat-fee planning impossible. Percentage models smooth that volatility—you pay more in good months, less in slow ones.
Flat fees reward consistency. If you can count on 40+ sales per month, locking in a $99–159 plan with zero transaction fees caps your platform cost as a fixed line item. Your margin improves with every sale beyond breakeven.
The edge cases that break assumptions
Payment plan students count differently depending on the platform. Teachable charges transaction fees on each installment. Podia treats a payment-plan student as one enrollment and doesn’t re-bill you when the second charge processes. For a $297 course split into three $99 payments, that difference compounds.
Refund handling varies. Some platforms refund their transaction fee when a student requests a refund. Others don’t. If your refund rate sits above 8%, that leaked margin adds up.
Annual billing discounts look appealing but lock you in. Teachable offers two months free on annual plans. That’s $318 saved on the Pro plan—but only if you’re certain you won’t outgrow or downshift within 12 months. Most solo operators overestimate growth in year one and get stuck paying for capacity they don’t use until month nine.
Run your actual numbers. Take last quarter’s sales count, average product price, and refund rate. Model it against three platforms with different fee structures. The winner isn’t always the one with the best brand or the sleekest interface—it’s the one that costs least at your actual volume, today and six months from now.
What’s your current course platform costing you per student? Reply with your numbers—I’ll run the comparison and tell you if you’re leaving money on the table.

30 June 2026
WordPress transient bloat: when temporary data becomes permanent

Photo: Matinbeigi via Wikimedia Commons (CC BY-SA 4.0)

WordPress transients are supposed to be temporary. They’re API response caches, widget output buffers, and rate-limit trackers that plugins and themes store in your database with an expiration timestamp. The system promises automatic cleanup.
It doesn’t happen. Most WordPress installs accumulate thousands of expired transients that sit in the wp_options table indefinitely. The result: slower admin queries, bloated database exports, and—if you’re unlucky—autoload overhead that adds 200–500ms to every single page load.
What transients are and why they pile up
Transients live in wp_options as key-value pairs. Each transient gets two rows: one for the data (_transient_name) and one for the expiration timestamp (_timeout_transient_name).
WordPress checks the timeout when you request a transient. If it’s expired, the system returns false and is supposed to delete both rows. That deletion happens sometimes—but only when code explicitly requests the expired transient by name.
If a plugin stops using a transient key, or if a theme gets deactivated, or if an API endpoint changes and the cache key shifts, those rows stay forever. Multiply that across a dozen plugins over two years, and you’re carrying 8,000–15,000 expired transients.
I audited a client site last month running WooCommerce, Yoast, and a page builder. The wp_options table held 11,400 transient rows. Fewer than 200 were still valid. The rest dated back to 2024.
When bloat becomes a performance problem
Not all transient bloat is slow. If the transients aren’t autoloaded, they sit inert until a query scans the full table—during a plugin settings save, a database export, or a migration.
The danger zone is autoloaded transients. WordPress loads every autoloaded option into memory on every page load, whether you use it or not. Plugins that set transients with autoload enabled (some do this by accident) can inject 50–100 KB of dead data into every request.
Run this query to check autoloaded size:
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes';
If the result exceeds 800 KB, you’ve got a problem. Above 1.5 MB, every page load takes a measurable hit. Autoloaded transients are often the culprit, especially from caching plugins, social-share counters, and API widgets.
How to purge expired transients safely
Purging is a SQL operation. Before you run it, back up your database. Then use this query to delete expired transient pairs:
DELETE FROM wp_options WHERE option_name LIKE '_transient_%' AND option_name NOT LIKE '_transient_timeout_%' AND (SELECT option_value FROM wp_options WHERE option_name = CONCAT('_transient_timeout_', SUBSTRING(option_name, 12))) < UNIX_TIMESTAMP();
Most managed WordPress hosts—including BigScoots—let you run SQL directly from phpMyAdmin or via WP-CLI. If you’re on WP-CLI, install the Transient Command package:
wp package install wp-cli/transient-command
wp transient delete --expired
This is safer and faster than a manual query. It handles both the data row and the timeout row in one pass.
After purging, check autoload size again. On the client site I mentioned, autoloaded options dropped from 1.8 MB to 420 KB. Admin page load times improved by 340ms. Front-end caching masked most of the visitor-facing impact, but logged-in users saw faster dashboard responses immediately.
Prevention: audit transient usage in your plugin stack
The best fix is limiting transient creation in the first place. Audit which plugins are setting transients and whether they clean up after themselves.
Install the Query Monitor plugin and visit a few pages on your site. Open the “Database Queries” panel and filter for set_transient calls. Note which plugins fire the most transient writes. Then check whether those plugins offer settings to disable or reduce cache frequency.
Social share counters and related-post plugins are the worst offenders. Many set transients for every post or every API response, with 24-hour expirations that renew on every view. If you have 500 posts and a social-share plugin that caches Twitter and Facebook counts separately, that’s 1,000+ transients rotating daily.
Disable aggressive transient caching where you don’t need real-time data. Most operators don’t need share counts to refresh more than once a week.
If you run WooCommerce, audit your transient load after enabling or updating extensions. WooCommerce core is disciplined about transient cleanup, but third-party extensions frequently aren’t. One payment gateway plugin I tested left 400 expired session transients per day.
When to schedule purges
If you can’t eliminate the source, automate the cleanup. Add a monthly WP-CLI cron job or use a plugin like WP-Optimize (free version includes transient cleanup). Schedule it to run during low-traffic hours.
Don’t purge daily—it’s unnecessary and adds load. Monthly is enough unless you’re running a high-transaction WooCommerce store or a membership site with thousands of users generating session transients. In those cases, weekly makes sense.
One non-obvious tip: after a major plugin update or deactivation, manually purge transients. Plugin uninstallers rarely clean up their own transient keys. Deactivating a page builder or switching analytics plugins can leave hundreds of orphaned cache entries behind.
Want more hosting and WordPress infrastructure breakdowns? Subscribe to One Two Three Send for weekly operator-focused guides on the tooling that powers online businesses.

30 June 2026
ConvertKit broadcast scheduling: why UTC offset breaks send times

ConvertKit’s broadcast scheduler lets you pick a send time in your local timezone. But the platform stores that time as a UTC offset—and it doesn’t automatically adjust for daylight saving changes. If you schedule a 9am send in March and your region observes daylight saving in April, your broadcast will go out at 8am or 10am instead.

This isn’t a bug. It’s how the system handles timezone data. And if you’re running a daily or weekly broadcast, you won’t notice until your open rates drop or readers start asking why your send time shifted.

How ConvertKit stores scheduled send times

When you schedule a broadcast for 9:00am Eastern Time, ConvertKit doesn’t store “9am Eastern.” It converts that to a UTC offset—currently UTC-4 during daylight saving, UTC-5 during standard time—and locks in the absolute UTC timestamp.

If you schedule in winter (UTC-5) for a March send, that 9am broadcast is stored as 2pm UTC. When daylight saving kicks in and your local clock springs forward, your region is now UTC-4—but the broadcast still fires at 2pm UTC, which is now 10am local time.

The reverse happens in autumn. A broadcast scheduled during daylight saving will arrive an hour early once standard time resumes.

This affects any operator in a region that observes daylight saving: most of the US and Canada, parts of Europe, Australia, and a handful of other countries. If your timezone doesn’t shift, you won’t hit this issue.

When this actually breaks your workflow

One-off broadcasts are fine. You schedule, you send, you move on. The problem surfaces with recurring sends or templates you duplicate week after week.

If you run a Tuesday morning briefing and schedule it every Monday night for a 7am send, you’ll duplicate last week’s broadcast, update the content, and leave the time slot untouched. That works until the clocks change—then your 7am send becomes 6am or 8am, depending on direction.

Engagement suffers. A 6am send might hit inboxes before your audience wakes up, pushing your email down the stack. An 8am send competes with the morning rush and office distractions. Either way, open rates drop, and you won’t know why unless you check the actual delivery timestamp in your sent folder.

How to avoid the offset trap

The simplest fix: manually verify your send time after every daylight saving transition. Mark your calendar for the second Sunday in March and the first Sunday in November (US dates), and check every scheduled or recurring broadcast. If the time shifted, update it.

If you’re scheduling more than a week out, pick your send time on the day you’re actually sending—not in advance. That way, the UTC offset reflects the current timezone rules.

For operators running daily sends, consider switching to a relative schedule instead of an absolute one. ConvertKit doesn’t natively support “send X hours after signup” for broadcasts, but you can replicate the behaviour with a sequence: create a one-email sequence, set the delay to zero, and trigger it with a segment or tag. That way, the send time is always relative to subscriber activity, not a fixed UTC timestamp.

Another option: use a timezone that doesn’t observe daylight saving. If you schedule in UTC or Arizona time (which stays on Mountain Standard year-round), your send time never shifts. Your local reference changes, but the broadcast fires at a consistent absolute hour. This works if your audience is global or if you don’t care about hitting a specific local time—just a consistent daily slot.

What other platforms do differently

Some ESPs handle this better. MailerLite stores send times as a timezone identifier (like America/New_York) rather than a UTC offset, so the platform automatically adjusts for daylight saving. You schedule 9am Eastern, and it stays 9am Eastern year-round, regardless of offset changes.

Others, like Mailchimp, let you pick a subscriber’s local timezone for sends—so a 9am broadcast goes out at 9am in each recipient’s region. That’s useful for global lists, but it spreads your send window across 24 hours, which complicates analytics and real-time engagement tracking.

ConvertKit’s approach isn’t wrong—it’s just literal. The platform does exactly what you tell it: send at this UTC timestamp. If you want a different timestamp after the clocks change, you have to say so.

If timezone handling matters to your workflow—especially if you’re running daily sends or operating across multiple regions—test your platform’s behaviour before committing. Schedule a broadcast six months out, note the UTC offset, and check again after a daylight saving transition. If the local time shifted, you’ll need a manual or automated workaround.

Got a question about email tooling or workflow automation? Reply to this email—we cover reader questions every Sunday.

29 June 2026
AI prompt versioning: why your best prompts disappear
Photo by Marija Zaric on Unsplash

You spend twenty minutes refining a prompt until it finally produces exactly what you need. You use it twice, close the tab, and three weeks later you’re starting from scratch because you can’t remember the exact wording that worked.
This happens to every solo operator using AI tools. The platforms aren’t built for prompt reuse—they’re built for one-off conversations. Chat histories pile up, search fails, and your best work vanishes into a scroll you’ll never revisit.
The solution isn’t a fancy tool. It’s a lightweight versioning habit that takes thirty seconds per prompt and saves you hours of rework.
What prompt versioning actually means
Versioning is just saving iterations with timestamps and outcomes. When a prompt works, you save it. When you tweak it, you save the new version alongside the old one—not instead of it.
Most operators save prompts in a note somewhere, but they overwrite the previous version every time they improve it. That works until you realize the new version broke something the old one handled correctly. Without the previous iteration, you’re guessing at what changed.
A versioned prompt log looks like this:
- v1 (2026-06-15): “Write a product description for [product]. Include benefits and features.”—Output was too generic.
- v2 (2026-06-15): “Write a 150-word product description for [product]. Lead with the primary benefit. List three features as short bullets.”—Better structure, still missing voice.
- v3 (2026-06-18): “Write a 150-word product description for [product] in a conversational, second-person voice. Lead with the primary benefit in one sentence. Follow with three feature bullets (10 words each). End with a single-sentence call to action.”—This one works.
You don’t need software. A plain text file, a note in Notion, or a Google Doc works. The format matters less than the habit of saving before you overwrite.
When to version and when to move on
Not every prompt deserves versioning. Throwaway requests—”summarize this article,” “rewrite this sentence”—aren’t worth logging. Version the prompts you’ll reuse: content templates, data extraction patterns, formatting instructions, analysis frameworks.
The trigger is simple: if you’ll want this exact output shape again, version it. If you spent more than five minutes refining it, version it. If it’s part of a repeatable workflow, version it.
I version prompts for weekly newsletter intros, product description formats, and SEO meta-description generation. I don’t version one-off research questions or casual rewrites.
One non-obvious benefit: versioning forces you to notice what actually changed. When you write “v4: added constraint about word count,” you’re documenting what moved the needle. That makes future edits faster because you know which variables matter.
Where versioning breaks down
The biggest failure mode is over-organizing. Operators build elaborate tagging systems, folder hierarchies, and metadata schemas that take longer to maintain than the prompts are worth. The file rots because updating it feels like work.
Keep it flat. One document, chronological entries, minimal structure. Search works fine. If you’re spending more than thirty seconds logging a prompt, you’re doing too much.
The second failure mode is saving prompt text without saving context. A prompt that says “generate five headline options” is useless six months later if you don’t remember it was for LinkedIn posts, not email subject lines. Add one sentence of context: what it’s for, what input format it expects, what output it produces.
Third: versioning doesn’t replace testing. A prompt that worked in Claude in June might produce different results in July after a model update, or fail completely if you switch to a different AI tool. Version numbers aren’t guarantees—they’re breadcrumbs back to something that worked once.
The thirty-second logging habit
When a prompt works, immediately copy it into your log with three pieces of information: the version number (just increment from the last one), today’s date, and one sentence about what it does or what changed. That’s it.
If you’re working in Claude or another AI assistant, you can store prompts directly in a running note and paste them in when you need them. If you’re using API-based tools, keep a separate file in the same directory as your scripts.
For operators running content workflows, pair this with a simple naming convention. I prefix mine with the content type: product-description-v3, newsletter-intro-v7, meta-description-v2. That makes search faster and keeps related prompts grouped.
One more trick: when you version a prompt, test it twice before you archive the previous version. Run it on two different inputs and confirm the output quality holds. If it doesn’t, you still have the old version to fall back on.
Want more practical AI workflow tactics? Subscribe to One Two Three Send for weekly breakdowns of what actually works—no hype, no fluff.

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.
29 June 2026

► Necessary Cookies Always Active

Necessary cookies enable essential site features like secure log-ins and consent preference adjustments. They do not store personal data.

► Functional Cookies Remark

Functional cookies support features like content sharing on social media, collecting feedback, and enabling third-party tools.

► Analytical Cookies Remark

Analytical cookies track visitor interactions, providing insights on metrics like visitor count, bounce rate, and traffic sources.

► Advertisement Cookies Remark

Advertisement cookies deliver personalized ads based on your previous visits and analyze the effectiveness of ad campaigns.