DEV Community: The Solo Operator

My coding agent shipped a bug to three pages it wasn't touching

The Solo Operator — Mon, 27 Jul 2026 19:19:47 +0000

The spec was simple: restyle the buy button on the product detail pages. Nothing else. The agent implemented it, I skimmed the diff, it looked like a button change, and I shipped it. Within a day I had a report that checkout, cart, and one subscription page had all quietly deformed. The button lived in a shared component, and restyling it for one page had restyled it everywhere that component was used. I've paid for that exact mistake twice, on two different redesigns, months apart, because the first time I fixed the symptom instead of the process.

I run a store with no other engineers. Everything that ships to production goes through a coding agent I treat like a contractor with commit access and a probation period that never ends. My job was never to write the feature. My job is to be able to say, with confidence, "this change is contained to what it claims to touch" — and for a long time I couldn't actually do that, I was just skimming a diff and hoping the file list looked reasonable.

The naive move, and why it's expensive specifically for a store

The tempting shortcut when you're shipping alone is to let the agent push straight to production for anything that looks small — "it's just a copy change," "it's just a button." A production e-commerce site doesn't forgive that shortcut the way an internal tool would. A checkout bug costs money by the minute it's live, not by the hour someone notices it. So the bar for "small enough to skip review" needs to be near zero, not near "looks small in the diff summary."

The process that actually holds up has five stages, and I don't skip any of them for anything beyond an actual typo fix.

1. Spec what must NOT change

Before the agent touches anything, I write the change in plain language, and — this is the part I used to skip — I write down explicitly what must stay identical. "Restyle the buy button on PDPs; checkout, cart, and subscription pages must be pixel-identical." That second sentence is the one that would have caught my original incident before it happened, because it forces the agent (and me) to think about blast radius before writing a line of code, not after a bug report.

2. Grep before you restyle anything shared

This is the single rule that came directly out of two incidents, and it's now non-negotiable: before modifying any shared component, the agent greps every usage of it across the codebase and lists them in its change summary, with a one-line impact note per usage. Most of my production incidents trace back to exactly this pattern — a component gets restyled for the page someone's thinking about, and it silently deforms every other page that happens to reuse it. Once you've been burned by this twice, you stop trusting "it's a small change" as a category and start asking "what else uses this file" as a reflex, every time.

Pitfall I hit: The shared-component leak happened to me twice on completely different redesigns — a checkout re-theme and, months later, a product-page redesign — and the second time it happened I realized it wasn't bad luck, it was a missing line in my checklist; when the same class of bug recurs on unrelated projects, that's a process gap, not an unlucky week.

3. Review with a fresh agent session, not the one that built it

The mistake that undid my early review process for a while was subtler than the shared-component problem: I had the same agent session that implemented the change also review it. The review was a formality every time, because the agent "knew what it meant" — it reviewed its own intentions, not the actual diff. It couldn't be skeptical about a decision it had just made in good faith five minutes earlier.

The fix is to spin up a genuinely fresh session with no memory of the implementation's reasoning, hand it only the spec and the diff, and frame it explicitly as a skeptical reviewer. That framing matters more than it sounds like it should. "Review this as a senior engineer looking for problems" produces a completely different quality of output than "check if this diff matches the spec." Here's how reviewing a diff you didn't write actually differs from writing it in the first place:

	Implementer's view	Fresh reviewer's view
Context	Knows what it meant to change	Only knows the stated spec
Bias	Confirms its own intent	Hunts for contradictions to the spec
Blast radius	Assumes contained if it "felt" contained	Explicitly checks every file touched
Business rules	May not have been told them explicitly	Should be handed them as a checklist

The reviewer's job is specific, not general: hunt for unintended file changes, shared-component blast radius, hardcoded values that should have been config, and violations of business invariants — discount schedules, pricing logic, anything that's a rule rather than a preference. "Looks fine to me" is not a verdict. "Approve" or "request changes, with reasons" is.

4. Preview, then smoke test, then production

Nothing goes straight from review to live. It goes to a preview deployment first, and for anything touching money — checkout, cart, subscription flows — I run a full mystery-shopper pass through the actual purchase flow on that preview URL before it goes anywhere near production. This step catches the class of bug that a code review genuinely can't: things that are syntactically fine and logically wrong, like a discount tier that computes correctly for four subscription cadences and silently wrong for the fifth.

Only after that does it go to production. And even then the job isn't done — the agent re-verifies the live site immediately after deploy, as an actual customer would experience it, and takes before-and-after screenshots. "Deployed successfully" and "deployed correctly" are different claims, and only one of them is worth trusting without a look.

5. Every incident becomes a permanent checklist line

My deploy checklist is nine lines long. Every line on it is a scar. That's not a rhetorical flourish — I mean it literally traces back to a specific incident that cost me something, and the checklist is the only reason I haven't repeated any of them a third time. When something goes wrong anyway, despite the process, it gets a short postmortem written into the checklist immediately, while the details are fresh, not summarized weeks later from memory.

Impact: Agency-equivalent development for a store like mine would run somewhere in the low thousands of dollars a month; my tooling costs a fraction of that, and the review process itself has caught revenue-touching bugs before they reached production at least once a quarter — each one worth more on its own than the month's entire tool bill, which is the actual argument for keeping a review pass instead of skipping it to save twenty minutes.

What review actually looks like when you can't write the code

The honest answer to "how do you review a diff you didn't write and couldn't have written yourself" is that you don't review the code quality. You review containment and invariants. Does the file list match the stated scope. Does anything outside that scope change. Does the change respect the business rules that were true before the change and need to stay true after it — pricing, discount math, anything a customer-facing number depends on. That's a review any operator can learn to do competently without being able to write the feature themselves, and it's the actual skill that makes solo-founder shipping survivable rather than a slow-motion liability.

Here's the prompt pair I actually run — one for the implementer, one for the reviewer, always as two separate sessions:

Change spec: [plain-language description]. Must-not-change: [list].
Implement on branch [name]. Requirements:
- Before touching any shared component, grep all usages and list
  them in your summary with an impact note each.
- Respect business invariants: [discount schedule, pricing rules].
- Output: diff summary by file, shared-component impact list,
  and preview URL.
Then STOP. A separate review pass and my approval happen before
any production deploy.
[Reviewer session prompt:] Review this diff against the spec above
as a skeptical senior engineer. Hunt specifically for: files
changed beyond scope, shared-component side effects, and invariant
violations. Verdict: approve / request changes, with reasons.

One more habit that came from a genuinely dumb loss: I once had an in-progress redesign wiped out because a working directory got deleted while it was still the active workspace for a session. Commit early, push often, and treat "delete this directory" as an action that needs the same suspicion as a production deploy, because from a data-loss standpoint it basically is one.

None of this makes shipping alone as safe as shipping with a team. It makes the failure modes cheap and specific instead of expensive and vague — which, for a solo operator, is the actual bar worth clearing.

Originally published on my site: https://methezone.github.io/solo-operator-playbook/agent-deploys-review-pass.html

All 30 workflows are written up with prompts and failures. Five are free, in full: the sampler.

I let an agent do my books. It still has to ask first.

The Solo Operator — Mon, 27 Jul 2026 19:14:44 +0000

The first time I let an agent loose on my company's transaction list, it categorized a hospital bill as "staff welfare." I have no staff. I am the staff. It saw a medical merchant, saw a business card, and made a confident, wrong, entirely plausible-looking leap. Nobody caught it for two weeks, because the whole point of automating bookkeeping is that you stop looking at every line.

That single line item is why I now run a rule I'd tell any solo operator to adopt before anything else: an agent categorizing your books must ask before it guesses. Not "flag things it's not sure about eventually." Ask, structurally, every single month, before anything gets written into the real ledger.

The problem auto-categorization doesn't solve

Every bookkeeping SaaS ships with its own auto-tagging, and it's bad in a specific, predictable way: it categorizes based on merchant type, not context. "Convenience store" becomes... what? Office supplies? A staff meal? Personal groceries picked up on the way home? The tool doesn't know, so it picks something, and if you don't look, that something sits in your books until an accountant or an auditor asks about it.

Left alone, this becomes a quarterly archaeology project. You open the books three months in, find a pile of uncategorized or badly-categorized transactions, and either burn an evening reconstructing what each one was for, or pay your accountant to guess, which is worse, because now someone with no context is making tax-relevant decisions about your business.

The fix isn't a smarter auto-tagger. It's separating the categorization work into three tiers of confidence and treating each one differently.

High, medium, low — and only one of those gets applied automatically

Here's the actual monthly workflow I run, a few days after month-end once transactions have settled:

I keep a one-page categorization rulebook in the agent's memory: recurring merchants mapped to categories (a specific packaging supplier goes to "materials," cloud hosting goes to "infrastructure"), a few amount-based heuristics, and an explicit escape hatch for anything the rulebook doesn't cover.
The agent opens the bookkeeping tool, pulls everything uncategorized, and works through it with a confidence label on each line: high (it matches the rulebook exactly), medium (a reasonable inference, but not a rule match), low (genuinely unsure).
High-confidence items get applied directly to the books. Medium items go into a short approval list with a one-line reason each. Low items come to me as plain questions — merchant, amount, date — usually five to ten a month, not fifty.
Every decision I make on a medium or low item gets written back into the rulebook. The unsure pile shrinks over time because the rulebook actually learns from me, instead of me re-answering the same judgment call every month.
Before anything's final, the agent checks its own arithmetic: categorized count plus remaining-uncategorized count has to equal the total number of transactions imported that month. If those numbers don't add up, something got silently dropped, and that's worth catching before it becomes a hole in the filing.

Pitfall I hit: Before I forced the confidence column into the output, the agent would categorize with total, unwarranted certainty — that hospital bill filed as staff welfare is the example that made me change the process, and the uncomfortable part is how plausible it looked sitting in a spreadsheet next to fifty correctly-tagged rows; a confidence label plus a mandatory low-confidence escape hatch fixed the vast majority of this on its own.

Why the audit trail matters more than the speed

The month-end session used to take three to five dreaded hours. Now it's twenty to thirty minutes of me approving or correcting a short list. That speed gain is real, but it's not the part I'd defend if someone pushed back on the whole idea of an agent touching the books. The part I'd defend is the audit trail.

Every automated system that touches money needs to answer one question cheaply: if someone asks "why does this number look different," can you reconstruct the answer in minutes, or does it take an hour of digging? My first pass at this had no answer — exclusions and category changes went into the books with no marker, and when my accountant asked why a total had shifted, reconstructing it took real time I didn't have.

The fix was boring and it worked: every adjustment the agent makes gets a consistent, searchable memo attached — a fixed keyword plus a short reason. Not a note only I'd understand six months later. A memo my accountant, or a future version of me with no memory of this month, can search for and reconstruct instantly. Speed without a trail just moves the archaeology project from "which category" to "why did this change," and that second version is worse because it involves someone else's trust in your books.

Impact: The direct cost saving is real but modest — my accountant's cleanup billing dropped and clean categorization made a later tax-deduction review straightforward, worth a few hundred dollars a year at minimum — but the bigger, harder-to-price value is what a tax audit doesn't find later, because every exclusion and category decision has a reason attached to it instead of a shrug.

The personal-vs-business problem is a separate job

Categorization and personal-expense auditing feel like the same task and they are not, and mixing them into one session degrades both. Categorization asks "what bucket does this business expense belong in." The audit asks a completely different question: "did a personal expense leak into the business books at all." When your company card lives in your personal wallet — which for a lot of solo founders it does — pharmacy runs, dinners that weren't really meetings, and one-off personal purchases slide into the same statement as your suppliers and hosting bills. Each one is small. Over six months they add up into a real compliance risk.

I run this as a separate, twice-a-year pass, with a written policy defined before the agent touches anything:

Bucket	Examples	Agent's action
Clearly personal	clinics, salons, entertainment venues, home utilities	flag for exclusion
Clearly business	suppliers, hosting, shipping	leave alone, no flag needed
Ambiguous	convenience stores, solo meals, general retail	leave untouched, list separately

The critical rule is that ambiguous items are left alone by default. You exclude only what's unambiguously personal. My first attempt got this backwards in both directions — one pass flagged every solo lunch as suspicious, a looser second pass missed something as obvious as home gas bills. It took two iterations of the written policy, not the prompt, to converge on something reasonable. The policy decides, not the agent's judgment call in the moment, because the policy is the thing you can defend to an accountant and the agent's in-the-moment judgment is not.

I still review every flagged line myself before anything gets excluded from the books. This is a twenty-to-forty-minute session, not a formality, because the tax consequences land on me, not on the agent.

What your accountant actually needs

None of this is really built for me. It's built so that twice a year I can hand a package to someone with far less context than I have and have them trust it without a long phone call. That package needs three things, and none of them are "a bigger spreadsheet":

A clean categorized ledger where every automated decision has a stated confidence level and, for anything adjusted, a searchable reason attached.
A short, explicit list of what was excluded as personal and why, so nobody has to reconstruct it from memory.
Totals that reconcile — imported count, categorized count, excluded count, all adding up to something an accountant can check in one pass rather than trusting blindly.

Here's the actual prompt template I run every month, unedited from what's in my agent's memory:

You are my bookkeeper's assistant. Open [bookkeeping tool] and list
all uncategorized transactions for [month]. Categorize each using
this rulebook: [paste rulebook]. For each item output:
merchant | amount | date | category | confidence (H/M/L) | reason.
Apply H items directly. Queue M items for my approval. Ask me about
L items individually. After applying, verify: categorized + remaining
= total imported, and report the three numbers. Flag anything that
looks like a personal expense separately — do not categorize those.

The last line in that prompt is doing more work than it looks like. It keeps the two jobs separate even when they're running in the same tool, in the same month, on the same list of transactions. Categorization and personal-expense auditing use different policies, different review cadences, and different levels of scrutiny from me, and the moment you let an agent conflate them, you lose the thing that made this whole exercise trustworthy in the first place: a clear, defensible answer to "why does this number look the way it does."

The agent got faster at this every month. What actually matters is that it got more honest about what it didn't know, and that it never once got to decide what happens to something it wasn't sure about.

Originally published on my site: https://methezone.github.io/solo-operator-playbook/ai-bookkeeping.html

All 30 workflows are written up with prompts and failures. Five are free, in full: the sampler.

I stopped writing proposals and started shipping demos

The Solo Operator — Mon, 27 Jul 2026 19:13:24 +0000

A prospect once replied to my outreach with the line every service business dreads and craves in equal measure: "send me something and I'll take a look." I used to spend an evening on that reply — a PDF with a scope, a timeline, some past-work screenshots, a price. It was fine. It was also, I eventually realized, indistinguishable from what any of my five competitors would send in response to the same line. Everyone's PDF looked competent. Competent doesn't win anymore, because competent is now the free, instant output of any model a competitor happens to open.

That's the actual shift worth naming. Proposals used to be a costly signal — spending a night on a document proved you were serious. Now that cost has collapsed to nearly zero for everyone, which means a well-written proposal proves nothing except that you, too, have access to a language model. The only thing left that still separates you from the pile is a proposal that contains work you've actually already done, specific to them.

So that's what I started sending instead: a small, real, working demo, built for that one prospect, attached to a one-page proposal instead of replacing it.

Why this is suddenly cheap

This strategy existed before agents — good salespeople have always known that showing beats telling. What changed is the economics. A custom demo used to mean a few days of a developer's time you couldn't spare for every warm lead, so you rationed it for the biggest deals only. A coding agent turns "build a thin, real prototype against this specific prospect's actual page or data" into a few hours of agent time plus maybe an hour of my review. That's cheap enough to do routinely, but it is not free, and pretending it's free is exactly how you end up doing unpaid client work disguised as sales effort. More on that below.

Scoping it in hours, not days

The playbook has a specific order, and skipping steps is where it goes wrong.

First, a browser agent audits the prospect's public surface — their storefront, their product pages, their content cadence, their reviews, whatever your service actually touches — and produces a findings list. Not vague observations. Specific, verifiable ones: "your product page has no FAQ section," "your most-repeated review complaint is about shipping time and no response addresses it," each with a screenshot or a quote attached, not a guess.

Second, from that findings list, scope exactly one demo buildable in roughly four hours of agent time that makes two or three of those findings tangible using the prospect's actual product, actual copy, actual data. Not a generic template with their logo pasted on. A redesigned mockup of their real page. A working prototype dashboard running on their public numbers. A sample deliverable built from their actual content. The specificity is the entire point — a generic demo is just a fancier PDF.

Third, the proposal itself gets short, because the demo is now doing the persuading: their problem stated in their own numbers, a link to the demo, scope, timeline, price, and one paragraph on how the engagement would actually run. One page, not five.

	Text-only proposal	Demo-backed proposal
Cost to produce	An evening of writing	A few hours of agent time + ~1 hour of my review
What it proves	I can write a proposal	I can already do the thing, on your actual data
Competitive differentiation	Low — everyone's is similarly polished now	High — most competitors won't have shipped anything
Right for	Small, low-stakes deals	Deals worth 20-50x the hours invested

When not to do this

This only makes sense above a deal-size threshold, because the hours aren't free even if they're cheap. My rule is roughly 20 to 50 times the agent-and-review cost — below that, a solid templated proposal is the right tool, and building a demo for a small deal is just expensive theater that doesn't pay for itself even at a decent close rate. There's also a category of prospect where a demo reads as presumptuous rather than impressive: mocking up someone's brand and product without asking first can land badly, especially where showing up uninvited with "I redid your website" reads as overstepping rather than helpful. I now ask a light permission question in the first reply — something like "mind if I mock something up on your actual page?" — before building anything. It costs nothing, and the answer is itself a useful buying-intent signal: enthusiastic yes, lukewarm yes, or silence all tell you something before you've spent a single agent-hour.

Prospect: [company/URL]. Service: [what I sell]. Step 1: audit
their [store/site/content] and list 5-8 specific, verifiable
findings with evidence (screenshot/quote/URL each — no guesses).
Step 2: propose ONE demo buildable in ~4 hours that makes 2-3
findings tangible using THEIR actual product/data/content.
Step 3: after my approval, build it at [staging URL].
Step 4: draft a one-page proposal: their problem (their numbers),
demo link, scope, timeline, price [range], working process.
Tone: [voice doc]. Do not send anything.

Where it goes wrong

The findings list is where trust gets built or destroyed in the first ten seconds of a prospect's attention, and it is also where an agent's confidence outruns its accuracy fastest. One early audit confidently reported that a prospect "had no email capture" on their site — the capture form existed, sitting behind a popup the agent's browsing session had already dismissed before it looked. Sending that claim to a real prospect would have been an instant credibility loss, not a minor inaccuracy.

Pitfall I hit: Every finding in the audit now requires attached evidence — a screenshot, an exact quote, a URL — and I personally verify each one before it goes anywhere near a prospect, because a single wrong claim about someone's own business, stated confidently, undoes every bit of credibility the demo was supposed to build.

The second failure is scope creep, and it's a subtler trap because it feels like generosity in the moment. My second demo, built without a hard stop, quietly turned into something like 60% of the actual proposed project — built for free, before any contract existed. The fix wasn't willpower, it was a mechanical constraint: a four-hour cap on the build, and a framing repeated in the prompt itself — prove capability, don't deliver the value. The demo's job is to make the prospect believe you can do the work. It is not supposed to be the work.

I still read everything before it goes out — the findings list especially, since an agent's wrong claim about a stranger's business is the one failure mode with no good recovery — and I send it personally rather than letting any part of the send itself run unattended. Whatever happens with the deal, win or lose, it goes into the same follow-up tracking I use for everything else, and I ask directly what actually decided it. That answer feeds back into the next findings list and the next demo scope, which is the only reason this keeps getting better instead of just staying a nice trick I did once.

Impact: A demo-backed proposal costs roughly an hour of my own review and tailoring on top of the agent hours, against a full evening for a weaker text-only version, and on a small honest sample my close rate on demo-backed proposals runs roughly double what text-only proposals get — which for a one-person operation means a single incremental win in a quarter is enough to change the shape of the whole quarter.

The underlying logic generalizes past sales, and it's worth stating plainly: whenever the artifact you'd normally produce to prove seriousness has gotten cheap for everyone to fake, the only remaining signal is proof that can't be faked cheaply — something that only works because it's actually true. A demo running on someone's real data is one of the few things left in that category.

Originally published on my site: https://methezone.github.io/solo-operator-playbook/working-demo-proposals.html

All 30 workflows are written up with prompts and failures. Five are free, in full: the sampler.

I let an agent hunt government grants every morning

The Solo Operator — Mon, 27 Jul 2026 18:59:59 +0000

Last spring I found out, by accident, that my country had been running a storefront-improvement subsidy for three months. Direct cash, no strings beyond receipts, aimed at exactly the kind of small physical retail expansion I was quietly considering. The application window closed in nine days. I found it because a supplier mentioned it in passing, not because I'd been looking. I hadn't been looking, because looking is a full-time habit nobody has time for on top of running the actual business.

That is the real shape of the grant problem. It isn't that the money doesn't exist. It's scattered across a dozen portals, each with its own posting cadence, its own PDF-only application forms, and a window that opens and closes in a few weeks with no advertising beyond the portal itself. Missing 90% of it isn't a competence failure. It's what happens when the monitoring cost is higher than any one founder can sustainably pay, every single day, forever.

So I stopped trying to be the monitor. I built a daily routine instead: a browser agent that sweeps the portals every morning before I'm awake, and reports back only what's new.

What the sweep actually does

The mechanics are unglamorous, which is exactly why they work. Every morning, the agent visits a fixed list of grant and subsidy portals — national, regional, and industry-specific — and diffs what it finds against what it saw yesterday. New listings get evaluated against an eligibility profile I keep in persistent memory: legal entity type, registered region, industry classification, headcount, revenue band, and the documents I already have on hand versus the ones I'd need to chase down.

The profile has to be built from actual registration documents, not from what I assume about my own business. My mailing address and my registered business address are in different cities, and the first two drafts the agent produced were quietly disqualified before they started because the program filtered on registration region, not the address in my email signature. Grant portals don't care where you get your mail. They care what's on the paper you filed with the government.

The second piece of the profile is a filter policy, written down explicitly, because an agent left to its own judgment about what counts as "opportunity" will happily surface things that aren't. Mine excludes anything that isn't direct cash: no networking events, no exposure programs, no prize-less pitch competitions, no pure mentoring tracks. Those all show up in a raw sweep of any government portal, dressed up in the same official language as a $40,000 cash subsidy, and if you don't exclude them explicitly the agent will keep reporting them as if they were real leads.

Ranking, not just listing

A list of programs is not useful on its own. What made the sweep worth ten minutes a day instead of a research project was forcing every match through the same scoring pass, on the same axes, every time:

Axis	What it captures
Cash amount	Actual funding on offer, net of any required matching contribution
Fit	How closely the program's stated criteria match my eligibility profile
Probability	Realistic odds given competition, past cycles, and how narrow the criteria are
Self-pay requirement	Whether I have to spend first and get reimbursed, or the funding is up front
Prep burden	Hours of documentation and drafting required to apply
Deadline	Days remaining, weighed against prep burden

Amount alone is a trap. A $70,000 program with a 20-page business plan requirement and a 40% self-pay match is often worse than a $5,000 program with a one-page form and no match, once you price in the hours. The scoring forces that comparison instead of letting the biggest number win by default.

Fit scoring needed a second fix. Early on, almost everything came back scored 4 or 5 out of 5 — the agent was being agreeable, not honest. Adding one instruction changed that completely: require the agent to cite the specific eligibility criterion behind every score. The moment it has to point at an actual sentence in the program's requirements rather than a vibe, the scores get real, and the 4s and 5s that remain are ones I trust.

Deadlines against the actual posting, not the summary

This is the part I'd flag hardest if I were writing this for someone just starting. Grant portals get re-posted, extended, and occasionally mis-dated by aggregator sites that scrape them secondhand. An agent that reads a deadline off a third-party summary page and puts it on your calendar has told you something that might be wrong by days in either direction, and a missed government deadline isn't the kind of mistake you get to retry.

Pitfall I hit: The deadline that matters is the one on the official posting itself, verified at the source, not the one on a news aggregator or a summary email — I now require the agent to screenshot or quote the exact line from the original portal page before any date goes on my calendar, because a deadline off by even one day on a government submission is not a mistake you get a second attempt at.

Every new match that clears the filter gets its deadline added to my calendar automatically, with a few days of reminder buffer built in. That alone solved most of the actual miss rate — not the research, the remembering.

From match to draft

For anything scoring high enough to be worth the hours, the agent goes further than reporting. It drafts the actual application: the form fields, a business narrative pulled from a reusable company-story document I keep in memory, and a mapping of required attachments to the documents I already have filed. What used to be three to eight hours of form-wrangling per application becomes a draft sitting in a folder, ready for me to read.

Here's the prompt I run every morning, roughly as written:

Daily grant sweep. Portals: [list]. My eligibility profile and
filter policy are in memory. For each NEW program since yesterday:
name | funding type | cash amount | deadline | eligibility verdict
(cite the specific criterion) | fit score 1-5 | one-line reason.
EXCLUDE: networking, exposure, mentoring-only, prize-less programs.
For any program scored 4+, draft the application into [folder]:
filled form fields, narrative sections using my company-story doc,
and required-attachment mapping. STOP before any submit action.
Add deadlines to my calendar with a 3-day buffer.

Why I still click submit myself

The gate is not decorative. A government application is a legally binding statement about your business, and the agent's confident draft is only as current as the eligibility profile behind it. My business registration gained a new industry classification at some point, and an outdated profile silently skipped programs I'd actually qualified for — the opposite failure, but proof the profile needs a quarterly reality check against the actual documents, not against my memory of them.

The more dangerous failure runs the other direction. After months of clean drafts, the temptation to let the agent submit on its own is real and it grows with every successful cycle. I haven't done it, and the one time I came close to loosening that rule, the draft in front of me contained an eligibility claim that had quietly gone stale. The gate didn't just catch a paperwork error. It caught me getting comfortable.

Impact: The sweep costs about ten minutes of review a day in exchange for what used to be an impossible daily research habit, and each application draft it produces saves three to eight hours of form-filling; the ceiling is the real story though, since individual small-business grants in my market run from roughly two thousand to seventy thousand dollars equivalent, and a single approval can fund years of the tooling this whole system runs on, while every miss costs nothing but a few minutes of reading.

I track every application in a plain pipeline — drafted, submitted, result — so nothing falls through after the fact. That part matters more than it sounds like it should. Grant programs rarely tell you their decision on a schedule you can predict, and a submitted application you've stopped thinking about is exactly the kind of open loop that used to live in my head before any of this existed. Now it lives in a spreadsheet instead, and the only thing that still requires me personally is the one click that was always going to require me personally.

Originally published on my site: https://methezone.github.io/solo-operator-playbook/agent-grant-scanning.html

All 30 workflows are written up with prompts and failures. Five are free, in full: the sampler.

Six things I stopped trying to automate

The Solo Operator — Mon, 27 Jul 2026 18:57:59 +0000

I spent most of a month building a listing-creation workflow for my products, and I rebuilt it four times before I admitted the actual problem: my listing format was still changing every week. I wasn't automating a process. I was automating a moving target, which meant every automation run needed its own manual fix afterward, which is a worse position than just doing the task by hand in the first place. I eventually killed the workflow, did listings manually for six more weeks until the format genuinely stopped changing, and only then rebuilt it — in an afternoon, correctly, because by then there was actually something stable to automate.

Running a company with agents instead of employees makes automation feel free. It isn't. Every workflow you build is a small system you now own — it can break, drift, and quietly mislead you, and someone has to notice when it does. That someone is still you. The real skill isn't finding things to automate. It's noticing, early, which things will cost you more automated than manual. Here are six specific shapes that keeps showing up.

1. The one-off wearing a recurring-task costume

Some tasks feel like they'll happen again because they're annoying, not because they actually will. I've caught myself starting to build a workflow for something that, on reflection, I was only ever going to do once or twice — a specific one-time filing, a single vendor negotiation, a report I needed exactly once for exactly one audience. The tell is asking, honestly, "will this happen ten more times in the next year." If the answer is no, or "maybe, vaguely," the correct move is to just do it, by hand, this one time. Building infrastructure for a task that never recurs is pure sunk cost with no future payoff, and the build time alone often exceeds just doing the thing.

2. Work where the judgment IS the job

Some tasks look like execution but are actually judgment wearing execution's clothes. Final creative taste calls are the clearest example I have. Brand voice drift is cumulative and close to invisible in any single decision — one slightly-off caption, one slightly-generic product description — but it compounds silently until the brand doesn't sound like anything anymore. An agent can draft ten variations and even rank them by a stated rubric, but the actual decision of "this is the one that sounds like us" is the job itself, not a step before the job. Automating that step doesn't save time on the real work; it replaces the real work with something that resembles it.

Pitfall I hit: I let a semi-automated version of a partner email go out that was factually perfect and relationally tone-deaf — every fact in it was correct, and it still cost more goodwill to repair than a hundred fully-automated tasks had saved me that quarter, which is what convinced me relationship weight needed to be a first-class filter question, not an afterthought.

3. Anything where being wrong is expensive and you can't easily check

This is the quiet one, because it doesn't fail loudly. I once automated a data-entry task and didn't build a fast way to spot-check its output. Errors accumulated unseen for a month before I noticed. The lesson that stuck: if you can't verify the output faster than you could have just done the task, you haven't automated the task, you've automated the risk. Automation without cheap verification isn't a shortcut, it's a delayed bill with an unknown amount on it.

The filter question I now ask explicitly: can I check this output in meaningfully less time than doing it would take? If checking takes as long as doing, the automation adds a step, not a savings.

4. Relationship-critical communication

Some counterparties can tell when it isn't really you, and it matters to them specifically that it is. A wholesale partner notices. A long-standing customer notices. These aren't tasks where the content needs to be correct — it's where the source of the message is part of the message. I keep an explicit "manual on purpose" list for this reason, and key relationship conversations are permanently on it, not because an agent can't draft convincing text, but because the value of the interaction is partly "this person took the time," and that value evaporates the moment it's detected as manufactured, whether or not it actually was.

5. Anything whose inputs change shape every time you do it

Automation assumes a stable, repeatable shape to the input. When the underlying process is still evolving — a form that changes fields, a listing format you're still iterating on, a workflow you've done differently each of the last three times — automating it means rebuilding constantly, and each rebuild costs more than the manual version would have. My rule now: run the task manually until it's boring. Boring means stable. If you're still discovering new edge cases on manual run number four, you don't have a process yet, you have an experiment, and experiments don't automate — they get concluded first.

Signal	Ready to automate	Not ready yet
Last 3 manual runs	Identical steps	Different each time
Output check	Faster than doing the task	As slow as doing the task
Failure cost	Reversible, cheap	Irreversible or expensive
Counterparty	Doesn't care who did it	Specifically values you
Frequency	10+ times a year	Once or twice, ever

6. Vanity automation you never actually read

This is the most embarrassing one because it's not a failure of judgment about the task — it's a failure to notice the automation stopped earning its keep. A routine that reports the same forty items every single day, with no distinction between "nothing changed" and "here's what's new," trains you to stop reading it within a couple of weeks. At that point it isn't automating anything. It's producing a report that exists so you can feel like something is being monitored, while nothing is actually being watched, because the one person who was supposed to read it stopped.

The fix isn't complicated: every recurring routine has to be diff-based and has to explicitly say "nothing new" when nothing's new, instead of silently repeating yesterday's list. A routine that tells you "2 new since yesterday" stays read for months. A routine that dumps the same forty rows every morning gets ignored within two weeks, and an ignored automation is worse than no automation, because it creates the false confidence that something is covered when nothing is.

Impact: Running an honest filter before building anything kills roughly a third of my automation ideas before they cost a single hour of build time — that's real hours a year not spent on workflows that would have rotted, and the near-misses I did catch late (the unstable listing rebuild, the tone-deaf partner email) suggest the things I chose not to automate protected more value than several of the things I did build.

The filter, in practice

Before I build anything now, I run it through five questions, out loud, honestly, before writing a line of workflow logic:

Automation decision review for: [task]. Answer honestly:
1) Expected repetitions over 12 months?
2) Has the process been identical the last 3 manual runs?
3) Can output be verified in <20% of the time doing it takes?
4) Worst-case failure: reversible? At what cost?
5) Does anyone on the other side value ME doing this personally?
Recommend: automate fully / automate edges only (specify which) /
keep manual, with reasoning. If "automate," also state its
maintenance cost and which weekly-audit check will catch its decay.

The "automate edges only" answer is the one I underuse the least and value the most. Most of the tasks on my manual-on-purpose list aren't fully manual in practice — an agent still assembles the research, drafts the first pass, and organizes the evidence. What it doesn't do is make the final call or sit in the seat where a relationship or a legal outcome depends on it being genuinely me. A legal dispute is the clearest version of this: an agent can build the timeline, gather the evidence, and draft the numbers, but the strategy and every submission stay human, always.

The number of workflows worth running isn't "as many as possible." It's the number whose upkeep you can actually audit on a regular basis without it becoming its own job. Past that number, the correct move is pruning, not adding — and the six patterns above are just the fastest way I've found to recognize, before I spend the week building it, which candidate is going to end up on the pruning list anyway.

Originally published on my site: https://methezone.github.io/solo-operator-playbook/when-not-to-automate.html

All 30 workflows are written up with prompts and failures. Five are free, in full: the sampler.

The one rule that lets me run a company with no employees

The Solo Operator — Mon, 27 Jul 2026 18:53:07 +0000

There's a specific bad day every solo founder running agents pictures at least once: money leaves an account that shouldn't have left it, a legal document gets filed that shouldn't have been filed, a public post goes out that shouldn't have gone out. Not because the agent was malicious. Because it was confident, and confidently wrong, and nobody was standing between the decision and the action. That fear is the reason most founders keep AI at "chat toy" status — useful for drafting an email, too dangerous to trust with anything that touches the real world.

The mistake in that fear is the word "trust." You do not need to trust an agent to run a company on one. You need to design a system where trust was never the load-bearing part. That system is a lot simpler than it sounds: agents draft, I approve, agents execute. The entire discipline of running a company with zero employees comes down to enforcing that one sentence well enough that it never quietly stops being true.

Sorting actions by whether you can take them back

The first real decision isn't about any particular workflow. It's a classification you make once, up front, and apply everywhere: how reversible is this action, really?

Some things are freely reversible — drafts, internal research notes, a categorization that's easy to relabel later. Those need no gate at all; gating them just adds friction with no safety benefit. Some things are reversible but cost something to undo — a code deploy, a listing change, a bookkeeping entry that's wrong. Those get process gates: a review pass, a check against known-good state, a second look before anything ships. And some things are not reversible, full stop, or reach outside your own systems into the world: sending money, submitting a government application, posting publicly, emailing a customer, agreeing to a contract. Those get a hard human gate, with no exceptions carved out for routine-feeling cases, because "this one's routine" is exactly the sentence that precedes most gate failures.

Class	Examples	Gate
A — freely reversible	Drafts, internal notes, research summaries	None
B — reversible with cost	Deploys, listing edits, expense categorization	Process gate: review pass, invariant check
C — irreversible or external	Payments, government submissions, public posts, customer emails, contracts	Hard human gate, always

The temptation is to let category C shrink over time as an agent proves itself reliable in category B. Resist that. Reliability in one class says nothing about the next one, and the cost of being wrong in class C is not symmetric with the cost of being wrong in class B.

One gate is not enough

A gate that lives only as an instruction in a prompt — "draft this, never send it" — will eventually fail, not because the model is malicious but because language is ambiguous and instructions get reinterpreted under pressure. I lost one that way: an instruction to "handle the customer reply" got read as license to send a response, when what I meant was closer to "handle" as in "prepare a response for me to send." Handle isn't send. It's close enough, under the wrong reading, to be genuinely dangerous.

That's why the gate has to exist in three separate layers, each one catching what the layer before it might miss:

Prompt-level: the instruction itself says "draft, never send," stated plainly in every task.
Workflow-level: the tooling itself stages the draft somewhere that sending requires a manual click from me — not a matter of the agent choosing to stop, but a mechanical fact about how the tool works.
Platform-level: the agent structurally lacks the permission — a read-only API key instead of a write one, a spend cap set inside the ad platform itself, no bank transfer authority on the account at all.

Any one layer can fail on its own. All three failing on the same action, at the same time, is a much smaller probability, and that's the actual point of stacking them. You're not trying to build a perfect gate. You're trying to make sure no single point of failure is load-bearing.

The "never list," written down and loaded every time

Beyond the reversibility classification, there's a short, explicit list of absolute prohibitions I keep in memory and load with every task, regardless of workflow: never enter my national ID number or a card's security code anywhere, never sign or consent to a contract, never final-submit a government application, never send money, never tell a customer something is finished before verified state actually confirms it's finished.

That last one deserves its own callout, because it's the failure mode that shows up most often and is easiest to miss:

Pitfall I hit: A click is not a confirmation — after any state-changing action, the only thing worth trusting is what the resulting screen actually shows, not what the agent's own summary claims happened, because agents report actions while reality reports outcomes, and those two things silently diverge more often than feels comfortable to admit.

I've had a refund reported as processed that the payment gateway had actually blocked behind a limit I didn't know existed. I've had a listing update reported as live that hadn't actually rendered on the storefront. I've had an API call reported as successful that had, in fact, returned a 404 the whole time. None of those were caught by trusting the agent's report. All of them were caught by looking at the actual resulting state before believing anything was done.

Standing guardrails (load with every task):
- Action classes: A) reversible → proceed; B) costly-reversible →
  follow the process gate for that workflow; C) irreversible
  (payments, submissions, public posts, customer comms, contracts,
  deletions) → PREPARE ONLY, stage for my explicit approval.
- Never list: [your absolute prohibitions].
- A click is not a confirmation: after any state-changing action,
  verify the resulting state on screen before reporting it done.
- If you are unsure which class an action is, treat it as C and ask.
Violations of this block are the only unforgivable failure mode.

Make the gate cheap or you'll erode it yourself

Here's the part that surprised me most: the biggest threat to a gate isn't the agent going rogue. It's me, months in, deciding the gate has become unnecessary friction. After enough clean grant-application drafts in a row, auto-submission started to feel obviously safe — it wasn't a big leap, it felt like removing a formality. The week I came closest to actually loosening that rule, the draft sitting in front of me for review contained an eligibility claim that had quietly gone stale since the profile was last checked against my real registration documents. The gate didn't just catch a paperwork error that time. It caught my own complacency, at the exact moment complacency was about to become policy.

The practical fix is making the gate cheap enough to operate that skipping it never looks tempting on a busy day. Batched digests instead of one-off pings. One-tap approvals instead of multi-step review. Pre-formatted views — a dashboard, a staged draft folder — so reviewing costs seconds instead of minutes. An expensive gate gets bypassed by exactly the person the gate was supposed to protect: you, on the day you're too busy to do it properly.

Impact: Gates cost roughly 20 to 40 minutes of my day in approvals, which is now genuinely the core of my job, and it's a good trade for the 4 to 6 hours of doing they replace — the real payoff is that the downside of any single agent failure is bounded at minutes of review instead of an actual incident, which is the property that makes it sane to run all the rest of this on a business with real money in it.

Testing the gate like you test a backup

The last habit worth stealing is the one that feels the most paranoid and pays off the most reliably: periodically ask an agent to attempt a gated action in a sandbox, on purpose, and confirm it refuses or stages rather than executes. A backup you've never restored from isn't a backup, it's a hope. A gate you've never watched fail closed is the same thing. Every actual near-miss gets written down and traced back to the specific layer that should have caught it — a missing checklist line, not a bad agent — because the discipline that matters here isn't punishing the agent for the mistake. It's making sure the same mistake has no path back into the system.

None of this is about distrust of the technology. It's closer to the opposite: the gates are what make it safe to hand over as much as I actually have, because the cost of any one thing going wrong stays bounded no matter how much surface area the agents are covering. That bound is the entire reason a company with zero employees can carry real money, real customers, and real legal exposure without it being reckless.

Originally published on my site: https://methezone.github.io/solo-operator-playbook/approval-gates.html

All 30 workflows are written up with prompts and failures. Five are free, in full: the sampler.

The five primitives I run a whole company on

The Solo Operator — Mon, 27 Jul 2026 18:51:33 +0000

I run a consumer product company by myself. Physical inventory, two storefronts, multiple marketplaces, subscription billing, bookkeeping, tax filings, government paperwork, content in two languages, and a codebase that ships to production most weeks. Headcount: one. Not "one plus a virtual assistant." One.

Three years ago this was not possible. It is also not possible today by keeping a chat window open and asking it questions. The thing that changed is not that models got smarter in the abstract. The thing that changed is that agents can now operate software the way an employee does: click through admin dashboards, fill in government forms, read email, write and deploy code, remember what happened last Tuesday, and run on a schedule without being asked.

Once that is true, most of what a small company's staff does becomes a workflow you can write down, hand to an agent, and audit weekly instead of doing daily.

Everything I run sits on five primitives. Tool names will churn every six months. These won't.

1. A browser-operating agent

An agent that drives a real browser session with my real logins: seller dashboards, banking portals, government sites, ad platforms, email.

This is the highest-leverage primitive, and it is the one most people skip. The reason is uncomfortable: roughly 90% of small-business operations live behind a login wall with no usable API. Your marketplace seller console. Your payment provider's merchant dashboard. Your country's tax portal. The grant program that still ships application forms as attachments.

If your automation strategy requires an official API for everything, you will automate the 10% that already had one, and you will still be doing the other 90% by hand at 11pm.

The browser agent is my hands. It logs in, navigates, reads what's on screen, fills forms, downloads documents, and reports what it found.

2. A coding agent

An agent that reads my repositories, writes changes, opens a review pass, and deploys.

I treat it exactly like a contractor with commit access and a probation period that never ends. It built the storefront, the internal dashboards, the scrapers, and all the glue scripts. My job is not to write the code. My job is to read a diff at the level of "this changes the checkout page and nothing else" and to notice when that claim is false.

That distinction matters more than it sounds. You do not need to be able to write the feature. You need to be able to tell whether the change is contained.

3. Scheduled routines

Recurring jobs. "Every morning at 7, scan these five grant portals and report anything new." "Every day, draft two posts and three replies for my approval."

The unlock here is psychological as much as technical. A solo operator's scarcest resource is not hours, it is open loops — the things you're holding in your head because if you forget them, nobody else will remember. Every loop you hold costs attention whether or not you act on it.

Things that run on a schedule stop occupying your head. That is the actual product.

One rule I learned the hard way: a scheduled job must report "nothing changed" explicitly. If silence can mean either "no news" or "the job has been broken for nine days," you will eventually discover it was the second one. Mine tell me they found nothing. Then silence always means breakage.

4. Persistent memory

Structured notes my agents read and write: per-site notes ("this bookkeeping tool's export button is under Settings → Data"), per-project notes ("payment provider B's review is pending, last checked on the 23rd"), and per-decision notes ("subscriptions stay on card billing only; do not re-add wallet pay to subscriptions").

Without memory, every session starts from zero and re-makes old mistakes. You re-explain your business, the agent re-discovers that the export button moved, and it re-proposes the thing you rejected in March.

With memory, your staff has tenure. This is the difference between an intern who started this morning and one who has been with you a year.

The trap is dumping everything into one giant note. Then retrieval gets worse as it grows, and the agent reads three thousand words of history to answer a question about one dashboard. Split it: one file per site, one per project, one per durable decision.

5. Approval gates

The rule that makes all of the above safe enough to run on a business with real money in it:

Agents draft. I approve. Agents execute.

Anything irreversible passes an explicit human checkpoint. Sending money. Filing a government application. Posting publicly. Emailing a customer. Deploying to production.

People read that as a compromise on automation — as if the gate is the part I haven't automated yet. It is the opposite. The gate is the automation strategy. It converts a hundred hours of doing into one hour of reviewing, and reviewing is a job one person can actually hold.

It also changes the cost of failure, which is what makes the whole thing possible. An agent that drafts a bad grant application costs me five minutes of review. An agent that submits a bad grant application costs me a lot more than five minutes. So mine can't.

What this actually buys, honestly

In conservative terms, across the last stretch of running this way:

It covers roughly two to four full-time roles' worth of routine work: ops assistant, bookkeeper's assistant, junior marketer, junior developer.
It costs a few hundred dollars a month in tooling. Less than one day of one employee.
It does not replace judgment. I still decide pricing, brand, product, and legal strategy. Agents make those decisions cheap to execute, not unnecessary to make.
It fails regularly. A deploy shipped wrong subscription discount tiers. A refund reported "done" that the payment gateway had actually blocked. A scraper returned stale competitor data for nine days without complaining. Every one of those became a checklist line.

That last point is the one I'd underline. The failures are survivable because of the gates, not because the agents are reliable. Anyone selling you the version where the agents don't fail is selling you something else.

Where to start if you're one person

Do not install all five at once. The order that worked:

Pick the single workflow that wastes the most of your week. Run it manually with an agent twice before you schedule it. You are debugging your own process description, not the model.
Write the memory notes. The moment you stop re-explaining your business, everything else gets cheaper.
Put gates on money paths before you automate them, not after.
Then schedule. Only things that have already worked manually twice.

The failure mode I see most often is the reverse: schedule first, discover later that the workflow was never right, and end up with a cron job that produces confident garbage every morning at seven.

This is the introduction to a longer thing. I wrote down all 30 workflows I actually run — each with the numbered playbook, a copy-paste prompt, the pitfalls that burned me, and honest time and money ranges.

Originally published on my site: https://methezone.github.io/solo-operator-playbook/five-primitives.html

I wrote down all 30 workflows with the copy-paste prompts and the failures. Five of them are free, in full, no email gate: the free sampler.