Claude Code for Solo Founders: What I Actually Ship With It

I am a one-person company. There is no backend team, no DevOps engineer, and no QA. There is me, a server, and Claude Code running in a terminal on that server. This post is about what that combination actually produces, and the habits that made it reliable instead of chaotic.

What has been built this way

Everything on my projects page was developed with Claude Code as the main pair programmer:

• a self-hosted crawling service with an API, request logging, and route health tracking
• a WordPress theme and companion plugin that replaced a licensed commercial plugin on my newer sites
• DatPilot Portal, a FastAPI app with accounts, a wallet, quoting, and a 51-check website inspector
• the content pipeline and nightly audits that keep 8 sites healthy
• an automated news digest that renders image cards and narrated short videos
• this website

None of these are demos. They run every day, and when they break, I fix them in the same terminal.

It works on the real server, not on snippets

The biggest difference from chat-based AI help is that Claude Code works inside the actual environment. It reads the real config files, runs the real build, checks the real logs, and looks at the real HTML a page returns. A huge class of “this should work” answers disappears when the assistant can run curl against the live page and see that it does not.

That is also why I ask for verification on the real output, every time. Not “the database says the setting is on”, but “the page served over HTTPS shows it”. Several bugs on my sites only existed at that last layer: a server cache still serving an old noindex page, or an avatar field holding an ID where a URL was expected, rendering src="http://48".

Memory: one fact per file

A coding assistant that forgets everything between sessions makes you repeat yourself. Claude Code supports a persistent memory directory, and I use it heavily with a simple rule: one fact per file, plus an index.

Good memory entries look like:

• a project note: where the code lives, how to deploy, what not to touch
• a decision with its reason: “do not link site A from site B, because of X”
• a lesson: “after changing this setting, clear the page cache, or the old HTML stays”

Bad entries are things the code already says. If it is in the repository or the git log, it does not need to be in memory.

The payoff is that a new session can start with “continue the writing batch” and pick up the right files, the right commands, and the open issues.

Skills and subagents for repeated jobs

Some tasks come up every day: check system health, add a new proxy, continue a batch, review the nightly ops report. I turned those into skills, which are short instruction files the assistant loads when I type a command like /kiem-tra (Vietnamese for “check”).

For read-heavy jobs, a skill hands the work to a subagent running a smaller, cheaper model. Reading through a long log to count repeated errors does not need the strongest model. The subagent returns a short summary, and the main session stays clean.

I also switch models deliberately. The everyday default is a mid-size model. For hard work, like designing a payment ledger or debugging a race condition, I switch to the strongest model and switch back when done.

Rules that keep it honest

The failure mode of AI coding is not bad syntax. It is confident claims. These rules live in memory and in my prompts:

1. No invented numbers. Every number in an article or report must come from a source or a calculation that can be repeated. If something was not measured, say so.
2. “Verified” means verified. Only the parts that were actually checked can be called verified.
3. Raise a concern once, then do the job. If I ask for something risky, I want the risk stated with evidence one time, and then I decide.
4. Ask before outward-facing actions. Publishing, posting, and deleting are confirmed first unless I have said otherwise.

There is also a hard safety layer. Some bulk writes against production data get blocked by the permission system, and the assistant hands me the exact command to run myself. That friction is annoying for a moment and valuable over months.

It also says no

When my sites outgrew the 10-site limit of a commercial plugin license, the obvious shortcut was to strip the license check. Claude Code declined, pointed to the proprietary license in the code, and proposed writing a compatible plugin from scratch instead. That became AffShelf, which I cover in build vs buy. The refusal saved me from a legal problem and gave me a product I own.

What it does not replace

• Product judgment. It can list options. Choosing what to build and for whom is still my job.
• Accounts and credentials. DNS records, payment providers, API keys, and anything tied to my identity go through me.
• Taste in the final read. I still read new pages and articles myself before calling a template done.

Advice if you are starting

• Give it a real environment with logs and a way to see output, not just a code editor.
• Write down decisions, not just facts, and include the reason.
• Turn every repeated task into a skill after the third time you explain it.
• Insist on checking the real output. Most of my bugs were found there.

For a solo founder, the effect is not that the assistant writes code faster than I could. It is that I can run a stack that would normally need a small team, and still understand every part of it.