--- name: fifteen-factor-app description: The Fifteen-Factor App methodology for modern cloud-native SaaS applications. This skill should be automatically invoked when planning SaaS tools, product software architecture, microservices design, PRPs/PRDs, or cloud-native application development. Extends the original Twelve-Factor App principles with three additional factors (API First, Telemetry, Security). Trigger keywords include "fifteen factor", "12 factor", "SaaS architecture", "cloud-native design", "application architecture", "microservices best practices", or when in a planning/architecture session. user-invocable: false --- # Fifteen-Factor App Methodology ## Overview The Fifteen-Factor App methodology extends the original Twelve-Factor App principles (created by Heroku in 2012) with three additional factors essential for modern cloud-native applications: API First, Telemetry, and Security. This methodology provides architectural principles and guidelines for building software-as-a-service applications that are: - **Performant** - Optimised for speed and efficiency - **Scalable** - Designed for horizontal scaling without significant changes - **Manageable** - Easy to deploy, monitor, and maintain - **Resilient** - Robust against failures with graceful degradation ## When to Apply This Methodology Apply the Fifteen-Factor principles during: 1. **Architecture Planning** - When designing new applications or microservices 2. **PRP/PRD Creation** - When documenting technical requirements and specifications 3. **Code Reviews** - When evaluating whether implementations follow best practices 4. **Migration Planning** - When modernising legacy applications for cloud deployment 5. **Technical Debt Assessment** - When identifying architectural improvements ## The Fifteen Factors at a Glance | Factor | Principle | Key Concept | |--------|-----------|-------------| | I. Codebase | One codebase, many deploys | Single repo per app, version controlled | | II. Dependencies | Explicitly declare and isolate | No implicit system-wide packages | | III. Config | Store in environment | Never hardcode configuration | | IV. Backing Services | Treat as attached resources | Databases, caches are swappable resources | | V. Build, Release, Run | Strict separation | Immutable releases, no runtime changes | | VI. Processes | Stateless and share-nothing | Horizontal scaling, no sticky sessions | | VII. Port Binding | Export via port | Self-contained, no runtime injection | | VIII. Concurrency | Scale out via process model | Horizontal over vertical scaling | | IX. Disposability | Fast startup, graceful shutdown | Maximise robustness | | X. Dev/Prod Parity | Keep environments similar | Continuous deployment | | XI. Logs | Treat as event streams | Separate generation from processing | | XII. Admin Processes | Run as one-off processes | Same environment as app | | **XIII. API First** | Design contracts first | Enable parallel development | | **XIV. Telemetry** | Monitor everything | APM, health checks, domain metrics | | **XV. Security** | Authentication & Authorisation | RBAC, identity per request | ## Applying Factors in Planning Sessions When creating a PRP, PRD, or architecture plan, evaluate the design against each factor: ### Foundation Factors (I-VI) These establish the baseline for any cloud-native application: - **Codebase**: Define repository structure and branching strategy - **Dependencies**: Specify package manager and dependency isolation approach - **Config**: Plan environment variable strategy and secrets management - **Backing Services**: Identify all external services and abstraction layers - **Build/Release/Run**: Design CI/CD pipeline with immutable artifacts - **Processes**: Ensure stateless design, plan session/state storage ### Operational Factors (VII-XII) These ensure smooth operation and maintenance: - **Port Binding**: Define service exposure strategy - **Concurrency**: Plan horizontal scaling approach - **Disposability**: Design for container orchestration - **Dev/Prod Parity**: Minimise environment differences - **Logs**: Plan logging infrastructure (ELK, Fluentd, etc.) - **Admin Processes**: Automate one-off tasks ### Modern Extensions (XIII-XV) These address contemporary requirements: - **API First**: Define OpenAPI/Swagger contracts before implementation - **Telemetry**: Plan APM, health endpoints, and observability - **Security**: Design authentication/authorisation (OAuth2, RBAC) ## Architecture Checklist Use this checklist when reviewing or planning an application: ``` □ Single codebase in version control □ All dependencies explicitly declared □ Configuration externalised to environment □ Backing services abstracted and swappable □ Build, release, run stages separated □ Stateless processes (no sticky sessions) □ Services self-contained with port binding □ Designed for horizontal scaling □ Fast startup and graceful shutdown □ Dev/staging/prod environments aligned □ Logs streamed to external aggregator □ Admin tasks automated and reproducible □ API contracts defined before implementation □ Telemetry: APM, health checks, metrics □ Security: Authentication and authorisation ``` ## Resources Detailed documentation for each factor is available in the references directory: - `references/overview.md` - Complete factor summary with diagrams - `references/original-factors.md` - Factors I-XII with implementation examples - `references/modern-extensions.md` - Factors XIII-XV (API First, Telemetry, Security) - `references/setup-and-tools.md` - Tooling recommendations and quick start To load detailed information about specific factors, read the appropriate reference file. For example, when planning API design, load `references/modern-extensions.md` for API First guidance. ### Searching References For specific implementation patterns, search the references: - API contracts: `grep -i "swagger\|openapi" references/` - Logging patterns: `grep -i "log\|fluentd\|elk" references/` - Security patterns: `grep -i "oauth\|rbac\|authentication" references/` - Container patterns: `grep -i "docker\|container" references/`