The 180-Line File That Lets Claude Run My Whole Business

By Lazar Milicevic · Published June 15, 2026 · 9 min read

Most people using Claude Code burn 20 minutes every session re-explaining their project. Stack, folder layout, naming, what not to touch — same monologue, five times a day. There's a boring fix nobody teaches, and it lives in one file at the root of your repo.

I run three production apps from this setup: Fakturko (invoicing), UNA_Intel (Gmail-Telegram bot), and bizflowai.io-Catalyst (lead engine). Same machine, same Claude Code install, zero context bleed. Here's exactly how it's wired.

The real cost of a blank-page Claude

Open a fresh session. Claude has no memory of yesterday. So you type the same orientation: "We're on Next.js 14, Postgres 16, Drizzle ORM, deploy to Hetzner, don't touch the migrations folder, use server actions not API routes…" That's 15-20 minutes of context-burning before you write a single line of real code.

Five sessions a day, five days a week. That's roughly 10 hours/week lost to re-explaining a business to an AI that should already know it. Across three apps, it gets worse — you start mixing up which convention belongs to which project.

The standard internet advice is to fix this with subagents, MCP servers, skills, orchestration frameworks. For a solo operator running a few apps, that's theater. You're optimizing the wrong layer. The leverage is one file Claude Code reads automatically: CLAUDE.md at the project root. No imports, no config. It's just there, and Claude treats it as ground truth.

What actually goes in CLAUDE.md (the five sections, in order)

The order matters. Claude reads top to bottom and weights earlier sections more heavily. Here's the structure I use for Fakturko, the invoicing app that processes hundreds of invoices a week for Serbian small businesses.

1. Project Context — three to five sentences. What the app does, who uses it, what the business goal is.

# Fakturko — Project Context

Fakturko is an invoicing app for Serbian small businesses (1-10 employees).
Users are non-technical owners who hate complexity. The product wins by being
faster than the competition for the 5 most common flows: create invoice,
mark paid, send reminder, export PDF, sync to accountant.
Optimize for fewer clicks and zero jargon, not feature breadth.

This sounds trivial. It's not. Without it, Claude will happily suggest enterprise-grade abstractions that are technically correct and commercially stupid. With it, Claude stops proposing role-based permission matrices for a one-person bakery.

2. Stack — every major dependency with its version. Be explicit.

## Stack
- Next.js 14.2 (App Router, server actions)
- TypeScript 5.4
- Postgres 16 (Hetzner, managed)
- Drizzle ORM 0.30
- Lucia Auth 3.x
- Stripe + Serbian bank transfer (custom adapter)
- Resend for transactional email
- Deploy: Docker → Hetzner VPS via GitHub Actions

This single block kills ~90% of wrong-library suggestions. If you're on Drizzle, Claude won't propose Prisma snippets. If you're on Postgres 16, no MySQL syntax.

3. Conventions — every decision Claude shouldn't have to ask about.

## Conventions
- File names: kebab-case for routes, PascalCase for components
- Server actions live in `app/_actions/`, one file per domain
- Never use API routes unless we need a webhook endpoint
- Tests: Vitest, written AFTER the feature, in `__tests__/` next to the file
- Env vars in `.env.local`, documented in `.env.example`
- Commits: Conventional Commits (`feat:`, `fix:`, `chore:`)
- Database changes: always a Drizzle migration, never raw SQL in app code

4. Commands — shell commands that matter. Not slash commands yet — actual bash.

## Commands
- Dev server:       `pnpm dev`
- Run tests:        `pnpm test`
- DB studio:        `pnpm drizzle-kit studio`
- New migration:    `pnpm drizzle-kit generate`
- Deploy:           `git push origin main` (CI handles the rest)
- Tail prod logs:   `ssh fakturko 'docker logs -f fakturko-app'`

Claude uses these instead of inventing wrong ones. No more "let me try npm run start" when the project uses pnpm.

5. Guardrails — what Claude must never do. The most underrated section.

## Guardrails
- NEVER modify files in `drizzle/migrations/` without explicit confirmation
- NEVER commit `.env*` files
- NEVER rewrite billing logic in `lib/billing/` without a written plan first
- NEVER run `drizzle-kit drop` or any destructive DB command
- NEVER touch the PDF rendering layer (`lib/pdf/`) — it's pixel-locked for accountants
- ALWAYS ask before installing a new dependency

This section alone has saved me from disasters more times than I can count. When Claude is autonomously chaining ten tool calls, the guardrails are the wall between "shipped a feature" and "wiped the migrations folder at 1 AM."

Section weights, ranked by ROI

• Guardrails → prevents catastrophes
• Stack → kills wrong-library suggestions
• Conventions → eliminates the "how should I name this?" loop
• Commands → stops the invented-command waste
• Project Context → kills commercially stupid decisions

Layer two: the .claude/commands/ folder

Once CLAUDE.md is solid, the next leverage is turning recurring multi-step prompts into one-tap slash commands.

Create .claude/commands/ in the project. Every .md file you drop in becomes a slash command. Here's the layout for Fakturko:

.claude/commands/
├── deploy.md
├── test.md
├── invoice-check.md
├── db-backup.md
├── release-notes.md
└── add-feature.md

Each file is a short prompt with the steps Claude should run. Example — .claude/commands/invoice-check.md:

Run a sanity check on the invoicing pipeline:

1. Run `pnpm test invoices`
2. Query Postgres: count invoices created in the last 24h, grouped by status
3. Check Resend logs for any failed reminder emails in last 24h
4. If any failures, summarize them and propose a fix — do NOT auto-apply
5. Output a 5-line summary I can paste into my daily log

Now I type /invoice-check instead of a paragraph. The release-notes command pulls the last 20 commits and writes a customer-facing changelog. The deploy command runs migrations, builds, and tails the production logs until the health check passes.

This is what turns Claude Code from a chat tool into a one-button operator for the business.

Layer three: one folder per business, never mash them together

If you run more than one app, do not put them in one mega-repo and hope context doesn't bleed. Each business gets its own folder at the root, each with its own CLAUDE.md and its own .claude/commands/.

~/code/
├── fakturko/
│   ├── CLAUDE.md
│   ├── .claude/commands/
│   └── ... app code
├── una-intel/
│   ├── CLAUDE.md
│   ├── .claude/commands/
│   └── ... bot code
└── bizflowai.io-catalyst/
    ├── CLAUDE.md
    ├── .claude/commands/
    └── ... engine code

When I cd into a folder and launch Claude Code, it loads only that project's brain. No cross-contamination. No confused suggestions pulling Drizzle patterns into a Python project. One install, three contexts, zero overlap.

Why this beats subagents for solo operators

• One file to maintain per project, in plain markdown
• No orchestration layer to debug
• Works on day one — no setup, no MCP server config
• Survives Claude Code updates because it uses the documented entry point

A real session, start to finish

Fresh terminal. cd ~/code/fakturko. claude. One sentence:

Add a feature that flags invoices unpaid for more than 30 days and sends a reminder email using our existing email service.

What happens next, without me typing another word:

1. Claude reads CLAUDE.md, sees Resend is the email provider, sees server actions are the pattern, sees Drizzle is the ORM
2. Generates a Drizzle query for invoices where status = 'unpaid' AND created_at < now() - interval '30 days'
3. Adds a server action in app/_actions/invoices.ts (matches the convention)
4. Writes a reminder template using the existing Resend client in lib/email/
5. Skips the migrations folder entirely (guardrail)
6. Asks before installing a cron library — proposes using the existing Vercel cron config instead

That entire flow used to take me 15 minutes of back-and-forth. Now it's one sentence and a review pass. The model didn't get smarter. The context did.

What I track to know it's working

I'm allergic to "feels faster" claims, so here are the actual numbers from the last 30 days across three projects:

The "0-1 wrong library" number is the one that surprises people. The stack section does most of that work alone.

Why bizflowai.io helps with this

A lot of the client work I ship through bizflowai.io starts exactly here — auditing how a small team uses Claude Code (or Cursor, or whatever) and writing the CLAUDE.md, command library, and folder layout for their stack. It's unglamorous but it's the highest-leverage automation work you can do for a solo or sub-10-person team, because every hour of AI-assisted work after that compounds instead of starting from zero.

Frequently asked questions

What is CLAUDE.md and why does it matter for Claude Code?

CLAUDE.md is a single markdown file placed at the root of your project that Claude Code reads automatically every session in that directory. It requires no imports or config. It gives Claude persistent context about your project, stack, and rules, so you stop wasting 20 minutes per session re-explaining your setup. Claude treats its contents as authoritative guidance.

How do I structure a CLAUDE.md file for a solo business?

Use five sections in this order: Project Context (3-5 sentences on what the app does and who uses it), Stack (every major dependency with version numbers), Conventions (naming, routing, testing, commit format), Commands (shell commands for dev, test, deploy, database), and Guardrails (what Claude should never do). A complete file runs about 180 lines.

Why do solopreneurs burn out using Claude Code?

Because every session starts with re-explaining the project: stack, database location, API folder, naming conventions, and what not to touch. Claude has no memory of yesterday's work. This setup tax burns roughly 20 minutes per session, which adds up to about two hours daily across five sessions, before any real work gets done.

When should I use CLAUDE.md vs subagents and MCP servers?

For a one-person business running a few apps, start with CLAUDE.md and a commands folder. Subagents, MCP servers, skills, and orchestration frameworks add complexity solopreneurs typically don't need. They optimize the wrong layer. The real leverage is persistent project context in one root file, not multi-agent infrastructure.

How do I create custom slash commands in Claude Code?

Inside your project, create a folder called .claude, and inside it a folder called commands. Every markdown file you drop there becomes a slash command. For example, a deploy.md file becomes /deploy. Each file contains a short prompt describing the exact steps Claude should take, turning repetitive workflows into one-button operations.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.