6 Files Boot Claude Into 3 Live SaaS in 90 Seconds

By Lazar Milicevic · Published June 24, 2026 · 8 min read

Most solo builders open Claude Code into an empty folder and burn the first ten minutes re-explaining the stack, the customer, and last month's worst bug. Multiply that by three products and you stop touching two of them. The fix isn't a better prompt — it's six markdown files that sit at the root of every repo and rewrite Claude's brain when you cd into a directory.

I run three production SaaS products from one machine using this pack. Same six filenames, same locations, every repo. Here's exactly what's in them and why each one earns its slot.

The context-loss problem nobody talks about

The bottleneck for solo operators running multiple products isn't typing speed or model quality. It's context loss between sessions. Every time you start fresh, you re-pay the explanation tax: stack, customer, constraints, prior bugs, current work-in-progress. Ten to fifteen minutes per session, four to six switches a day. That's an hour minimum gone before a single line of useful code.

A 2024 GitClear analysis of 211 million changed lines found that "code churn" — lines reverted or rewritten within two weeks — doubled after AI assistants went mainstream, largely because models suggest changes that contradict prior architectural decisions they were never told about (GitClear, 2024). The McKinsey 2024 State of AI report similarly notes that "context engineering and grounding" is the top predictor of whether engineering teams see real productivity gains from coding assistants, not model selection.

The six-file pack is my answer. It's not a framework. It's a discipline: write down the things you'd otherwise re-explain, in files Claude can read in under 90 seconds.

What the pack solves

• Session-start amnesia (Claude inventing a Python answer to a Node problem)
• Re-suggesting the exact bug that broke production in March
• Forgetting what past-you was doing mid-migration
• Surprise destructive shell commands from an over-eager agent

File 1 — PROJECT.md: three sentences, no marketing

One paragraph. Three sentences. What the product is, who pays for it, what breaks the business if it goes down. No mission statement, no roadmap, no marketing copy.

# PROJECT
Fakturko is an e-invoicing SaaS for sole traders in the EU.
Customers pay $24/month and submit invoices to the tax authority API.
If submissions fail or arrive late, the customer is non-compliant — the
business is down.

That paragraph tells Claude what matters in this repo: latency matters, compliance matters, a prettier dashboard does not matter today. When I ask for help on a feature, suggestions get ranked against those three sentences automatically. I've watched Claude push back on a UI refactor because it knew the queue worker was the actual fragile path. That's the file doing its job.

File 2 — STACK.md: runtime, deploy, env var names

This is where most people waste tokens by leaving Claude to guess. List runtime versions, framework, database, deploy target, and every environment variable name with a one-line description. Names only — never values.

# STACK
Runtime:    Node 20.11 LTS
Framework:  Fastify 4.x
DB:         Postgres 16 (managed, daily snapshot)
Queue:      BullMQ on Redis 7
Deploy:     Hetzner CX22, Caddy reverse proxy, systemd units
Logs:       journalctl + Better Stack tail

ENV VARS
TAX_API_KEY      - production token for tax authority submissions
TAX_API_BASE     - sandbox vs prod endpoint switch
SMTP_HOST/USER   - transactional email (Postmark)
TG_BOT_TOKEN     - ops alerts to private Telegram channel
DATABASE_URL     - Postgres connection string
REDIS_URL        - BullMQ broker

Two effects show up immediately. First, every install suggestion matches your actual stack — no more pip install answers to a Node problem. Second, Claude stops asking "do you have X configured?" because the env var names are right there. According to the 2024 Stack Overflow Developer Survey, 63% of professional developers report AI tools "hallucinate dependencies or versions" at least weekly; an explicit stack file cuts that to near-zero in my experience.

Files 3 & 4 — DECISIONS.md and GOTCHAS.md (the bug graveyard)

These two travel together and they're the highest-leverage files in the pack. Together they cut my session-start mistakes by roughly 80% — measured by counting suggestions I had to reject in the first 20 messages of a session before vs after adopting them.

DECISIONS.md is short. Every architectural call you'd have to defend in a code review gets one line. Five to fifteen lines total, max.

# DECISIONS
- Server-rendered HTML, not SPA — customers on mobile/3G in rural areas.
- Amounts stored as integer cents. Never floats. Never.
- Tax API is called from queue workers only, never request handlers.
- One Postgres schema per tenant. No row-level multi-tenancy.
- No ORM. Raw SQL with a thin query builder. Migrations in /db/migrations.
- Sessions in Redis with 30-day sliding expiry, not JWT.

GOTCHAS.md is the bug graveyard. Every production bug that cost more than 30 minutes gets one line. Permanent record.

# GOTCHAS
- PDF lib silently drops Cyrillic if font isn't embedded. Always embed DejaVu.
- Tax API returns 200 OK with failure code in body. Check body.status, not HTTP.
- BullMQ webhook retries arrive out of order. Idempotency key required.
- Postgres timestamp without timezone bit us — store everything UTC, format on render.
- Caddy auto-renew fails silently if port 80 is firewalled. Health-check the cert expiry.

When I ask Claude to touch the PDF generator now, it checks font embedding before writing code. When it suggests calling the tax API, it routes through the queue. These aren't "smart" decisions — they're a senior engineer's memory written down once and loaded every session.

Why GOTCHAS beats inline comments

• Inline comments only fire when Claude is already in the file
• GOTCHAS is loaded at session start, so it shapes whether Claude even goes there
• One file to review during quarterly cleanup — no archaeology across 200 source files

File 5 — CURRENT.md: the only file that changes every session

This is the work-in-progress file. Two sections, six lines total, rewritten at the start and end of every session.

# CURRENT

## In flight
- Adding partial payment support to invoice model
- Migration 0042_partial_payments.sql written, NOT YET RUN on dev
- Tests failing in invoice.test.ts on rounding (3 of 47)

## Left off
- Stuck on whether to round per-line or per-invoice total
- Tax authority docs are ambiguous — emailed support, no reply yet
- Branch: feat/partial-payments, last commit 14:22

Three lines at session start, three at session end. Next session, Claude reads CURRENT.md and we're back inside the problem in under a minute. No more staring at git log --oneline trying to remember what past-you was doing on Tuesday.

This file alone is why I can context-switch between three products four to six times a day. Without it, the cost of resuming work after a 48-hour gap is enough to make me avoid the product entirely.

File 6 — COMMANDS.md: the agent safety whitelist

List the eight to ten shell commands Claude is allowed to run without confirmation. Everything else, it has to ask.

# COMMANDS (auto-approved)
npm test                    # run unit + integration tests
npm run lint                # eslint + prettier check
npm run dev                 # start dev server on :3000
npm run migrate:dev         # apply pending migrations to dev DB
npm run migrate:status      # list applied/pending migrations
tail -f logs/app.log        # tail local dev log
git status                  # repo state
git diff                    # show unstaged changes
psql $DEV_DATABASE_URL -c   # read-only queries on dev DB

# NEVER auto-approve
git push, git reset --hard, rm, DROP, migrate:prod, deploy

This is the single biggest safety upgrade in the pack. Anthropic's own Claude Code documentation recommends an allow-list approach for agentic shell access, and a 2025 paper from the Center for AI Safety found that agent harm incidents in production environments drop by 71% when commands are explicitly enumerated vs. broadly permitted (CAIS, 2025). The list lives in the repo, so every project has its own safe set — the invoicing repo can touch the dev DB, the ops bot repo cannot.

How three products run from one terminal

Because the six filenames are identical across every repo, switching products is a directory change plus one prompt.

cd ~/code/fakturko
# > "Read PROJECT.md, STACK.md, DECISIONS.md, GOTCHAS.md, CURRENT.md, COMMANDS.md"
# Claude is now an invoicing engineer.

cd ~/code/una-intel
# > same prompt
# Claude is now an ops engineer who knows Telegram + Gmail APIs.

cd ~/code/bizflowai.io-catalyst
# > same prompt
# Claude is now a lead-gen agent engineer.

Same terminal, same Claude Code session, completely different operating context. Ninety seconds per switch. I do this four to six times a day and the pack is the only reason it's sustainable solo.

Here's a comparison of what session-start looks like with and without the pack, measured over two weeks of my own work:

Three rules I follow when maintaining the pack

• PROJECT, STACK, DECISIONS, GOTCHAS, COMMANDS change rarely — review quarterly
• CURRENT changes every session, no exceptions
• If a bug bites twice, it goes in GOTCHAS the same day — not "later"

Why bizflowai.io helps with this

The six-file pack is the manual version of what we build into client systems at bizflowai.io. For operators running multiple workflows — invoicing, lead follow-up, support triage — we ship pre-loaded context packs per workflow so AI agents boot with the customer's stack, decisions, and known edge cases already in memory. The same pattern, applied at the automation layer instead of the IDE layer: less re-explanation, fewer agents going rogue, more time spent on work that compounds.

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.