Claude Projects knowledge bases for indie founders

Blank chats fit one-off questions. Product specs, support wording, and competitor notes that return every week lose context in a blank chat. Claude Projects provide workspaces with knowledge bases and separate chat histories. This article does not compare Claude Code with Cursor, and it does not review a model tier. It covers how indie founders land a knowledge base in Projects and how to spend the Free five-project cap. Sources are Anthropic help pages on Projects and RAG observed on 2026-09-26.

What Projects actually give you

Help center copy states that Projects create self-contained workspaces with their own chat histories and knowledge bases, where you can upload documents, provide context, and run focused chats with Claude. Projects are available to all users, including free Claude accounts. Free users can create a maximum of five projects. Management guidance points to claude.ai/projects and New Project to name a workspace and add content. Materials uploaded to project knowledge are available across chats inside that project.

RAG documentation states that when project knowledge approaches the context window limit, Claude automatically enables retrieval-augmented generation to expand capacity by up to about 10x, using a project knowledge search tool to pull relevant snippets. If knowledge later drops below the threshold, processing can return to normal context mode. You do not need a manual switch to begin.

A default split for indie work

Do not waste five Free slots evenly on vibes. A common split is product specs and decisions, support and external wording, competitors and research, content and publishing, plus an experimental sandbox for temporary PDFs. The sandbox keeps disposable files out of formal libraries. Paid users with more slots should still split by task boundaries instead of one mega project.

Write a short project instruction in each formal project. Define role boundaries, what must not be invented, and output shape, such as forbidding support promises about unshipped features. Keep instructions short and put detail in knowledge documents. Name files clearly, such as 2026-09 pricing wording, not final-final.

Week one uploads only what you will reuse

Prioritize sources you will cite repeatedly. Requirement summaries, error code tables, refund rules, brand banned phrases, competitor matrices. Conclusions that emerge in chat should be distilled into the knowledge base if you will need them next week. Help center guidance stresses that chat context is not shared across conversations inside a project unless you add the information to project knowledge.

For changing numbers, put an observed date at the top of the doc. Archive stale files by rename so the model does not see two prices at once. Images can help, but retrievable text should carry the rules.

When not to upload, and when not to use Projects

Customer data without redaction, live secrets, and unpublished fundraising materials should stay out of a cloud knowledge base by default. Redact locally or paste only necessary fragments. If the workflow is mostly editing a repo, Claude Code or an IDE agent fits better; Projects do not replace version control. If you need team sharing with different chat-visibility rules, read Team plan docs before you park collaboration here.

When Free’s five projects are full, archive the sandbox before you delete formal specs. Public pricing pages often list Projects alongside higher-usage Pro-class tiers; upgrade when weekly limits and project counts actually hurt, not when marketing copy feels urgent.

Scenario defaults

A solo SaaS defaults to three formal projects plus a sandbox, leaving one emergency slot. A solo content site splits content and research so tone does not bleed. Two partners agree on one knowledge source of truth, then chat separately to avoid dual wording. If NotebookLM already handles long PDF reading, keep that for deep reading and place distilled conclusions into Claude for writing calls.

The narrow call. Indie founders should use Claude Projects for recurring context, spend the Free five-project cap on task boundaries, keep sources in knowledge, keep guardrails in instructions, and let RAG engage as volume grows. Do not upload secrets. Pay only under real usage or project-count pressure, and recheck help and pricing pages the day you change plans.

Spend ten minutes each Friday on maintenance. Delete obviously stale drafts, refresh prices and error codes, and confirm instructions still match the product. Maintenance beats creating a tenth project.

Put project links in an internal handbook so new helpers read the knowledge base before asking. That is how Projects become an asset rather than a private drawer only you open.