3-tier templates: solo, mid, corporate

Time: about 25 min reading + 40 min practice

The gist

When you build a home, you build it for your needs. A 300-square-foot studio for a single freelancer, a house for a family of five, an office for a 50-person company. These are different buildings with different infrastructure. A studio doesn't need a server room. A 50-person office can't get by on one outlet.

The same goes for a template for a new project. One template for every case is either too much complexity for a solo founder (they spend 2 weeks figuring out audit/, engineering-standards/ and SOC2 checklists instead of launching an MVP) or not enough for a corporate client (a B2B contract requires a data processing agreement, and the project doesn't have one).

The solution is a 3 tiers × 8 project types matrix. Three levels of infrastructure (solopreneur / mid-business / corporate) multiplied by eight business types (SaaS, content, service and so on). That's 24 ready-made configurations. Plus LEGO modules: you add only what you actually need, nothing more.

🎨 Picture this: a platform for several projects is a factory that builds businesses. The factory used to turn out one model of truck, the same one for a long-haul trucker and a gardener. Now it has a lineup: a car for one person, a minivan for a family, a semi for logistics. At each stage only the modules change (engine, body, electronics); the frame and the way it's assembled stay the same.

Key concepts

• Tier: a project's level of infrastructure: solopreneur, mid-business, corporate. It's set not by ambition but by the real load (team, budget, compliance)
• Base: the project foundation that's the same on every tier: 4 files (CLAUDE.md, MEMORY.md, HANDOFF.md, README.md) + 3 folders (assets, decisions, tasks)
• LEGO modules: 17 optional blocks you add on request: brand, departments, analytics, customers, tests, deployments, prps, prompts, explorations, compliance, security, audit, governance, infrastructure, contracts, reporting, context
• Project type: the project category that sets the default set of modules: SaaS, Content, Service, Marketplace, Tool, Community, Education, Build-to-Sell
• Non-negotiable: modules required on every tier: MEMORY.md and HANDOFF.md. Without them, every new Claude session starts from scratch
• Detachability: the requirement that a project can live without the platform. If the shared platform shuts down, the project has its own CLAUDE.md, its own owner data, its own BRAND-VOICE.md. It doesn't depend on the parent
• Portfolio Pattern: shared platform infrastructure (CORE) + independent projects with their own identity
• Decision tree: the algorithm for picking a tier and modules: 4 questions → a ready configuration
• Smart suggestions: the /audit-needs command, where Claude analyzes the project and suggests which modules to add
• Module promotion: the pattern for moving a project up the tiers: solo → mid → corporate as it grows

Theory

Why three tiers

One template for everything is an anti-pattern. Let me explain with numbers.

A solo founder hacking together an MVP over a weekend needs to start coding within 10 minutes. If the template comes with engineering-standards/, audit/, compliance/gdpr.md, security/threat-model.md folders, they spend 4 hours figuring out what these are and why. In the end they either delete half of it (time wasted reading) or leave it and forget about it (dead weight in the project).

A corporate client with a B2B contract is the opposite. When the lawyers ask "where's your Data Processing Agreement and breach notification policy?", you need to show ready documents in 5 minutes, not spend 3 days writing them from scratch.

The solution is a three-level hierarchy. Each level adds only what's needed at that stage.

🎨 Picture this: clothes. Solo is a T-shirt and jeans (minimal, comfortable, quick). Mid-business is a shirt and tie (you're meeting clients now). Corporate is a suit with cufflinks (you get let onto the executive floor at the bank).

Tier 1: Solopreneur, the studio apartment

Profile: 1 person. Budget $0-500/month. Focus: MVP, time to market, validation. Manual processes are fine.

What's included (base/):

• CLAUDE.md: the loader, how to work with the project
• MEMORY.md: what I already know about this project (a digest for restoring context)
• HANDOFF.md: for handing the project to another Claude / developer
• README.md: the external interface (for users, GitHub)
• assets/: static files, logos, screenshots
• decisions/: a decision log (one file per decision)
• tasks/: current tasks

What's NOT included (on purpose):

• ❌ Per-project subagents (the platform's shared agents are used)
• ❌ Per-project hooks (inherited from CORE)
• ❌ Compliance docs (nobody asks a solo founder for SOC2)
• ❌ Engineering standards: there's no one to govern, it's just you
• ❌ A per-project audit log (the CORE audit is enough)
• ❌ Contracts: no B2B yet

Footprint: ~5-15 KB of markdown files. Setup time: 5-10 minutes with /new-project.

Anti-pattern: a solo founder adds engineering-standards/ "for the future." A year later the governance folder is empty and the project is closed. Time wasted. The rule: don't add what you don't need today.

Tier 2: Mid-business, the family house

Profile: 2-10 people (including freelancers). Budget $500-5,000/month. There are paying clients. Automation starts saving money. Deployment processes appear.

What gets added to the base:

• BRAND-VOICE.md: one style for the team (if 3 people write content, you need one tone)
• ARCHITECTURE.md: a diagram of the system (a new developer sees how everything connects)
• BUDGET.md: operating expenses by month
• ROADMAP.md: what's planned for the next 3-6 months
• departments/: functional areas (marketing, support, ops)
• analytics/: metrics, KPI dashboards
• customers/: pseudonymized client data (not raw PII)
• tests/: automated tests (Vitest, Playwright)
• deployments/: staging + production procedures

Optional modules depending on context:

• prps/: Product Requirement Prompts (for feature development through /generate-prp)
• prompts/: a reusable prompt library
• explorations/: R&D experiments that don't go to production

Footprint: ~50-150 KB. Setup time: 30-60 minutes with /new-project --tier=mid + /add-module.

Pattern: wait for the signal. Don't add analytics/ until you have 10 paying clients: there's nothing to measure yet. Add it when the Recent Decisions section of MEMORY.md mentions metrics 3 times in a row.

🎨 Picture this: renovating an apartment. First you live in it and figure out where you're short on outlets, where the lighting is bad, where the floor squeaks. Then you fix those spots. You don't do a complete overhaul before you've lived there.

Tier 3: Corporate, the office building

Profile: 50+ people (or 5-10 people with enterprise B2B contracts). Budget $5,000+/month. Compliance is mandatory: SOC2 / GDPR / HIPAA depending on the industry. Lawyers require an audit trail.

What gets added to mid-business:

• ENGINEERING-STANDARDS.md: the decision-making structure (who approves what)
• compliance/: the full set: GDPR baseline, CCPA, privacy policy, ToS, cookie policy, retention policy, breach notification, data classification, data processing agreement, audit checklist
• security/: threat model, secrets management, incident response runbook
• audit/: append-only logs of every significant action (for SOC2 audits)
• infrastructure/: IaC, DR (disaster recovery), backup strategy
• contracts/: MSA, SLA, NDA templates for B2B clients
• reporting/: quarterly business reviews, board reports

Footprint: ~300 KB - 1 MB. Setup time: 4-8 hours with /new-project --tier=corporate + manual customization of the legal docs.

Anti-pattern: a solo founder jumps to the corporate tier because they "want to look serious." A month later they discover that compliance/gdpr.md holds a generic template that doesn't fit their specific situation. The lawyers still need to review it. Time wasted.

The rule: the corporate tier gets turned on by an outside signal: the first enterprise client in the pipeline, a lawyer asks for a DPA, an auditor starts a SOC2 readiness assessment. Not "just in case."

8 project types × 3 tiers

The Portfolio Pattern provides for 8 project types. Each one has a default set of modules.

Build-to-Sell is special: its job is to be ready to hand over at any moment. That's why even the solo tier includes a beefed-up HANDOFF.md (for a future buyer). At mid-business it's already the full set, because a business for sale has to show ARR, metrics and documentation.

Non-negotiable across all tiers

Two files are required at every level. Without them, every Claude session starts from scratch.

1. MEMORY.md: a quick digest of the project

When a new Claude session opens the project, the first thing it reads is MEMORY.md. Context is restored in 2 minutes: phase, recent decisions, open blockers, tech stack, top metrics.

Without MEMORY.md:

• Claude reads all of CLAUDE.md + README.md + the last 10 commits + scans the structure: 10 minutes
• At minute 10 it starts working, but with incomplete context
• Constant clarifying questions for the project owner

With MEMORY.md:

• 2 minutes: full context restored
• Claude suggests the next action right away
• Hardly any context-related questions

2. HANDOFF.md: the continuity file

What if the owner gets sick? Decides to sell the project? Hires a developer? HANDOFF.md is a self-contained document for an outside reader who doesn't know your platform.

It should answer:

• What does this project do?
• What's the current status (revenue, users, blockers)?
• Where's the source code, where's the deployment, where are the admin credentials?
• Who are the partners/clients (pseudonymized)?
• What are the risks and open issues?

Without HANDOFF.md, the project isn't detachable. It can't survive if the shared platform shuts down or the owner hands the project to someone else. That breaks the principle that projects can be detached (detachability).

LEGO modules: the catalog

17 modules are available through /add-module. They're grouped by function.

Brand & Identity (1):

• brand/: BRAND-VOICE.md, brand guidelines, visual identity

Operations (4):

• departments/: functional areas (marketing, support, ops, finance)
• analytics/: metrics, KPIs, dashboards
• customers/: pseudonymized client data
• reporting/: periodic reviews (weekly/monthly/quarterly)

Engineering (6):

• tests/: Vitest/Playwright/Jest setup
• deployments/: staging + production procedures
• prps/: Product Requirement Prompts for feature development
• prompts/: a reusable prompt library
• explorations/: R&D experiments
• infrastructure/: IaC, DR, backup strategies

Compliance & Risk (5):

• compliance/: GDPR, CCPA, privacy, ToS, retention policies
• security/: threat model, secrets, incident response
• audit/: append-only logs
• engineering-standards/: the decision-making structure
• contracts/: MSA, SLA, NDA templates

Context (1):

• context/: external knowledge files (specs, papers, glossaries specific to the project)

The decision tree: how to pick a tier

Question 1: How many people actively work on the project?
  1 person → solo tier (start here, upgrade later)
  2-10 people → mid-business tier
  10+ people OR there are B2B enterprise clients → corporate tier

Question 2: Are there regulatory requirements?
  No → the answer from question 1
  GDPR (EU users) / CCPA (CA users) → at least mid-business + the compliance module
  HIPAA / SOC2 / financial regulations → corporate

Question 3: Are you getting the project ready to sell?
  No → the answer from questions 1-2
  Yes → tier + 1 (at least mid-business even if solo). A beefed-up HANDOFF.md
  Ready to sell now → corporate (shows the buyer it's mature)

Question 4: What's the revenue?
  $0-1,000/month → solo
  $1,000-10,000/month → mid-business
  $10,000+/month OR enterprise contracts → corporate

If different questions give different answers, take the highest tier. Better to overshoot than undershoot when the load grows.

Promotion: moving between tiers

A project can grow. Solo → mid-business happens when:

• A second person joins the team (a freelancer, a partner)
• The first $500-1,000/month in revenue comes in steadily
• 10+ paying clients
• Decisions start getting discussed (you need decisions/)

Triggers for mid → corporate:

• The first enterprise B2B prospect (a deal of $10K+/year)
• A prospect's lawyers asked for compliance docs
• An audit / due diligence (for selling the project or an investment round)
• A team of 10+ people

The promotion process:

1. Run /audit-needs: Claude will tell you which modules it recommends
2. The project owner approves the list
3. /add-module compliance / /add-module security / etc.
4. Fill the generic templates in with your specific details
5. Update MEMORY.md with the new tier status

Anti-pattern: preemptive promotion. Don't upgrade the tier because you "want to look serious." An upgrade is a reaction to an outside signal, not internal ambition.

Detachability: a critical requirement

Every project must survive the death of the platform. If the platform shuts down tomorrow, any project, say projects/my-newsletter/, should keep working as a standalone project.

What this means in practice:

• ✅ Its own CLAUDE.md (not just an @import from CORE)
• ✅ Its own BRAND-VOICE.md (independent of the platform owner's communication rules)
• ✅ Its own owner data (pseudonymized if needed)
• ✅ Its own deployment scripts (they don't call the platform's shared infrastructure directly)
• ✅ A HANDOFF.md that's self-contained for an outside reader

What it's allowed to borrow:

• Shared playbooks through a link like @~/platform/... (as long as the project stays in the platform)
• Shared agents and hooks (but when it detaches, they get copied into the project)

🎨 Picture this: a grown child should be able to live apart from their parents. That doesn't mean they have to move out. But they could at any time. The platform is the parent; the projects are the grown children.

🧪 Practice

The /new-project, /add-module, /audit-needs and /handoff commands are custom commands from the course author's working repository, and the projects/_template/ folders aren't publicly available. If you don't have them, create your own: in Claude Code, a custom command is a skill (the file .claude/skills/<name>/SKILL.md), and older .claude/commands/<name>.md files still work too. Ask Claude to build a command like this from the description in the lesson.

Step 1: Start a new project with /new-project

# In Claude Code, with your platform folder open
/new-project my-newsletter

Claude will ask 4 questions (the decision tree above):

• How many people?
• Regulatory requirements?
• Getting it ready to sell?
• Current revenue?

Based on your answers, it will suggest a tier + modules. Approve it, and the structure gets created.

Step 2: Look over the structure it created

ls projects/my-newsletter/

On the solo tier you'll see:

projects/my-newsletter/
├── CLAUDE.md          (loader)
├── MEMORY.md          (digest, required)
├── HANDOFF.md         (continuity, required)
├── README.md          (external interface)
├── AGENTS.md          (symlink to CORE agents)
├── assets/            (logos, screenshots)
├── decisions/         (log)
└── tasks/             (current)

Mid-business will add: BRAND-VOICE.md, ARCHITECTURE.md, BUDGET.md, ROADMAP.md, analytics/, customers/, departments/, deployments/, tests/.

Corporate will add on top of mid: ENGINEERING-STANDARDS.md, compliance/, security/.

Step 3: Add a module when there's a signal

A month has passed. my-newsletter now has 50 paying subscribers. Time to start tracking metrics.

/add-module analytics

Claude will:

1. Check compatibility (is there analytics already? no, so add it)
2. Copy the template from projects/_template/modules/analytics/
3. Adapt it to the current tier
4. Update MEMORY.md (record that the module was added)
5. Suggest a next step (fill in the starting metrics)

Step 4: Smart suggestions with /audit-needs

/audit-needs

Claude will analyze MEMORY.md, recent decisions and the current structure, and suggest:

Recommended modules for my-newsletter:
✅ ALREADY HAVE: brand, analytics
🔵 SUGGEST: customers (you mentioned customer feedback 3 times in decisions/)
🟡 OPTIONAL: prompts (you have 5 reusable prompts in scattered places)
⚪ NOT NEEDED YET: compliance (no EU/CA users mentioned)

Approve? [y/n]

You decide what to add. Claude doesn't make decisions on its own; it only suggests.

Step 5: Promotion from solo → mid-business

# After a trigger (a second person, the first $1K/mo)
/audit-needs --tier=mid-business

Claude will show a gap analysis:

Current: solo tier
Target: mid-business tier

Missing modules for mid-business:
- BRAND-VOICE.md (need for team consistency)
- ARCHITECTURE.md (onboard new developer)
- BUDGET.md (track operational costs)
- ROADMAP.md (3-6 month plan)
- departments/ (functional areas)
- analytics/ (KPIs tracking)
- deployments/ (staging procedure)

Estimated time to setup: 1-2 hours
Estimated maintenance overhead: +30 min/week

Proceed with promotion? [y/n]

Step 6: Verify detachability

Once a quarter, check that the project is detachable.

/handoff projects/my-newsletter

Claude will generate a HANDOFF.md for an outside reader. Read it as a stranger would:

• Is it clear what the project does?
• Are there financial metrics (revenue, costs)?
• Are the critical dependencies listed (API keys, hosting)?
• Is the PII pseudonymized?
• Could the project run without the shared platform?

If the answer to even one of these is "no," fix it before next quarter.

Step 7: The Build-to-Sell scenario (if it applies)

If you're building a project to sell:

/new-project saas-tool --type=build-to-sell

The defaults already include a beefed-up HANDOFF.md. On top of that you need:

1. Full pseudonymization of the owner's data
2. An asset inventory: a list of everything (domains, accounts, IP)
3. A financial summary: the last 12 months of P&L (if applicable)
4. A customer list: pseudonymized (for the buyer's due diligence)
5. A transition plan: how the new owner takes over the project (login changes, payment redirects)

# 6 months before the sale
/add-module reporting  # quarterly business reviews: they raise the valuation
/add-module contracts  # MSA/SLA ready for the buyer
/audit-needs --tier=corporate  # gap analysis for a premium sale

Step 8: Practice: pick a tier for your own ideas

Take 3 of your current or planned projects. Apply the decision tree:

Notice: the most demanding answer sets the tier. If even one question points to corporate (HIPAA, for example), the whole project is corporate.

⚠️ Anti-patterns

❌ One template for every case. There used to be one big template that contained EVERYTHING. A solo founder spent 4 hours reading it, deleted half and got lost in the rest. The fix is a modular system with an explicit choice of tier.

❌ Preemptive promotion. A solo founder adds engineering-standards/, compliance/, audit/ "just in case" / "to look serious." Six months later the folders are empty and the time is wasted. The rule: promotion is reactive, not proactive. An outside signal triggers the upgrade.

❌ Skipping the non-negotiables. A solo founder deletes MEMORY.md because "it's all in my head anyway." Two weeks later a new Claude session doesn't know the context and spends 30 minutes on discovery every time. MEMORY.md and HANDOFF.md are required on every tier.

❌ Module sprawl. A mid-business project included all 17 modules "because they're available." A year later the explorations/ folder has one file, contracts/ is empty, and audit/ has never been opened. The rule: add a module when there's a signal you need it NOW.

❌ Cross-tier copy-paste without adapting. You copied compliance/gdpr.md from the template as is, and it has generic placeholders like {{COMPANY_NAME}}. A prospect's lawyer will see it and lose trust. The rule: a template is a starting point, not a final document.

❌ Detachability breaks by accident. The project has import config from '/Users/me/platform/shared/...', and now it doesn't work if you move the folder. The rule: all imports are relative or go through explicit shared/ symlinks.

❌ Mixing tiers inside a project. The project is on the corporate tier, but decisions/ is empty (decisions aren't being recorded). That's not corporate; that's solo with an expanded structure. A tier isn't just files; it's also the discipline of using them.

❌ Build-to-Sell without preparing the HANDOFF. You launched a project to sell, but HANDOFF.md says "you'll figure it out." The buyer sees a lack of transparency and asks for a discount. Build-to-Sell = HANDOFF.md as a product asset that keeps getting updated.

🔗 Related

Claude.md: your project's system prompt: what to put in the project loader. This lesson adds to it: which tier to choose for CLAUDE.md.

Portfolio detachability: detachable projects: shared platform infrastructure vs. independent projects. Here you practice creating such a project with detachability in mind.

Memory and continuity: why MEMORY.md is non-negotiable on every tier. For Claude Code's automatic memory, see Claude.md: your project's system prompt.

Multi-agent orchestration: the corporate tier adds per-project subagents. Solo uses the shared CORE agents.

Skills architecture: which skills you need on each tier (solo uses a shared library; corporate may have project-specific skills).

✅ Checkpoint

Before moving on to the next lesson, make sure that:

• You can explain the difference between the solo / mid-business / corporate tiers in your own words, using an analogy
• You know the 8 project types and the default set of modules for each
• You understand why MEMORY.md and HANDOFF.md are non-negotiable on every tier
• You've applied the decision tree to at least one of your real / planned projects
• You've run /new-project with the right tier and checked the structure
• You know when to add a module (on a signal) vs. when not to (preemptive is an anti-pattern)
• You understand the detachability requirement and why it's critical
• You've run /audit-needs on at least one existing project
• You know the triggers for promotion from solo → mid → corporate
• You can explain why Build-to-Sell is a special case that needs a beefed-up HANDOFF

Sources

Templates and commands from the course author's working repository (not publicly available; you can build them yourself from the description in the lesson):

• projects/_template/base/: the foundation for every tier
• projects/_template/modules/: 17 LEGO modules
• projects/_template/business/: mid-business tier defaults
• projects/_template/corporation/: corporate tier defaults
• .claude/commands/new-project.md: bootstrap a new project
• .claude/commands/add-module.md: add a module
• .claude/commands/list-modules.md: what's available
• .claude/commands/audit-needs.md: smart suggestions
• Platform principles: the principle that projects can be detached (detachability)
• Context separation rules: what NOT to duplicate between CORE and projects
• The template factory description: the Portfolio Pattern and the 8 project types
• MEMORY.md (template): the structure of the non-negotiable file

Next lesson

→ Portfolio detachability: detachable projects