How to Use Claude Code to Run a Business, Not Just Write Code

You installed Claude Code, pointed it at a folder, watched it build something small, and then hit the real question: now what? Most guides stop at “type claude and ask it to make an app.” That is where the useful part begins, not where it ends. I build and run eight products on my own, and the back office of all of them, blog publishing, SEO reporting, signup triage, support summaries, inbox cleanup, monitoring, runs on Claude Code jobs that fire on schedules. That is more than thirty jobs, and only a fraction of them touch code.

Here is the short version. You use Claude Code by describing a goal in plain English, letting it plan before it edits, checking its work, and repeating until the loop earns your trust. Then you stop babysitting it interactively and start handing it recurring jobs on a schedule. The highest-leverage way to use Claude Code is not interactive coding, it is unattended scheduled jobs that run while you sleep.

How to use Claude Code, step by step

The core loop is the same whether you are a developer or not:

  1. Install and launch. From your terminal, run npm install -g @anthropic-ai/claude-code (or use the native installer from Anthropic’s docs), then run claude inside a project folder. On first run it walks you through signing in with your Anthropic account; you need a paid Claude plan or API credits. Trust the directory when it asks, and you are in.
  2. Describe the goal in plain English. Not “write a function,” but “add a contact form that emails me when someone submits it.” Tell it to ask questions before it starts if anything is ambiguous.
  3. Make it plan first. Press Shift+Tab to enter plan mode. It then shows you a written list of the changes it intends to make before it touches a single file, so you catch a bad approach before it happens. Plan mode before edits is the single habit that separates a useful session from a runaway one.
  4. Review, adjust, then let it edit. Approve the plan or send it back.
  5. Verify. Run the app, read the diff, or ask it to run the tests. Never merge on trust.

A concrete example from my week: I told it “pull last month’s Search Console data for these three sites and tell me which posts lost the most clicks.” It planned the steps, read the data through a connected tool, ranked the losers, and handed me a short list. No code involved, just a task with a clear input and a checkable output.

Four things make that loop far better, fast:

  • Give it a CLAUDE.md. This file sits in your repo and is read at the start of every session. Mine tells every agent to use my secrets injector instead of ever handling a raw key, never use em dashes, hand bulk file reading to subagents to save context, and double-check a database field name before it writes a query against it. Yours should hold how the project is built and what to never touch.
  • Scope the context. Do not dump the whole repo at it. Point it at the files that matter with @-references. Broad context makes it slower and more likely to guess.
  • Use slash commands. /clear wipes the conversation so a long task does not drag stale context behind it. You can save your own commands as markdown files in a .claude/commands/ folder and reuse them.
  • Connect tools with MCP. The Model Context Protocol is a small JSON config: you add a server entry with a name and what it connects to, and the tool shows up inside Claude Code. I added a Google Search Console server so Claude reads my real traffic instead of guessing; the full walkthrough is in connecting Search Console to Claude.

There are three ways to run it. Pick by how much you trust it yet:

Way to run it Best for The trade-off
Terminal CLI Full control, automation, power use You live in the terminal
IDE extension (VS Code, JetBrains) Seeing diffs inline while you learn Tempts you back into line-by-line editing
Cloud / web Kicking off tasks from a browser or phone Least visibility into what it is doing

If you are serious about using Claude Code as more than a novelty, learn it in the terminal. Every unattended job I run lives there, and the CLI is the only surface that automates cleanly.

The shift that matters: operator, not autocomplete

Cursor and Copilot sit inside your editor and finish your lines. Claude Code takes a whole job. Once you see it that way, “how do I use it” stops being about keystrokes and becomes a question about which jobs you are willing to delegate. If you want the editor-style comparison, I wrote a full Cursor vs Claude Code breakdown after paying for both.

Beyond code: the jobs I actually run on it

This is the part the tutorials skip, because most authors use Claude Code to write code faster, not to run an operation. Here is what more than thirty scheduled jobs look like in practice:

  • Blog publishing. A /blog <site> workflow picks the next topic from a backlog, applies that site’s SEO strategy, writes the article, generates the images, publishes to the CMS, and posts a run summary. The whole thing lives in one repo and runs unattended across several sites.
  • SEO reporting. A weekly and a monthly job pull Search Console, GA4 and Bing data through connected tools and email me a portfolio report. For the research layer behind that I use my own SEO tool, Murkuz, so Claude reads live keyword and ranking data instead of guessing at it.
  • New-signup triage. A cron scores new signups across every product against my ideal-customer profile, so the interesting accounts surface instead of drowning in a list.
  • Support and inbox. One job summarizes support tickets into answered, still-open, and feature requests. Another strips forwarding noise out of my email so only useful mail reaches me.
  • Infrastructure canary. A daily 8am job checks that everything is still up and shouts if it is not.

Claude Code is not just a coding tool; I run the back office of eight products on it through more than thirty scheduled jobs. When I do hand it a whole feature, I dictate the brief by voice through Contextli and let Claude Code carry the front end and back end end to end. If it hits its usage limits, I switch to Codex for the rest, which I broke down in Codex vs Claude Code.

The question stops being “what can Claude Code build for me” and becomes “which recurring job in my week never has to be mine again.”

How to keep an unattended agent from wrecking things

The first objection everyone raises: are you not terrified it deletes your database or spends your money? Honestly, no. In heavy daily use I have not had an agent destroy anything, and the “AI wiped my repo” stories usually trace back to no plan mode and no backups. But running jobs unattended does need a few guardrails.

  • Plan mode and verification are the core of it. An agent that outlines first and checks its own work afterward rarely goes off a cliff.
  • Permissions and allowlists decide what it can run without stopping to ask. Loosen them only for jobs you have already watched behave.
  • A secrets injector. This is the one guardrail I deliberately built. My credentials live in a local file of names and descriptions; a small script pulls the real value at runtime so the key never enters the model’s context. The only guardrail I actually had to build was a secrets injector, so the AI can run on auto without ever seeing a key. Models refuse to paste API keys into chat, which used to break every multi-step automation; the injector fixed that.

Without those, “run unattended” is a wish. With them, I leave real jobs on auto and trust them to finish.

What it costs, and whether it is worth it

Heavy use is metered by how much the model actually works, so a hobby month and a production month cost very different amounts. Rough shape of the plans, which are Anthropic’s own (check their pricing page for current numbers):

Plan Rough monthly cost Who it is for
Pro about $20 learning, light interactive use
Max about $100 to $200 daily heavy use, one power user
Team seats and API on top metered running multiple products or unattended jobs

I run roughly 15 to 20 billion tokens a month across a personal Max seat and two team seats, and my total AI spend sits around five to six hundred dollars. Here is the part worth knowing before you panic at the entry price: at raw API rates that usage would cost fifteen to twenty thousand dollars a month, and I pay a small fraction of it on a subscription. I put the real numbers, plan by plan, in what I actually pay for Claude Code.

Is it worth it? For me it replaced work I would otherwise pay people to do, so the math is not close. For someone using it to write code a little faster, the cheapest paid plan is fine. The gap opens up the moment you start running jobs unattended, because a scheduled job earns its keep every day whether or not you are at the keyboard.

FAQ

Do you have to be a coder to use Claude Code?

No. If you can organize files in folders and describe a task in plain English, you can use it. Most of my back-office jobs, the reports, the triage, the inbox cleanup, are not coding at all. You do not need to be a developer to use Claude Code; you need to describe a task clearly and check the result.

What can I actually use Claude Code for besides writing code?

Anything that is a repeatable process over files, data, or an API:

  • Publishing and updating content
  • Pulling and summarizing analytics
  • Triaging new signups or support tickets
  • Cleaning up an inbox
  • Monitoring systems and alerting you when something breaks

If a task has clear inputs and a checkable output, it is a candidate for a job.

How do I fit it into my day-to-day instead of using it once and forgetting it?

Stop thinking of it as something you open, and start thinking of it as jobs that run on their own. Take one recurring task you do every week, write it up as a prompt with the steps, and put it on a schedule. That single move is what turns Claude Code from a toy into infrastructure.

It runs off and does too much, or burns through context. How do you control that?

Always plan first, keep the context tight with @-file references, and use /clear between unrelated tasks. If a job matters, ask it to verify its own work at the end. Runaway behavior is almost always a scoping problem, not the model being reckless.

How do I prompt it effectively?

  • Be specific about the outcome, not the implementation.
  • Give it the context it needs and nothing it does not.
  • Tell it to ask questions before it starts on anything ambiguous.
  • Keep your CLAUDE.md tight so it starts every session already knowing your rules.

The clearer your prompt, the less you have to correct after the fact.

Where this comes from

I build and run eight products on my own, and the back office of all of them runs on Claude Code schedules, so I have used it on real work rather than demos: more than thirty jobs covering publishing, reporting, triage and monitoring. The setup above, plan mode first, a tight CLAUDE.md, a secrets injector so it can run unattended, is exactly what I use every day, run from a terminal with around twenty sessions open at once. The verdict on cost is what I actually pay this month, not a guess. If you want the tools behind the workflow, my SEO research runs on Murkuz and my notes and memory run locally through Locul, both of which I built to plug into this exact setup. Start by moving one weekly task onto a schedule; that is the step that changes how you work.