Solo operators
The Solo Operator's Guide to Claude
If you run your own work, Claude is most valuable when it removes one recurring bottleneck without creating a second job for you to supervise.
Updated July 28, 2026
The direct answer
Do not begin with a giant prompt library or an ambitious automation. Choose one job you already repeat, give Claude a stable brief and a real example, then add a review step you can perform in a few minutes. That is the smallest useful Claude system for a solo operator.
The goal is not to make Claude run your business. It is to reduce the repeated setup, sorting, and first-draft work that competes with the work only you can do: making decisions, serving clients, and taking responsibility for the result.
Why collecting prompts is not enough
A clever prompt can produce a good answer once. A useful workflow must also work on next week’s messier input, show you when something is missing, and leave the result somewhere you can find it. That requires more than wording.
| Piece | Question it answers | Solo-operator example |
|---|---|---|
| Context | What does Claude need to know every time? | Your offer, audience, tone, current priorities, and the meaning of internal shorthand. |
| Input | What changes on each run? | This week’s meeting notes, inbox thread, research links, or rough draft. |
| Output contract | What does “finished” look like? | A five-bullet briefing, a client email draft, or a task list with owners and dates. |
| Review gate | What must a human verify? | Names, dates, promises, source support, tone, and any action outside Claude. |
Choose your first workflow with four tests
- It repeats. You have done it at least three times and expect to do it again.
- The inputs are visible. You can point to the notes, messages, files, or facts the work begins with.
- The result is recognizable. You can describe a good output and show an example.
- A mistake is recoverable. You review the draft before it creates a promise, expense, deletion, or public action.
A weekly client update passes all four tests. “Handle my marketing” does not. The first has a recurring input, a defined deliverable, and an obvious review moment. The second hides dozens of decisions inside one vague instruction.
A complete example: the weekly client update
Imagine Friday arrives with three meeting notes, a few completed tasks, and two decisions waiting on the client. The old process is to reread everything, decide what matters, and draft an update from scratch.
1. Make the input packet
Put the week’s relevant notes in one place. Do not give Claude the entire client archive merely because it exists. Smaller, deliberate context is easier to inspect and less likely to surface stale information.
2. Write the standing brief
Tell Claude who the update is for, the normal tone, the required sections, what counts as a blocker, and what it must never invent. Include one previously approved update as an example if you have one.
3. Ask for a reviewable result
Request the status summary first, then the client email. This two-step sequence lets you correct missing facts before polished prose makes an unsupported claim feel finished.
4. Apply the review gate
Check every date, owner, promise, and decision request against the source notes. Claude can draft the email; only you can decide whether it accurately represents the relationship.
The useful artifact is the workflow, not this week’s email. Save the brief, approved example, and review checklist. Next Friday, only the input packet should change.
Three strong starting workflows
These workflows are useful in ordinary Chat. When the job needs connected apps or a bounded multi-step assignment, move it to Cowork. When the lasting result belongs in a folder with templates, history, and repeatable checks, move it to Code. The Chat vs Cowork vs Code guide provides the full decision rule.
A 30-minute workflow setup
- Choose one task from the last seven days that you expect to repeat.
- Collect one real input and one example of an acceptable result.
- Write a six-line brief: context, input, output, boundaries, example, review.
- Run it once in Chat and mark every correction you make.
- Add those corrections to the brief, then run it on a second real input.
If the second run is easier to review and requires fewer corrections, you have the beginning of a system. If it is not, improve the brief or choose a more bounded job. Do not add scheduling, connectors, or file access to rescue a workflow whose basic contract is still unclear.
What not to delegate early
Common solo-operator mistakes
- Starting with the most annoying task instead of the clearest one. A painful but chaotic process is often a bad first workflow.
- Giving Claude every file “for context.” Scope the input to the decision; stale context creates confident mistakes.
- Polishing before checking facts. Validate the structured summary before asking for finished prose or design.
- Calling a scheduled prompt an automation. A timer does not make an unclear process reliable.
- Skipping the saved review checklist. The checklist is what turns your judgment into a repeatable quality standard.
Plan access and the course path
You can build and test the first version of these workflows in Chat on a free Claude account. The course’s Cowork and Code exercises begin at Lesson 6 and generally require paid Claude access for the intended hands-on work. Pro is sufficient; Max is not required. See the Free vs Pro vs Max guide for the exact distinction between reading the later lessons and performing their exercises.