Every solo operator has the same Sunday-evening realization: the week was fine, but two full days of it were paperwork. Not client work — the work about the work. Invoices assembled by hand. A report rebuilt from the same CSV as last month. An inbox triaged one guilty click at a time.
The automation advice on the internet is useless here, because it's written for teams. "Integrate your stack" assumes you have a stack. What a one-person business needs is narrower: five small, boring programs that each remove a recurring chore and keep running for years with zero maintenance. Here they are, with the honest version of when to build each and when to just pay for a tool.
A note on the philosophy before the list: the automations worth writing are the ones where the chore is recurring, the rules are stable, and the data is yours. If any of the three is false, you're building a hobby, not a tool.
1. Invoicing: from memory to ledger
The chore. Making the invoice is five minutes. The expensive part is everything around it: remembering which number comes next, remembering who hasn't paid, remembering to follow up at day 30 instead of day 52.
The automation. A small CLI or script that owns the whole lifecycle: assigns the next invoice number, renders the document (text and a branded HTML you can PDF), and stores everything in a local SQLite file. Then three more commands do the real work: list shows what's open, overdue shows what's late with exit code 1 so a weekly cron can nag you, and summary totals billed, collected, and outstanding. The follow-up problem disappears because "who owes me" becomes a command, not a memory.
Build or buy? If your invoicing volume is a handful a month and your needs are "professional PDF, numbered, tracked," build or use a simple script — the paid invoicing apps are priced for businesses that need online payments and client portals, and you'll pay $15–30/month forever for features you don't touch. Buy the moment you need card payments on the invoice itself or multi-currency; that's genuinely fiddly and not worth owning.
2. Reporting: one command from CSV to answers
The chore. Export the CSV from the bank / the shop / the time tracker, open a spreadsheet, re-derive the same five numbers, paste them somewhere. Done monthly, it's forty minutes. Skipped, it's why you don't know your own numbers.
The automation. A script that takes any CSV and produces a report: row counts, per-column stats, top categories, min/max/mean/median on numeric columns, and a monthly rollup when it finds a date column. The trick is tolerance — it has to survive the real world's UTF-8 BOMs, ragged rows, currency symbols, and "(1,234.00)" negatives, because bank exports are where clean data goes to die. Output Markdown for your notes or HTML for sending.
Build or buy? Build, firmly. This is the single best return on an evening of scripting a solo operator will ever get, because it converts "I should look at the numbers" into a ten-second command, which means you'll actually do it. The buy alternative is a dashboard SaaS that wants to hold your data hostage for $50/month. Decline.
3. Email triage: the digest instead of the inbox
The chore. Opening the inbox to find one thing and surfacing forty minutes later having answered nothing. The inbox is an interface designed by other people's priorities.
The automation. A script that reads your local mail (mbox or a Maildir from a sync tool) and renders a single digest page: senders, subjects, dates, grouped and ordered the way you think — by person, by thread, with the newsletters and notifications corralled into their own section. You triage the digest over coffee, decide what deserves a reply, and only then open the actual mail client. The inbox stops being a slot machine.
Build or buy? It depends on where your mail lives. If you can get it into local files, the digest is a clean build — no API keys, no third party reading your correspondence. If your mail lives only behind a webmail UI, buy: a client with good filtering, or a service that does summaries. What you should not do is give a random "email assistant" startup full access to your correspondence to save twenty minutes a day. The privacy math on that is terrible and stays terrible.
4. Price watching: know when your costs move
The chore. Your suppliers, hosting providers, and the tools you resell all change prices quietly. You find out from the invoice, which is one month too late to matter.
The automation. A small watcher: a list of URLs and CSS selectors (or just page snapshots), fetched on a schedule, compared to the last seen value, with a note when something moves. Two rules make it a good citizen instead of a nuisance: it checks robots.txt and stays away where told, and it fetches politely — hourly at most, usually daily. Price pages do not change by the minute; hammering them is how scripts get blocked and, honestly, how they deserve to be.
Build or buy? Buy if you're watching dozens of competitor SKUs across JavaScript-heavy storefronts — that's a real product category and the tools earn their fee. Build if your list is the ten or twenty pages that actually affect your costs. The polite-fetching requirement is exactly why a homemade one beats a browser extension for this: you control the cadence and the ethics.
5. Backups: verified, or it didn't happen
The chore. You know you should. That's the whole chore — the gap between knowing and having.
The automation. A script that copies the directories that matter to a second disk or a mounted remote, and — this is the part everyone skips — verifies. Every copied file gets a checksum, written into a manifest, and the next run re-verifies a sample. A backup you've never checked is a hope, not a backup. The manifest also answers the two questions that matter during a bad day: when did this last run, and did it succeed. Scheduled nightly via cron or a systemd timer, it becomes invisible, which is the correct state for backups.
Build or buy? Both, layered. Use a real off-site service for catastrophe insurance — fire and theft don't care about your second disk. Add the local verified script for the common case, which is "I need yesterday's version of this file right now." The local script restores in seconds and doesn't need an internet connection; the off-site service is for the day the office burns down. One of each, and you can stop thinking about it.
The rules that keep automations honest
Across all five, the same disciplines decide whether the tool lasts:
- Standard library only where possible. Every dependency is a future breakage. Python's stdlib covers files, CSV, SQLite, email, HTTP, and hashing — which is all five tools above.
- Data stays on your machine. The ledger, the reports, the mail digest, the manifests. Local-first isn't paranoia; it's why the tools still work when a startup pivots or shuts down.
- Fail loudly, not silently. The overdue checker exits 1 when it finds something. The backup script writes a manifest line you can check. An automation that fails quietly is worse than none, because it teaches you to trust a broken thing.
- Automate the remembering, not the judgment. The digest doesn't answer your email; it stops the inbox from deciding your morning. The watcher doesn't renegotiate your contract; it tells you the price moved. Judgment is the part you're paid for.
Where to start
Start with whichever chore you did most recently by hand and resented — that's the one with proven demand. Write the smallest version that removes it, use it for a month, and only then make it nicer. The tools that survive are the ones that were useful when they were ugly.
If you'd rather not write them yourself, these five are exactly the tools in the Solo Automation Toolkit ($49): invoice.py, csvreport.py, maildigest.py, pricewatch.py, and backup.py — standard-library-only Python, tested end to end, with the verification log in the zip. They're the versions I run myself. But the build-vs-buy notes above hold either way: take the philosophy even if you never take the toolkit.