How I build a SaaS solo with Claude Code: method and guardrails

I have built nine SaaS products on my own, with Claude Code as my development team. AI is not what makes that possible: the way it is framed is. An agent that codes fast without a frame quickly produces code nobody understands, itself included by the next session. Here is the method I use, as it can be read in my repositories — starting with this site’s. The products themselves are on the projects page.

Frame before the first line

A non-trivial feature starts with a written specification, not a prompt. The blog you are reading is the example: before any code, a document described the problem, the data model, the states to handle, the acceptance criteria, the test plan, the pitfalls found in the existing code, and ended with the implementation prompt.

This is not bureaucracy. An agent executes what has been decided very well; it decides poorly what has not. The specification moves decisions to where they are cheapest: before the code, not during review.

A CLAUDE.md that tells the truth

Every repository has its CLAUDE.md: the stack, the structure, the commands, the conventions, the change rules, the known pitfalls and the pre-commit checklists. It is the document the agent reads first, every session. Its rules are concrete and checkable, like this one, taken from this site’s repository:

Ne jamais construire un lien interne avec `/${locale}${path}` :
utiliser localeHref(locale, path), sinon le lien anglais pointe
vers une URL française qui répond en 301.

The flip side: a wrong CLAUDE.md is worse than none. On this site, the security documentation described for six weeks a protection that had been removed from the code. The blog’s framing started from that non-existent constraint; it took reading the actual configuration to notice, then fixing nine files. Hence a line in the pre-commit checklist: if a change touches what the docs describe, the docs change with it.

Rules the agent cannot bypass

A written instruction is a wish. An automated check is a rule. Anything a tool can check should be checked by one:

• Strict TypeScript: on this blog, a paragraph missing its English version does not compile.
• Unit and end-to-end tests, written alongside the code, not after.
• Before every PR: lint, type check, tests and a production build. One command, not an effort of memory.
• Schema validation for untrusted inputs (environment variables, forms, webhooks).
• No TODOs in the code: every known debt gets an entry in a known-issues file, with its lead.

When AI is inside the product

Building with AI and building AI are two different topics. In the second case, the discipline moves into the product. Novera Signal, an agent that detects and qualifies sales opportunities, enforces strict JSON output validated by a schema, versions its prompts, keeps the data provider behind an abstraction, and never sends anything on its own: a human approves every message. Novera Recorder transcribes and summarises meetings entirely on the local machine, because their content must not leave it.

What I never delegate

• Deciding what not to build. That is the decision that saves the most.
• Architecture: permissions, data isolation, payments. Where a mistake costs a rewrite.
• Reviewing every change, comparing the diff against the specification.
• Irreversible actions: production releases, sending to third parties, deleting data.

The rest, the agent does better and faster than I would alone. That split is what makes a solo-built product sustainable over time. It is also what sets its price: what an AI-built SaaS MVP costs.