Category: Productivity

Most solo operators running online businesses are paying for between three and seven software subscriptions they either forgot about or no longer need. The average waste sits between $80 and $200 per month — enough to cover a year of decent hosting or a professional email service.

This isn’t about extreme frugality. It’s about operational hygiene. Every unused subscription is a small leak in your business, and those leaks compound over time. Here’s how to audit your stack, cut the bloat, and build a system that prevents it from creeping back.

Pull your transaction history from every payment method

Start with your credit cards, PayPal, and any business accounts you use for software purchases. Download the last six months of transactions and filter for anything that repeats monthly or annually.

Look for:

• Charges under $20 — these are easy to miss and often auto-renew without warning.
• Annual renewals you forgot about. A $200 charge in May for a tool you stopped using in February hurts twice.
• Services billed through aggregators like Paddle or FastSpring, which obscure the vendor name on your statement.

If you use a tool like Stripe for your own revenue, check your outgoing subscriptions too. Some operators set up recurring payments for white-label services or API access and forget they’re still active.

Match every charge to a current use case

Open a spreadsheet. List every recurring charge, the amount, the billing cycle, and — most importantly — the last time you actually used it.

For each subscription, ask:

• Have I logged in during the past 30 days?
• Does this tool solve a problem I still have?
• Could I replace this with a free alternative or a tool I’m already paying for?

Common offenders include:

• Design tools you used once for a logo refresh (Canva Pro, Adobe Creative Cloud).
• SEO or analytics platforms you check twice a year (Ahrefs, Semrush).
• Social media schedulers for platforms you stopped posting to (Buffer, Publer).
• AI assistants you signed up for during a launch, then replaced with something else.

If you haven’t touched it in 60 days and can’t articulate a specific upcoming use case, kill it.

Downgrade before you cancel

Some tools offer free tiers that cover 80% of what you need. Before you cancel outright, check if a downgrade makes sense.

Examples:

• Most email platforms (MailerLite, Brevo, Beehiiv) have generous free plans for lists under 1,000 subscribers.
• Analytics tools like Plausible and Fathom offer lower-tier plans if you’re tracking fewer than 10,000 monthly pageviews.
• Hosting providers often let you move to a cheaper plan if your traffic dropped or you consolidated sites.

Downgrading keeps your account active, preserves your data, and gives you a fallback if you need to scale back up. Canceling outright sometimes means losing historical data or having to re-integrate from scratch later.

Set a calendar reminder to repeat this every quarter

Subscription bloat isn’t a one-time problem. New tools creep in during launches, experiments, or when you’re troubleshooting something urgent. Three months later, you’ve forgotten why you signed up.

Block 30 minutes every quarter to repeat this audit. Use the same spreadsheet. Update your current charges, check usage, and cut anything that’s drifted out of your workflow.

If you’re using a tool like Notion or Airtable to manage your business operations, add a “Software Stack” table with columns for cost, renewal date, and last-used date. Set up an automation (via Zapier or Make) to flag anything that hasn’t been marked “used” in 45 days.

One rule to prevent future bloat

Before you sign up for any new paid tool, add a note in your calendar for 60 days out: “Still using [Tool Name]?”

If the answer is no, cancel before the second billing cycle hits. Most SaaS tools hook you with a generous trial or a strong first-month use case, then fade into the background as your workflow shifts. The 60-day check catches that drift before it costs you six months of fees.

Running lean doesn’t mean running cheap. It means every dollar you spend has a job. If a tool isn’t doing that job, cut it and redirect the budget to something that moves your business forward.

Want more operator-focused breakdowns like this? Subscribe to One Two Three Send and get one article like this in your inbox every week — no fluff, no filler, just the tools and tactics that matter for solo operators running content businesses.

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.

Zapier gives you two ways to handle conditional logic: filters and paths. They sound similar—both let you control what happens based on specific conditions—but they work differently, cost differently, and solve different problems.

If you’ve ever built a Zap that runs but does nothing, or one that burns through tasks faster than expected, you’ve probably picked the wrong tool for the job.

What filters do (and when they’re the right choice)

A filter is a checkpoint. It evaluates a condition and either lets the Zap continue or stops it immediately. If the condition isn’t met, the Zap ends—no further steps run, and Zapier counts it as a task used.

Filters work best when you want to exclude certain triggers from running the rest of your workflow. For example:

• Only send a Slack notification if a form submission includes “urgent” in the subject line
• Only add a contact to your CRM if their email domain isn’t gmail.com or yahoo.com
• Only log a new row in Google Sheets if the order total is above $100

The key trait: you’re saying “if this isn’t true, do nothing.” You’re not offering an alternative action—you’re just stopping early.

One non-obvious benefit: filters are psychologically clean. When you review a Zap history and see tasks that were filtered out, you know exactly why they didn’t proceed. There’s no ambiguity, no hidden branch you forgot about.

What paths do (and when you need them instead)

Paths let your Zap fork into multiple routes based on conditions. Each path can have its own set of actions, and Zapier will execute only the path whose conditions are met. If none match, the Zap can either stop or fall through to a default path.

Paths are the right tool when you want to route a trigger to different outcomes. For example:

• If a new subscriber chooses “weekly digest,” add them to MailerLite list A; if they choose “daily brief,” add them to list B
• If a support ticket is tagged “billing,” create a Stripe invoice; if it’s tagged “technical,” post to a dev Slack channel
• If a Typeform response selects “enterprise,” send to your CRM and notify sales; if it selects “self-serve,” send a welcome email via Postmark

The structure is “do X if A, do Y if B”—not “do X or do nothing.”

Paths count as one step in your Zap, but each action inside a path counts separately toward your task limit. If you have three paths and only one executes, you’re only billed for the actions in that path—not all three.

The mistake that burns tasks: using paths when a filter would do

Here’s the pattern I see most often: someone builds a Zap with two paths. Path A has five actions. Path B is empty, labeled “Do Nothing.”

That’s a filter dressed up as a path. And it’s wasteful.

Every time the Zap runs, Zapier evaluates the path logic—even if the result is to do nothing. You’re adding complexity and making your Zap history harder to read. Worse, if you later add actions to Path B “just in case,” you risk doubling your task usage without realizing it.

The fix: if one outcome is “do nothing,” use a filter instead. Reserve paths for workflows where every branch does something.

How they affect your task count (and your bill)

Both filters and paths count as tasks, but in different ways.

A filter counts as a task every time the Zap runs, even if the filter stops it. If 100 triggers come in and 90 are filtered out, you’ve used 100 tasks—because Zapier had to evaluate all of them.

A path counts as one task for the path step itself, plus one task for each action that runs inside the chosen path. If you have a three-path Zap and only one path executes two actions, you’ve used three tasks total (path evaluation + two actions).

This means paths can be more efficient if you’re routing high-volume triggers to different outcomes. But if you’re just trying to exclude certain triggers, a filter up front will keep your history cleaner—even if the task count is the same.

One rule of thumb that makes the decision easy

Ask yourself: if this condition isn’t met, should something else happen, or should nothing happen?

If the answer is “nothing,” use a filter.
If the answer is “something else,” use paths.

That’s it. You don’t need to overthink routing logic, task costs, or Zap readability. That one question will steer you to the right tool almost every time.

Got a Zapier workflow that’s burning tasks faster than expected? Subscribe to One Two Three Send and get one operator-focused automation breakdown every week—no fluff, no beginner tutorials, just the details that matter when you’re running a real business.

Most solo operators treat video communication as binary: either you schedule a Zoom call or you send a text message. But there’s a third option that’s quietly become infrastructure for small teams and consultants — async video tools like Loom.

The question isn’t whether async video is useful. It’s when it replaces a live call without losing clarity, and when it just creates more work.

When async video actually saves time

Loom works best when the communication is one-directional with optional follow-up. That means:

• Product walkthroughs or onboarding. If you’re showing a client how to use your system, a 4-minute Loom beats a 30-minute call. They can pause, rewatch, and ask clarifying questions async.
• Feedback on creative work. Instead of writing “the CTA button needs more contrast,” you record your screen, talk through the issue, and show exactly what you mean. The recipient doesn’t need to be there.
• Status updates or reporting. If you’re walking through analytics, project progress, or a content calendar, async video delivers context without requiring everyone to block 30 minutes.
• Bug reports or technical issues. Showing what’s broken — cursor movements, console errors, page behaviour — is faster and clearer than writing it out.

The pattern: you’re delivering information, not negotiating or brainstorming. The recipient needs to understand, not co-create.

When live calls still win

Async video breaks down when the conversation is two-way, ambiguous, or high-stakes.

• Sales calls or discovery. You can’t read body language or adjust your pitch in real-time via Loom. Async video works for demos after a discovery call, not instead of one.
• Conflict resolution or difficult feedback. Tone is hard to control in async video. If the message could be misread as critical or defensive, do it live.
• Strategy or brainstorming. If the goal is to iterate on ideas together, async video adds latency without adding clarity. A 15-minute Zoom call beats three rounds of recorded back-and-forth.
• Complex negotiations. Pricing discussions, contract terms, partnership structure — these need real-time give-and-take.

The test: if the other person will need to ask three follow-up questions, just schedule the call.

The hidden cost of async video

Loom’s free plan caps videos at 5 minutes; the paid tier (Loom Business at $12.50/user/month when billed annually) removes the limit. But the real cost isn’t the subscription — it’s response latency and context-switching.

When you send a 6-minute Loom, you’re asking the recipient to:

1. Notice the notification
2. Find 6 uninterrupted minutes
3. Watch at 1x or 1.5x speed
4. Decide whether to reply async or schedule a follow-up

If they’re juggling client work or deep focus time, that Loom might sit unwatched for 48 hours. Compare that to a text message (skimmable in 15 seconds) or a scheduled call (pre-committed time).

Async video works when the recipient has slack in their schedule. If they’re underwater, it becomes a new tab they feel guilty about.

Loom vs. Zoom: the operator’s rubric

Here’s the decision tree:

Use Loom when:

• You’re explaining something visual (UI, design, analytics dashboard)
• The recipient doesn’t need to respond immediately
• You’d otherwise write 8+ paragraphs with screenshots
• You’re delivering information, not seeking consensus

Use Zoom (or a phone call) when:

• The topic is ambiguous or exploratory
• You need to read tone or body language
• The conversation will have multiple back-and-forth turns
• The stakes are high (sales, conflict, contracts)

Use neither — just text — when:

• The message is under 3 sentences
• It’s purely informational (link, date, yes/no)
• You don’t need tone or visual context

One non-obvious Loom tip

Enable emoji reactions in your Loom settings (under Preferences > Video Settings). Viewers can drop a thumbs-up or checkmark at specific timestamps without needing to reply. For simple feedback loops — “Does this make sense?” or “Approve this approach?” — it’s faster than waiting for a written response.

Also: enable auto-transcription (it’s on by default in paid plans). Recipients can skim the transcript before deciding whether to watch. That alone cuts response time in half for some people.

Async video isn’t a Zoom replacement. It’s a text-message replacement for things that need a screen. Use it when you’d otherwise write a novel with screenshots. Skip it when the conversation needs to breathe.

Want more workflow breakdowns like this? Subscribe to One Two Three Send — we compare tools, tactics, and trade-offs for operators running online businesses. No fluff, no listicles, just the decision-making rubric.

Zapier’s table formatter is one of those features that looks simple in the UI but behaves unpredictably once you start pushing real data through it. It’s designed to take a blob of text—CSV rows, tab-delimited lines, or even scraped HTML tables—and turn it into structured rows you can loop over or push into a spreadsheet.

It works. Sometimes brilliantly. But it also fails in ways that are hard to debug, and it adds latency to every Zap run. If you’re automating anything that touches customer data, order logs, or content pipelines, you need to know when this feature is the right tool and when it’s a liability.

What the table formatter actually does

The formatter takes unstructured or semi-structured text and tries to parse it into rows and columns. You tell Zapier what your delimiter is (comma, tab, pipe, semicolon), whether your data has headers, and how many columns to expect. It returns an array of line items you can iterate over in a looping Zap or map directly into Google Sheets, Airtable, or a database.

It’s useful when you’re pulling data from tools that don’t offer native integrations—scraped tables from a webpage, exported CSVs from legacy software, or bulk data from an API that returns everything as a single text block.

But here’s the catch: Zapier’s parser is not smart about edge cases. If your data contains a comma inside a quoted field, or if a row has fewer columns than expected, the formatter will either skip the row, split it incorrectly, or throw a silent error that doesn’t surface until you notice missing records three days later.

When it’s the right tool

The table formatter shines in a few specific scenarios:

• You’re working with clean, predictable CSVs. If your data source is a well-structured export with consistent delimiters and no nested commas or line breaks, the formatter works fast and reliably.
• You need to parse fewer than 100 rows per run. Zapier charges task usage for every loop iteration. If you’re parsing 500 rows, that’s 500 tasks. The formatter itself counts as one task, but looping over the output will burn through your plan quickly.
• You’re prototyping. If you’re testing a workflow and need to see whether the data structure is usable, the formatter is faster than writing a Code step. You can always replace it later with Python or JavaScript once the logic is proven.

When to skip it and use a Code step instead

If your data is messy, inconsistent, or large, you’re better off writing a Code by Zapier step with Python or JavaScript. Here’s why:

Speed. The formatter adds 2–4 seconds of latency to every Zap run. A Code step that does the same parsing with Python’s csv module runs in under a second, even with hundreds of rows.

Error handling. The formatter fails silently on malformed rows. A Code step lets you log errors, skip bad rows gracefully, or send yourself a Slack alert when something breaks.

Flexibility. If your CSV has quoted fields, escaped characters, or inconsistent column counts, the formatter will choke. A Code step gives you full control over how to handle those cases. You can strip extra whitespace, coalesce missing columns, or even validate data types before passing rows downstream.

Here’s a bare-bones Python snippet that replaces the table formatter for most use cases:

import csv
from io import StringIO

input_text = input_data.get('csv_text')
reader = csv.DictReader(StringIO(input_text))
rows = [row for row in reader]

return {'rows': rows}

That’s it. You get an array of dictionaries, one per row, with column names as keys. You can loop over it, filter it, or transform it before sending it to your destination app.

One non-obvious tip: use line item groups cautiously

If you’re using the formatter inside a loop (for example, parsing multiple CSV files in a single Zap run), Zapier will try to batch the output into line item groups. This sounds convenient, but it makes debugging nearly impossible. You can’t inspect individual rows in the Zap history, and if one row in the batch fails, the entire group fails without telling you which record caused the error.

If you’re dealing with anything mission-critical—customer orders, payment logs, subscriber imports—avoid line item groups entirely. Parse once, loop once, and log each iteration so you can trace failures back to the source row.

Want more workflow breakdowns like this? Reply with the automation you’re trying to build—we’ll cover it in a future issue.