Scope-Appropriate Architecture

Right-size every architectural decision to the project's actual needs. Not every project needs hexagonal architecture, CQRS, or microservices.

Core principle: Detect the project tier first, then constrain all downstream pattern choices to that tier's complexity ceiling.

---

The 6 Project Tiers

Tier	LOC Ratio	Architecture	DB	Auth	Tests
1. Interview/Take-home	1.0-1.3x	Flat files, no layers	SQLite / JSON	None or basic	8-15 focused
2. Hackathon/Prototype	0.8-1.0x	Single file if possible	SQLite / in-memory	None	Zero
3. Startup/MVP	1.0-1.5x	MVC monolith	Managed Postgres	Clerk/Supabase Auth	Happy path + critical
4. Growth-stage	1.5-2.0x	Modular monolith	Postgres + Redis	Auth service	Unit + integration
5. Enterprise	2.0-3.0x	Hexagonal/DDD	Postgres + queues	OAuth2/SAML	Full pyramid
6. Open Source	1.2-1.8x	Minimal API surface	Configurable	Optional	Exhaustive public API

LOC Ratio = total lines / core business logic lines. Higher ratio = more infrastructure code relative to business value.

---

Auto-Detection Signals

Signal	Tier Indicator
README contains "take-home", "assignment", "interview"	Tier 1
Time limit mentioned (e.g., "4 hours", "weekend")	Tier 1-2
< 10 files, no CI, no Docker	Tier 1-2
.github/workflows/ present	Tier 3+
package.json with 20+ dependencies	Tier 3+
Kubernetes/Terraform files present	Tier 4-5
CONTRIBUTING.md, CODE_OF_CONDUCT.md	Tier 6
Monorepo with packages/ or apps/	Tier 4-5

When confidence is low: Ask the user with AskUserQuestion.

---

Pattern Appropriateness Matrix

Pattern	Interview	Hackathon	MVP	Growth	Enterprise
Repository pattern	OVERKILL	OVERKILL	BORDERLINE	APPROPRIATE	REQUIRED
Event-driven arch	OVERKILL	OVERKILL	OVERKILL	SELECTIVE	APPROPRIATE
DI containers	OVERKILL	OVERKILL	LIGHT ONLY	APPROPRIATE	REQUIRED
Separate DTO layers	OVERKILL	OVERKILL	1 EXTRA	2 LAYERS	ALL LAYERS
Microservices	NEVER	NEVER	NEVER	EXTRACT ONLY	APPROPRIATE
CQRS	OVERKILL	OVERKILL	OVERKILL	OVERKILL	WHEN JUSTIFIED
Hexagonal architecture	OVERKILL	OVERKILL	OVERKILL	BORDERLINE	APPROPRIATE
DDD (bounded contexts)	OVERKILL	OVERKILL	OVERKILL	SELECTIVE	APPROPRIATE
Message queues	OVERKILL	OVERKILL	BORDERLINE	APPROPRIATE	REQUIRED
API versioning	SKIP	SKIP	URL prefix	Header-based	Full strategy
Error handling	try/catch	console.log	Error boundary	Error service	RFC 9457
Logging	console.log	none	Structured JSON	Centralized	OpenTelemetry

Rule of thumb: If a pattern shows OVERKILL for the detected tier, do NOT use it. Suggest the simpler alternative instead.

---

Technology Quick-Reference by Tier

Choice	Interview	Hackathon	MVP	Growth	Enterprise
Database	SQLite / JSON file	In-memory / SQLite	Managed Postgres	Postgres + Redis	Postgres + queues + cache
Auth	Hardcoded / none	None	Clerk / Supabase Auth	Auth service	OAuth2 / SAML / SSO
State mgmt	useState	useState	Zustand / Context	Zustand + React Query	Redux / custom + cache
CSS	Inline / Tailwind	Tailwind	Tailwind	Tailwind + design tokens	Design system
API	Express routes	Single file handler	Next.js API routes	FastAPI / Express	Gateway + services
Deployment	localhost	Vercel / Railway	Vercel / Railway	Docker + managed	K8s / ECS
CI/CD	None	None	GitHub Actions basic	Multi-stage pipeline	Full pipeline + gates
Monitoring	None	None	Error tracking only	APM + logs	Full observability stack

---

Build vs Buy Decision Tree (Tiers 1-3)

For Interview, Hackathon, and MVP tiers, always prefer buying over building:

Capability	BUY (use SaaS)	BUILD (only if)
Auth	Clerk, Supabase Auth, Auth0	Core product IS auth
Payments	Stripe	Core product IS payments
Email	Resend, SendGrid	Core product IS email
File storage	S3, Cloudflare R2	Compliance requires on-prem
Search	Algolia, Typesense Cloud	> 10M docs or custom ranking
Analytics	PostHog, Mixpanel	Unique data requirements

Time savings: Auth alone is 2-4 weeks build vs 2 hours integrate.

---

Upgrade Path

When a project grows beyond its current tier, upgrade incrementally:

Tier 2 (Prototype) → Tier 3 (MVP)
  Add: Postgres, basic auth, error boundaries, CI

Tier 3 (MVP) → Tier 4 (Growth)
  Add: Redis cache, background jobs, monitoring, module boundaries

Tier 4 (Growth) → Tier 5 (Enterprise)
  Add: DI, bounded contexts, message queues, full observability
  Extract: First microservice (only the proven bottleneck)

Key insight: You can always add complexity later. You cannot easily remove it.

---

When This Skill Activates

This skill is loaded by:

• brainstorm Phase 0 (context discovery)
• implement Step 0 (context discovery)
• quality-gates YAGNI check
• Any skill that needs to right-size a recommendation

The detected tier is passed as context to constrain downstream decisions.

---

Related Skills

• ork:brainstorm - Uses tier detection in Phase 0 to constrain ideas
• ork:implement - Uses tier detection in Step 0 to constrain architecture
• ork:quality-gates - YAGNI gate references this skill's tier matrix
• ork:architecture-patterns - Architecture validation (constrained by tier)

---

References

Load on demand with Read("${CLAUDE_SKILL_DIR}/references/<file>"):

File	Content
interview-takehome.md	Tiers 1-2 in detail
startup-mvp.md	Tier 3 patterns and decisions
enterprise.md	Tiers 4-5 patterns and justification criteria
open-source.md	Tier 6 unique considerations