Claude Projects knowledge bases for indie founders
Load specs and support rules into Claude Projects, set project instructions, and allocate the Free five-project cap without uploading secrets.
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.
