dd0c: full product research pipeline - 6 products, 8 phases each

Products: route, drift, alert, portal, cost, run
Phases: brainstorm, design-thinking, innovation-strategy, party-mode,
        product-brief, architecture, epics (incl. Epic 10 TF compliance),
        test-architecture (TDD strategy)

Brand strategy and market research included.

products/04-lightweight-idp/product-brief/brief.md

@@ -0,0 +1,813 @@
+# dd0c/portal — Product Brief
+**Product:** Lightweight Internal Developer Portal ("The Anti-Backstage")
+**Version:** 1.0
+**Date:** 2026-02-28
+**Author:** Product Strategy Team
+**Status:** Phase 5 — Product Brief (Investor-Ready)
+**Board Decision:** GO (4-1) — Build Third in dd0c Sequence
+
+---
+
+## 1. EXECUTIVE SUMMARY
+
+### Elevator Pitch
+
+dd0c/portal is a zero-configuration internal developer portal that auto-discovers your services from AWS and GitHub in 5 minutes, replaces months of Backstage setup with a single IAM role connection, and gives every engineer a Cmd+K search bar that answers "who owns this?" faster than asking in Slack. $10/engineer/month. No YAML. No dedicated platform team. No lies in your catalog.
+
+### Problem Statement
+
+The internal developer portal market is broken in both directions:
+
+**The Enterprise Trap:** Backstage (open-source, Spotify) requires 1-2 dedicated engineers to maintain, takes 3-6 months to deploy, and depends on `catalog-info.yaml` files that engineers write once and never update. After 12 months, most Backstage instances have <30% catalog accuracy. Port, Cortex, and OpsLevel charge $25-50/engineer/month with enterprise sales cycles, pricing out the 80% of engineering teams with 20-200 engineers.
+
+**The Spreadsheet Trap:** Teams that can't afford enterprise IDPs track services in Google Sheets and Notion databases that rot within weeks. When a P1 incident fires at 3 AM, precious minutes are wasted in Slack asking "who owns this?" — a question that should take 0 seconds to answer.
+
+**The data tells the story:**
+- Engineers spend an average of 3-5 hours/week searching for internal service information (Humanitec 2025 Platform Engineering Survey)
+- New hires take 3-4 weeks to become productive, with poor internal tooling cited as the #1 friction point
+- 70%+ of internal documentation is stale within 6 months of creation
+- Incident MTTR increases by 15-30 minutes when service ownership is unclear
+- <5% of organizations have a functioning IDP in 2026 (Gartner), despite 80% recognizing the need
+- The Backstage graveyard is growing — community forums and Reddit are filled with teams who invested months and got minimal value
+
+### Solution Overview
+
+dd0c/portal is a SaaS developer portal that generates its service catalog from infrastructure reality instead of human-maintained YAML files:
+
+1. **5-Minute Auto-Discovery:** Connect a read-only AWS IAM role and GitHub OAuth. The discovery engine scans EC2, ECS, Lambda, RDS, API Gateway, CloudFormation stacks, GitHub repos, CODEOWNERS, and README files. Within 30 seconds, the catalog is populated with >80% accuracy — including service names, inferred owners, descriptions, tech stacks, and repo links.
+
+2. **Cmd+K Instant Search:** The entire portal is a search bar. Type any service name, team name, or keyword — results in <500ms. Faster than asking in Slack. This is the daily-use hook that makes the portal the browser homepage.
+
+3. **Zero Maintenance:** The catalog auto-refreshes from infrastructure sources. No YAML to maintain. No platform engineer babysitting plugins. The catalog stays accurate because it's generated from truth, not maintained by humans.
+
+4. **dd0c Platform Integration:** Portal is the hub of the dd0c platform. dd0c/cost shows per-service AWS spend. dd0c/alert routes incidents to the right owner. dd0c/run links executable runbooks. Each module makes the portal richer; the portal makes each module smarter.
+
+### Target Customer
+
+**Primary:** Engineering teams of 20-200 engineers, AWS-primary, using GitHub, who either:
+- Tried Backstage and abandoned it (or are limping along with a broken instance)
+- Evaluated enterprise IDPs (Port, Cortex) and couldn't justify the $60-150K/year price tag
+- Currently rely on Google Sheets, Notion, or Slack tribal knowledge for service ownership
+
+**Buyer Personas:**
+- **The Platform Engineer (Alex):** Burned out maintaining Backstage. Wants a portal that maintains itself so they can build actual platform capabilities.
+- **The Engineering Director (Priya):** Needs always-current service ownership for incident response, compliance audits, and headcount justification. Can't answer "who owns what?" with confidence today.
+- **The New Hire (Jordan):** Drowning in scattered tribal knowledge. Needs to understand the service landscape in hours, not weeks.
+
+**Firmographic Profile:**
+- 20-200 engineers (sweet spot: 40-100)
+- AWS as primary cloud (70%+ of infrastructure)
+- GitHub organization (not GitLab/Bitbucket at launch)
+- Series A through Series D startups, or mid-market companies with modern engineering practices
+- US/EU-based (timezone alignment for solo founder support)
+
+### Key Differentiators
+
+| Dimension | Backstage | Port/Cortex | dd0c/portal |
+|-----------|-----------|-------------|-------------|
+| Time to value | 3-6 months | 2-6 weeks | 5 minutes |
+| Catalog maintenance | Manual YAML (1-2 FTEs) | Semi-manual (0.25 FTE) | Auto-discovery (0 FTE) |
+| Day-1 accuracy | 0% (empty catalog) | 30-50% (import + manual) | 80%+ (auto-discovered) |
+| Pricing (50 eng) | $0 + $200-400K labor | $60-150K/year | $6,000/year |
+| Daily-use stickiness | Low (nobody visits) | Medium | High (Cmd+K, Slack bot, browser homepage) |
+| AI capabilities | None | Basic | Native (Ask Your Infra, V2) |
+| Platform integration | Standalone | Standalone | dd0c flywheel (cost, alerts, drift, runbooks) |
+| Setup requirement | Fork React monolith, configure plugins, write YAML | Sales call, POC, weeks of configuration | Connect AWS + GitHub, done |
+
+---
+
+## 2. MARKET OPPORTUNITY
+
+### Market Sizing
+
+**Total Addressable Market (TAM): $4.3B/year**
+- Global software developers: ~28 million (Evans Data, 2026)
+- Developers in organizations with 20+ engineers (IDP-relevant): ~12 million
+- Average willingness to pay for developer portal tooling: ~$30/dev/month (blended across tiers)
+- TAM = 12M × $30 × 12 = $4.3B
+
+**Serviceable Addressable Market (SAM): $840M/year**
+- AWS-primary organizations (dd0c's initial integration scope): ~40% of cloud market
+- Teams of 20-500 engineers (too big for a spreadsheet, too small for Port/Cortex)
+- Estimated developer population in segment: ~2.8M developers
+- At $25/dev/month blended: SAM = 2.8M × $25 × 12 = $840M
+
+**Serviceable Obtainable Market (SOM):**
+- Year 1-2 realistic penetration: 0.1-1% of SAM
+- Conservative (0.1%): ~2,800 developers across 50-80 orgs → $336K ARR at $10/eng
+- Aggressive (1% by Year 3): ~28,000 developers → $3.36M ARR
+- Expected value at Month 12: ~$300K ARR (probability-weighted across scenarios)
+
+**Market growth:** IDP market growing at 30-40% CAGR as platform engineering becomes mainstream. Gartner estimates <5% of organizations have a functioning IDP in 2026, with 80% recognizing the need. The gap between awareness and adoption is dd0c's opportunity.
+
+### Competitive Landscape
+
+#### Tier 1: Open Source Incumbent — Backstage (Spotify/CNCF)
+- 27K+ GitHub stars, CNCF Incubating project
+- Free but requires 1-2 FTEs to maintain ($200-400K/year true cost)
+- `catalog-info.yaml` model is fundamentally broken — depends on humans doing unpaid maintenance
+- Most instances have <30% catalog accuracy after 12 months
+- Plugin ecosystem is wide but shallow; community plugins rot
+- **dd0c's angle:** "Backstage takes 5 months. We take 5 minutes. Backstage requires YAML. We require nothing."
+
+#### Tier 2: Managed Backstage — Roadie
+- Managed Backstage-as-a-Service, ~$30-50/engineer/month
+- Removes hosting burden but still fundamentally Backstage (still requires YAML, still has cold-start problem)
+- Validates that Backstage maintenance is a real pain point — which is dd0c's thesis
+- **Threat level:** Low. Roadie is a better Backstage; dd0c is a different paradigm.
+
+#### Tier 3: Enterprise IDP Platforms — Port ($33M Series A), Cortex ($35M+), OpsLevel
+- Enterprise pricing: $25-50/engineer/month, sales-led, minimum contracts $30K+/year
+- Feature-rich: self-service workflows, advanced RBAC, compliance reports, custom scorecards
+- Built for 500+ engineer orgs with dedicated platform teams and procurement budgets
+- Setup takes weeks. Requires significant configuration. Pricing excludes small-to-mid teams entirely.
+- **dd0c's angle:** 10-20x cheaper, 100x faster to set up, zero maintenance. For the 80% of teams that Port/Cortex ignores.
+
+#### Tier 4: Shadow Competitors (Existential Threats)
+- **GitHub:** Already has CODEOWNERS, dependency graphs, repository topics, Actions. If GitHub ships a "Services" tab, the lightweight IDP market contracts overnight. **Severity: 10/10.**
+- **Datadog Service Catalog:** Basic today, but Datadog has $2B+ revenue and massive distribution. If bundled effectively with monitoring, it's "free" for existing customers.
+- **Atlassian Compass:** Integrated with Jira/Confluence. Currently mediocre, but Atlassian has massive mid-market distribution.
+- **AWS Service Catalog:** Terrible UX today, but AWS has native infrastructure data access.
+
+#### Competitive Positioning Matrix
+
+```
+Factor                  | Backstage | Port/Cortex | Roadie | dd0c/portal
+------------------------|-----------|-------------|--------|------------
+Setup Time              | Months    | Weeks       | Days   | 5 minutes
+Catalog Maintenance     | Manual    | Semi-manual | Manual | Auto
+Day-1 Accuracy          | 0%        | 30-50%      | 0%     | 80%+
+Price (50 engineers)    | $200K+    | $60-150K    | $18-30K| $6K
+Daily Active Usage      | <10%      | 20-30%      | 15-25% | Target: 40%+
+AI-Native               | No        | Basic       | No     | Core (V2)
+Platform Integration    | Plugins   | Standalone  | Plugins| dd0c flywheel
+Solo Founder Viable     | No        | No          | No     | Yes
+```
+
+### Timing Thesis: Why Now
+
+Four forces are converging to create a window of opportunity:
+
+**1. Backstage Fatigue (2024-2026)**
+The Backstage hype cycle has peaked and entered the trough of disillusionment. Teams that adopted Backstage in 2023-2024 are 12-18 months in and discovering the maintenance burden is unsustainable, catalog accuracy has degraded below 50%, and the platform engineer maintaining it is burned out or has quit. This creates a massive pool of "Backstage refugees" — teams that believe in the IDP concept but are disillusioned with the execution. These are dd0c's first customers.
+
+**2. Platform Engineering Goes Mainstream (2025-2026)**
+Platform engineering is no longer a luxury — it's expected. Budget is being allocated specifically for developer experience tooling. The question has shifted from "do we need an IDP?" to "which one?" This means more buyers, more budget, and less evangelism required.
+
+**3. AI-Native Expectations (2026)**
+Engineers use Copilot, Cursor, and Claude daily. A developer portal that requires manual YAML maintenance feels archaic. The expectation is: "Why can't it just figure out what services we have?" dd0c's auto-discovery + AI query model aligns with 2026 developer expectations. Backstage's manual model feels like 2020.
+
+**4. FinOps + Platform Engineering Convergence**
+Engineering leaders want cost-per-service alongside ownership and health. No standalone IDP does this well. dd0c's platform approach (portal + cost + alerts) is uniquely positioned for this convergence.
+
+**Regulatory Tailwinds:**
+- SOC 2 / ISO 27001 adoption increasing — auditors ask "show me service ownership." An always-current IDP is compliance infrastructure.
+- EU DORA (Digital Operational Resilience Act) requires service mapping and incident response capabilities for financial services.
+- US Executive Order on AI requires organizations to inventory AI-powered services and their owners.
+- Platform engineering job postings up 340% since 2023 — the buyer persona is proliferating.
+
+**The window is open. It won't stay open forever.** GitHub could ship a native service catalog. Datadog could invest seriously in theirs. The 12-18 month head start window is the entire strategic opportunity.
+
+---
+
+## 3. PRODUCT DEFINITION
+
+### Value Proposition
+
+**For platform engineers** who are drowning in Backstage maintenance, dd0c/portal is a self-maintaining developer portal that generates its catalog from infrastructure reality. Unlike Backstage, which requires manual YAML files that nobody updates, dd0c/portal auto-discovers services from AWS and GitHub with >80% accuracy in 5 minutes and zero ongoing maintenance.
+
+**For engineering directors** who can't answer "who owns what?" with confidence, dd0c/portal provides always-current, authoritative service ownership mapping. Unlike quarterly manual audits or stale Google Sheets, dd0c/portal auto-refreshes from source-of-truth systems and answers compliance questions in seconds, not weeks.
+
+**For every engineer** who wastes time searching for service information, dd0c/portal is a Cmd+K search bar that's faster than asking in Slack. Unlike scattered documentation across Confluence, Notion, and pinned Slack messages, dd0c/portal is one surface with everything: owner, repo, health, on-call, cost, runbook.
+
+**Core design principle: "Calm surface, deep ocean."** The default view is radically simple — service name, owner, health, repo link. One line per service. Scannable in 2 seconds. But depth is one click away: dependencies, cost, deployment history, runbook, scorecard. Start simpler than a spreadsheet, grow deeper than Backstage — but only when the user asks for depth.
+
+### Personas
+
+#### Persona 1: Jordan — The New Hire
+- Software Engineer II, 2 years experience, just joined a 60-person engineering org
+- Spends first week on a scavenger hunt across Slack, Confluence, GitHub, and Google Docs trying to map the service landscape
+- Assigned a ticket involving an unfamiliar service — can't find the right repo, the owner, or current documentation
+- **JTBD:** "When I join a new company, I want to quickly understand the service landscape so I can contribute meaningfully without feeling lost."
+- **dd0c moment:** Jordan opens the portal, hits Cmd+K, types the service name from standup, and instantly sees: owner, repo, description, on-call, last deploy. What used to take 3 days takes 3 seconds.
+
+#### Persona 2: Alex — The Platform Engineer
+- Senior Platform Engineer, 6 years experience, maintaining Backstage for 14 months
+- Spends 40% of time on Backstage maintenance instead of building actual platform tooling
+- Sends monthly "please update your catalog-info.yaml" Slack messages that everyone ignores
+- Has a secret spreadsheet that's more accurate than Backstage
+- **JTBD:** "When I'm responsible for the developer portal, I want it to maintain itself so I can focus on building actual platform capabilities."
+- **dd0c moment:** Alex connects the AWS IAM role and GitHub OAuth. 30 seconds later, 147 services appear — with owners, repos, and health status. Alex's spreadsheet is obsolete. The monthly YAML nagging stops forever.
+
+#### Persona 3: Priya — The Engineering Director
+- Director of Engineering, manages 8 teams (62 engineers), reports to VP of Engineering
+- Can't answer "which teams own which services?" without a multi-week manual audit
+- SOC 2 audit in 3 months — compliance team needs service ownership evidence she can't produce
+- Incident MTTR inflated by 15+ minutes because nobody knows who to page
+- **JTBD:** "When preparing for a compliance audit, I want an always-current inventory of services, owners, and maturity attributes so I can produce evidence in minutes, not weeks."
+- **dd0c moment:** Priya opens the portal dashboard. Every service, every owner, every health status — live, accurate, exportable. The SOC 2 evidence that used to take 2 weeks is generated in 30 seconds.
+
+### Feature Roadmap
+
+#### MVP (V1) — "The 5-Minute Miracle" — Months 1-3
+
+The MVP is ruthlessly scoped. It does three things and does them perfectly:
+
+**Auto-Discovery Engine (THE product)**
+- AWS discovery via read-only IAM role: EC2, ECS, Lambda, RDS, API Gateway, CloudFormation stacks
+- Infers "services" from CloudFormation stacks, ECS services, tagged resource groups, and naming conventions
+- GitHub org scanner: repos, languages, CODEOWNERS, README extraction, deployment workflows
+- Cross-references AWS resources ↔ GitHub repos to build service-to-repo mapping
+- Ownership inference from CODEOWNERS, git blame frequency, and team membership
+- Confidence scores on every data point: "85% confident @payments-team owns this (source: CODEOWNERS + git history)"
+- Auto-refresh on configurable schedule (default: every 6 hours)
+- **Target: >80% accuracy on first run. This is the entire business.**
+
+**Service Catalog UI**
+- Service cards: name, owner (with confidence), description (extracted from README), repo link, tech stack, health status, last deploy timestamp
+- Cmd+K instant search across all services, teams, and keywords — results in <500ms
+- Progressive disclosure: default view is one-line-per-service table. Click to expand full service detail.
+- Team directory: which team owns which services, team members, contact info
+- Correction UI: one-click to fix wrong ownership or add missing data. Corrections feed back into the discovery model.
+
+**Integrations (Minimum Viable)**
+- AWS: read-only IAM role (runs in customer's VPC, pushes metadata to SaaS)
+- GitHub: OAuth app for org access
+- PagerDuty/OpsGenie: import on-call schedules, map to services ("Who's on-call for this right now?")
+- Slack bot: `/dd0c who owns <service>` — responds in <2 seconds
+
+**Infrastructure**
+- Auth: GitHub OAuth (SSO via GitHub org membership)
+- Billing: Stripe, $10/engineer/month, self-serve credit card signup
+- Onboarding: connect AWS + GitHub in 3 clicks, auto-discovery runs, catalog populated
+
+**What V1 explicitly does NOT include:**
+- No scorecards or maturity models
+- No dependency graphs
+- No software templates or scaffolding
+- No custom plugins or extensibility
+- No Kubernetes or Terraform discovery (AWS + GitHub only)
+- No advanced RBAC (org-level access only)
+- No self-hosted option
+
+#### V1.1 — "The Daily Habit" — Months 4-6
+
+**Dependency Visualization**
+- Auto-inferred service dependency graph from AWS VPC flow logs, API Gateway routes, and Lambda event sources
+- Visual dependency map (click a service → see what it calls and what calls it)
+- Impact radius: "If this service goes down, these 5 services are affected"
+
+**Scorecards (Lightweight)**
+- Production readiness checklist per service: has README? Has CODEOWNERS? Has runbook? Has monitoring? Has on-call rotation?
+- Org-wide scorecard dashboard: "72% of services meet production readiness standards"
+- Exportable for compliance evidence (SOC 2, ISO 27001)
+
+**Backstage Migrator**
+- One-click import from existing `catalog-info.yaml` files
+- Maps Backstage catalog entries to dd0c services, merges with auto-discovered data
+- "Migrate from Backstage in 10 minutes" — the acquisition wedge for Backstage refugees
+
+**Enhanced Discovery**
+- Terraform state file parsing (service infrastructure mapping)
+- Kubernetes label/annotation discovery (for K8s-based services)
+- Improved accuracy via ML-assisted pattern matching from user corrections across customers
+
+#### V2 — "Ask Your Infra" — Months 7-12
+
+**AI Natural Language Querying (The Differentiator)**
+- "Ask Your Infra" agent: natural language questions against the service catalog
+- Examples:
+  - "Which services handle PII data?"
+  - "Who owns the services that the checkout flow depends on?"
+  - "Show me all services that haven't been deployed in 90 days"
+  - "What's the total AWS cost of the payments team's services?"
+  - "Which services don't have runbooks?"
+- Powered by LLM with the service catalog as structured context — not hallucinating, querying verified data
+- Available in portal UI, Slack bot, and CLI
+
+**dd0c Platform Integration**
+- dd0c/cost integration: per-service AWS cost attribution on every service card
+- dd0c/alert integration: alert routing to service owner, incident history on service card
+- dd0c/run integration: linked runbooks per service, AI-assisted incident response
+- Cross-module dashboard: "Service X costs $847/mo, had 3 incidents this month, has 2 IaC drifts"
+
+**Advanced Features**
+- Change feed: "What changed in the service landscape this week?" (new services, ownership changes, health status changes)
+- Zombie service detection: services with no deployments, no traffic, and no owner for 90+ days
+- Cost anomaly per service: "Service X cost jumped 340% this week"
+
+#### V3 — "The Platform" — Months 12-18
+
+**Multi-Cloud**
+- GCP discovery (Cloud Run, GKE, Cloud Functions)
+- Azure discovery (App Service, AKS, Functions)
+- Multi-cloud service catalog with unified view
+
+**Enterprise Features**
+- Advanced RBAC (team-level permissions, service-level visibility controls)
+- SSO (Okta, Azure AD) beyond GitHub OAuth
+- Audit logs (who viewed/changed what, when)
+- Compliance reports (SOC 2 evidence packages, auto-generated)
+- API access (programmatic catalog queries for CI/CD integration)
+
+**Agent Control Plane**
+- Registry for AI agents operating in the infrastructure
+- "Which AI agents have access to which services?"
+- Agent activity monitoring and governance
+- Position dd0c/portal as the source of truth that AI agents query — not competing with agents, but enabling them
+
+### User Journey: First 30 Minutes
+
+```
+Minute 0:00 — Engineer discovers dd0c/portal (blog post, HN, colleague recommendation)
+Minute 0:30 — Signs up with GitHub OAuth. Enters credit card. 30 seconds.
+Minute 1:00 — Onboarding wizard: "Connect your AWS account." Provides CloudFormation
+              template for read-only IAM role. One-click deploy.
+Minute 3:00 — AWS connected. GitHub org already connected via OAuth.
+              "Starting auto-discovery..."
+Minute 3:30 — Discovery complete. "Found 147 services across 89 repos and 12 AWS accounts."
+              The "Holy Shit" moment.
+Minute 4:00 — Engineer sees the catalog. Services listed with names, owners (with confidence
+              scores), repos, health status. Scans the list. "This is... actually right."
+Minute 5:00 — Hits Cmd+K. Types "payment." Instant results: payment-gateway, payment-processor,
+              payment-webhook. Clicks payment-gateway → sees owner, repo, on-call, last deploy,
+              tech stack. All auto-discovered.
+Minute 6:00 — Notices one wrong owner. Clicks "Correct" → selects the right team → done.
+              System learns. Confidence score on similar services adjusts.
+Minute 8:00 — Copies the Slack bot install link. Adds /dd0c to the team Slack.
+Minute 10:00 — Types /dd0c who owns auth-service in #engineering. Bot responds instantly
+               with owner, on-call, repo link. Three colleagues react with 👀.
+Minute 15:00 — Sets dd0c/portal as browser homepage.
+Minute 30:00 — Shares screenshot in team Slack: "Look what I just found."
+               Three teammates sign up within the hour.
+```
+
+### Pricing
+
+**Free Tier — "Try It"**
+- Up to 10 engineers
+- Up to 25 discovered services
+- Cmd+K search, basic service cards
+- No Slack bot, no PagerDuty integration
+- Purpose: let individual engineers try the product without budget approval. They become internal champions.
+
+**Team Tier — $10/engineer/month — "The Sweet Spot"**
+- Unlimited services
+- Full auto-discovery (AWS + GitHub)
+- Cmd+K search, Slack bot, PagerDuty/OpsGenie integration
+- Confidence scores, correction UI, auto-refresh
+- Scorecards (V1.1+)
+- Self-serve signup, credit card, no sales call
+- No minimum commitment, cancel anytime
+- **Target customer: 20-100 engineers → $200-$1,000/month**
+
+**Business Tier — $25/engineer/month — "The Platform" (Month 12+)**
+- Everything in Team, plus:
+- dd0c module integrations (cost, alert, drift, run)
+- "Ask Your Infra" AI agent
+- Dependency graphs
+- Advanced RBAC, SSO (Okta/Azure AD)
+- Compliance reports (SOC 2 evidence packages)
+- Priority support
+- **Target customer: 100-500 engineers → $2,500-$12,500/month**
+
+**Pricing rationale:**
+- $10/engineer removes the procurement barrier. For a 50-person team, that's $500/month — within most engineering managers' discretionary spending authority. No procurement process, no legal review, no 6-month sales cycle.
+- The ROI calculation is trivial: "Does this save each engineer more than 15 minutes per month?" The Cmd+K search alone saves 15 minutes in the first week.
+- $10/engineer is structurally impossible for VC-backed competitors to match. Port and Cortex have 50+ employees and $30M+ in funding. Their cost structure requires $25-50/engineer. dd0c's cost structure is one person + cloud hosting.
+- Pricing evolution planned: $10 at launch → introduce Business tier at $25 by month 12 → effective ARPU rises to $15-20 as customers add modules and upgrade.
+
+---
+
+## 4. GO-TO-MARKET PLAN
+
+### Launch Strategy: Targeting Backstage Refugees
+
+The primary acquisition channel is not paid ads, not outbound sales, and not conference sponsorships. It's content-driven PLG targeting the single most receptive audience in DevOps: **teams that tried Backstage and failed.**
+
+These teams have already self-selected. They believe in the IDP concept. They've invested 3-18 months. They've felt the pain of YAML rot, plugin maintenance, and catalog decay. They are actively searching for alternatives. They are dd0c's first 100 customers.
+
+**Where they congregate:**
+- Backstage Discord and GitHub Discussions (frustrated questions, feature requests that will never ship)
+- r/devops and r/platformengineering (posts titled "Backstage alternatives?" appear monthly)
+- Platform Engineering Slack community (~15K members)
+- PlatformCon conference attendees and speakers
+- Blog posts titled "What We Learned From Our Backstage Implementation" (translation: "Why We Failed")
+- Google searches for "Backstage alternatives," "Backstage too complex," "IDP without YAML"
+
+### Content Strategy: Engineering-as-Marketing
+
+Every piece of content serves one of two purposes: (1) capture Backstage refugees, or (2) demonstrate the 5-minute magic.
+
+**Tier 1: Flagship Content (Pre-Launch)**
+
+1. **"I Maintained Backstage for 18 Months. Here's Why I Quit."**
+   - Honest, technical post-mortem. Not a hit piece — a relatable story.
+   - Target: HN front page, r/devops top post, Twitter/X viral thread
+   - CTA: "We built the alternative. Try it in 5 minutes."
+   - This single piece of content, if it resonates, generates the first 50-100 signups.
+
+2. **"The Backstage Migration Calculator"**
+   - Free web tool: input your Backstage metrics (engineers, hours/week on maintenance, catalog accuracy %)
+   - Output: total cost of ownership, comparison to dd0c/portal pricing, projected time savings
+   - Lead capture: email required for full report
+   - SEO targets: "Backstage cost," "Backstage alternatives," "Backstage vs"
+   - This tool validates demand before a single line of portal code is written.
+
+3. **"Is Your IDP Actually Used? A 5-Minute Audit"**
+   - Checklist/scorecard format. "How many engineers visited your IDP this week? Is your catalog >80% accurate?"
+   - Most teams score poorly → creates urgency → CTA to dd0c
+
+**Tier 2: SEO & Thought Leadership (Launch + Ongoing)**
+
+4. **"Zero-Config Service Discovery: How We Auto-Map Your AWS Infrastructure"** — technical deep-dive
+5. **"The Internal Developer Portal Buyer's Guide (2026)"** — honest comparison including dd0c's weaknesses
+6. **"Why Your Service Catalog Is Lying to You"** — thought piece on manual vs. auto-discovered catalogs
+7. **"How [Company] Replaced Backstage in 5 Minutes"** — customer case study video walkthroughs
+
+**Tier 3: Community & Social Proof (Post-Launch)**
+
+8. Customer case studies (as soon as first 3 customers are live)
+9. Monthly "State of the Catalog" reports — anonymized data on discovery accuracy and adoption patterns
+10. Open-source the discovery agent — builds trust, enables security audits, creates community contributions
+
+### Growth Loops
+
+**Loop 1: The Slack Bot Viral Loop**
+Every time an engineer uses `/dd0c who owns <service>` in a public Slack channel, it's a product demo. Colleagues see the instant response, ask "what is this?", and sign up. The Slack bot is a passive viral mechanism that scales with usage.
+
+**Loop 2: The Screenshot Loop**
+The "Holy Shit" moment — 147 services auto-discovered in 30 seconds — is inherently shareable. Engineers screenshot the catalog and share it in team Slack, Twitter/X, and engineering blogs. The visual impact of a populated catalog appearing from nothing is the product's best marketing asset.
+
+**Loop 3: The Org Expansion Loop**
+One team adopts dd0c/portal → other teams in the org notice → engineering director sees cross-team adoption → approves org-wide rollout. Bottom-up adoption creates top-down demand. This is the Slack/Figma playbook.
+
+**Loop 4: The dd0c Platform Upsell Loop**
+Portal customer sees per-service cost data (dd0c/cost integration) → "Wait, Service X costs $847/month?!" → upgrades to dd0c/cost → sees alert routing (dd0c/alert) → upgrades again. Portal is the top-of-funnel for the entire dd0c platform.
+
+**Viral coefficient target:** k=0.3 (each new user brings 0.3 additional users through Slack sharing and team adoption). At k=0.3, organic growth supplements content marketing but doesn't replace it.
+
+### Partnership Strategy
+
+**AWS Marketplace (Month 6)**
+- List dd0c/portal on AWS Marketplace
+- Customers with committed AWS spend (EDPs) can use marketplace credits to pay for dd0c — removes the budget objection entirely
+- AWS Marketplace provides credibility signaling and co-marketing opportunities via ISV Partner program
+
+**GitHub Marketplace (Month 3)**
+- List the GitHub App on GitHub Marketplace
+- Lower friction than AWS Marketplace, higher discovery volume
+- Natural discovery point for GitHub-centric engineering teams
+
+**PagerDuty / OpsGenie Integration Partners**
+- Deep integration with on-call tools is a key feature
+- Co-marketing: "Route alerts to the right owner automatically"
+- PagerDuty partner ecosystem promotes integrated tools
+
+**Strategic Non-Partnerships:**
+- Do NOT partner with Datadog (competing service catalog)
+- Do NOT seek AWS investment (maintain independence and future multi-cloud optionality)
+- Do NOT pursue SI/consulting partnerships (wrong channel for $10/eng PLG product)
+
+### 90-Day Launch Timeline
+
+**Weeks 1-4: Build the Core**
+
+| Week | Deliverable |
+|------|------------|
+| 1 | AWS auto-discovery engine: EC2, ECS, Lambda, RDS via read-only IAM role. Map resources to services using CloudFormation stacks, tags, naming conventions. |
+| 2 | GitHub org scanner: repos, languages, CODEOWNERS, README extraction. Cross-reference with AWS to build service-to-repo mapping. |
+| 3 | Service catalog UI: service cards, Cmd+K instant search (<300ms). Auth (GitHub OAuth), billing (Stripe). |
+| 4 | Onboarding flow (connect AWS + GitHub in 3 clicks). Confidence scores. Correction UI. |
+
+**Weeks 5-8: Polish & Beta**
+
+| Week | Deliverable |
+|------|------------|
+| 5 | Slack bot: `/dd0c who owns <service>`. Responds in <2 seconds. |
+| 6 | PagerDuty/OpsGenie integration: import on-call schedules, map to services. |
+| 7 | Backstage YAML importer. Landing page. Waitlist. |
+| 8 | Beta launch: invite 20 teams. Personal onboarding call with each. Obsessively collect feedback on discovery accuracy. |
+
+**Weeks 9-12: Launch & First Revenue**
+
+| Week | Deliverable |
+|------|------------|
+| 9 | Incorporate beta feedback. Fix top 5 discovery accuracy issues. |
+| 10 | Publish "I Maintained Backstage for 18 Months" blog post. Ship Backstage Migration Calculator. |
+| 11 | Public launch: HN "Show HN," Reddit (r/devops, r/platformengineering, r/aws), Twitter/X thread. Coordinated for maximum simultaneous visibility. |
+| 12 | Convert beta users to paid. Target: 10 paying customers by end of week 12. |
+
+**Pre-launch content (before writing portal code):**
+- Ship the Backstage Migration Calculator and "Why I Quit Backstage" blog post first
+- Validate demand with content before investing in engineering
+- If the content doesn't resonate, the product won't either
+
+---
+
+## 5. BUSINESS MODEL
+
+### Revenue Model
+
+**Primary revenue:** Per-seat SaaS subscription at $10/engineer/month (Team tier).
+
+**Revenue expansion mechanisms:**
+1. **Seat expansion:** As customer engineering teams grow, revenue grows automatically
+2. **Tier upgrade:** Team ($10/eng) → Business ($25/eng) as customers need RBAC, compliance, AI queries
+3. **Module attach:** Portal customers add dd0c/cost, dd0c/alert, dd0c/run — each at $10-15/eng/month
+4. **Effective ARPU trajectory:** $10/eng (portal only) → $25/eng (portal + 1 module) → $40/eng (portal + 2 modules + Business tier)
+
+**Revenue model is NOT:**
+- Usage-based (predictable revenue > usage volatility for a solo founder)
+- Enterprise sales-led (no sales team, no SDRs, no demo calls)
+- Freemium-dependent (free tier is acquisition, not the business)
+
+### Unit Economics
+
+**Cost structure (solo founder, Month 6):**
+
+| Cost Item | Monthly |
+|-----------|---------|
+| Cloud infrastructure (AWS/Vercel) | $500-1,500 |
+| Stripe payment processing (2.9% + $0.30) | ~3% of revenue |
+| Domain, email, tooling | $200 |
+| LLM API costs (discovery + AI queries, V2) | $200-500 |
+| Brian's time (opportunity cost) | $15,000 (imputed) |
+| **Total operating cost (excl. founder)** | **~$2,000-2,500/month** |
+
+**Gross margin:** ~90% (SaaS infrastructure costs are minimal at this scale)
+
+**Customer Acquisition Cost (CAC):** Near-zero for content-driven PLG. Primary cost is Brian's time writing blog posts and building free tools. Imputed CAC: ~$50-100 per customer (time spent on content ÷ customers acquired).
+
+**Lifetime Value (LTV):** At $500/month average (50 engineers × $10), with 5% monthly churn → average customer lifetime of 20 months → LTV = $10,000. LTV:CAC ratio > 100:1. (This is unusually high because CAC is near-zero for PLG.)
+
+**Payback period:** <1 month (self-serve credit card, no sales cycle, immediate revenue).
+
+### Path to Revenue Milestones
+
+**$10K MRR — "Validation" (Target: Month 9-12)**
+
+| Metric | Requirement |
+|--------|-------------|
+| Customers | 20-25 |
+| Avg engineers per customer | 40-50 |
+| Avg MRR per customer | $400-500 |
+| Monthly churn | <5% |
+| **Milestone significance** | Product-market fit confirmed. Solo founder business is viable. |
+
+**$50K MRR — "Sustainability" (Target: Month 15-18)**
+
+| Metric | Requirement |
+|--------|-------------|
+| Customers | 80-100 |
+| Avg engineers per customer | 50-60 |
+| Avg MRR per customer | $500-625 |
+| Module attach rate | >20% (portal + at least one other dd0c module) |
+| Monthly churn | <3% |
+| **Milestone significance** | $600K ARR. Hire first contractor (support + integration maintenance). Brian focuses on product + growth. |
+
+**$100K MRR — "Scale" (Target: Month 20-24)**
+
+| Metric | Requirement |
+|--------|-------------|
+| Customers | 150-200 |
+| Avg engineers per customer | 55-65 |
+| Avg MRR per customer | $500-667 |
+| Business tier adoption | >15% of customers |
+| dd0c platform revenue (all modules) | $200K+ MRR combined |
+| Monthly churn | <2.5% |
+| **Milestone significance** | $1.2M ARR. Hire 1-2 FTEs (engineer + DevRel). Consider seed funding if growth warrants acceleration. |
+
+### Solo Founder Constraints & Sequencing Rationale
+
+The Party Mode board recommended building dd0c/portal **third** in the dd0c launch sequence, after dd0c/route (LLM cost router) and dd0c/cost (AWS cost anomaly). This sequencing is strategically correct for three reasons:
+
+**1. Revenue before platform.**
+dd0c/route and dd0c/cost have immediate monetary ROI — they save companies money on LLM and AWS bills in week one. This generates revenue and political capital before portal launches. Portal is a harder sell as a standalone ("pay us to organize your services") but an easy sell as a platform add-on ("you're already saving $2K/month with dd0c — now see which services cost what").
+
+**2. Data before catalog.**
+dd0c/cost generates per-service cost data. dd0c/alert generates per-service incident data. When portal launches, it can immediately show cost and incident data on every service card — making the portal 10x more valuable on day one than it would be as a standalone catalog. The modules create the data; the portal visualizes it.
+
+**3. Customers before cold-start.**
+By the time portal launches (Month 7-12 of the dd0c platform), dd0c already has paying customers on route and cost. These customers are the portal's first users — no cold-start problem, no "will anyone try this?" uncertainty. They're already in the dd0c ecosystem and the portal is a natural expansion.
+
+**The sequencing risk:** If dd0c/route and dd0c/cost fail to gain traction, portal never launches. This is acceptable — if the FinOps wedge doesn't work, the platform thesis is wrong, and building a standalone IDP at $10/engineer is an even harder path.
+
+**Solo founder capacity allocation (portal phase):**
+- 50% — Discovery engine accuracy (the product)
+- 20% — UI/UX and integrations
+- 15% — Content marketing and community
+- 10% — Infrastructure and ops
+- 5% — Customer support (automated first, personal for top accounts)
+
+---
+
+## 6. RISKS & MITIGATIONS
+
+### Risk 1: GitHub Ships a Native Service Catalog
+**Probability:** 40% within 24 months
+**Impact:** Catastrophic (existential)
+**Severity:** CRITICAL
+
+GitHub already has CODEOWNERS, dependency graphs, repository topics, and Actions. If GitHub adds a "Services" tab that aggregates these into a searchable catalog with auto-discovery from Actions deployment targets, dd0c/portal's core value proposition evaporates for GitHub-only shops.
+
+**Why it might not happen:**
+- GitHub's product strategy is focused on AI (Copilot) and security (Advanced Security). IDP is not their priority.
+- Microsoft/GitHub has historically been slow to build platform features (GitHub Projects took years and is still mediocre).
+- A real IDP requires cross-platform data (AWS, PagerDuty, Datadog) that GitHub doesn't have and may not want to integrate.
+
+**Mitigations:**
+- Build value GitHub can't replicate: cross-platform integration (AWS + GitHub + PagerDuty + Slack), the dd0c module flywheel, and AI-native querying
+- Position dd0c as "GitHub + AWS + everything else" — not "GitHub but better"
+- If GitHub announces a service catalog, immediately pivot to positioning dd0c as the multi-source aggregation layer that includes GitHub's data alongside operational tools
+- **Speed is the primary mitigation.** Establish the beachhead and build switching costs before GitHub moves. Every month of head start is a month of habit formation.
+
+**Kill trigger:** If GitHub announces a native service catalog at GitHub Universe 2026 that integrates with PagerDuty and AWS natively, kill dd0c/portal as a standalone product. Pivot to making it a free feature within the dd0c platform to drive adoption of paid modules.
+
+### Risk 2: Auto-Discovery Accuracy Falls Below 80%
+**Probability:** 35%
+**Impact:** Critical (fatal to PLG motion)
+**Severity:** CRITICAL
+
+The entire product thesis rests on auto-discovery being "good enough" on first run. If engineers connect their AWS account and see 60% accuracy with wrong owners and phantom services, they close the tab and never return. Trust is binary. One bad first impression is fatal.
+
+**Technical challenges:**
+- AWS resources don't always map cleanly to "services" (is each Lambda a service? Each ECS task definition?)
+- GitHub repos don't always map to deployed services (monorepos, shared libraries, archived repos)
+- Ownership inference from git blame is noisy
+- Naming conventions vary wildly across organizations
+
+**Mitigations:**
+- Confidence scores, not assertions: "85% confident @payments-team owns this (source: CODEOWNERS + git history). Confirm or correct."
+- Conservative discovery: show 80 services at 90% accuracy rather than 150 services at 60% accuracy
+- Rapid feedback loop: user corrections improve the model. After 10 corrections, accuracy should be >95%.
+- Invest 50% of engineering time on discovery accuracy in year 1. This is the product.
+- If fully autonomous discovery fails, pivot to "AI-assisted onboarding" — LLMs analyze repos and chat with team leads to build the catalog interactively.
+
+**Kill trigger:** If accuracy is <60% after 3 months of engineering on diverse real-world AWS accounts, the technical thesis is wrong. Kill.
+
+### Risk 3: Solo Founder Burnout / Capacity Ceiling
+**Probability:** 50%
+**Impact:** Critical
+**Severity:** CRITICAL
+
+Building an IDP with AWS integration, GitHub integration, PagerDuty, Slack bot, Cmd+K search, auto-discovery engine, SaaS infrastructure, billing, auth, and customer support — as one person — is enormous. The failure mode isn't "Brian can't code it." It's "Brian builds it, gets 30 customers, and drowns in support tickets, bug reports, and integration requests."
+
+**Mitigations:**
+- Ruthless scope control: V1 is auto-discovery + service cards + Cmd+K + Slack bot + billing. That's it.
+- Architecture for zero maintenance: serverless infrastructure, automated deployments, automated monitoring
+- AI-assisted development: Cursor/Copilot/Claude for 50%+ of code generation
+- Kill criteria with deadlines: if milestones aren't hit, kill the product. Don't let sunk cost fallacy turn a 6-month experiment into a 2-year death march.
+- Hire first contractor at $20K MRR for support and integration maintenance
+
+### Risk 4: Datadog Bundles a Good-Enough Service Catalog
+**Probability:** 30%
+**Impact:** High
+**Severity:** HIGH
+
+Datadog already has a Service Catalog feature. With $2B+ revenue and massive distribution, if they invest seriously, teams already paying for Datadog get an IDP for "free."
+
+**Mitigations:**
+- Datadog's catalog is monitoring-centric (discovers from APM traces, not infrastructure). dd0c discovers from AWS + GitHub, which is more comprehensive.
+- Datadog's pricing ($23+/host/month) means their IDP is "free" only for existing $50K+/year Datadog customers. For teams using CloudWatch or Grafana, Datadog's IDP is irrelevant.
+- Position dd0c as monitoring-agnostic. Works with Datadog, Grafana, CloudWatch, or nothing.
+
+### Risk 5: Market Is Smaller Than Estimated
+**Probability:** 25%
+**Impact:** High
+**Severity:** HIGH
+
+Do teams of 20-50 engineers actually need — and will they pay for — a service catalog? Many function fine with a Google Sheet and Slack.
+
+**Mitigations:**
+- Free tier tests this hypothesis at zero cost. If teams under 30 don't convert, raise minimum target to 50+.
+- Beachhead is "teams that tried Backstage and failed" — already self-selected as needing an IDP.
+- If market is smaller than expected, portal becomes a free feature driving adoption of paid dd0c modules (cost, alerts, drift).
+
+### Kill Criteria Summary
+
+| Milestone | Deadline | Kill Trigger |
+|-----------|----------|-------------|
+| Auto-discovery >75% accuracy on test accounts | Month 3 | <60% accuracy after 3 months of engineering |
+| 10 beta users actively using weekly | Month 4 | Can't get 10 free users |
+| 5 paying customers ($10/eng) | Month 6 | Can't convert 5 teams from free to paid |
+| 20 paying customers, <10% monthly churn | Month 9 | Churn exceeds 10%/month (novelty, not habit) |
+| $10K MRR | Month 12 | Market too small or GTM broken |
+| GitHub announces native service catalog | Any time | Assess if dd0c differentiation survives. If GitHub covers 70%+ of dd0c value, kill standalone portal. |
+
+### Pivot Options
+
+If dd0c/portal fails as a standalone product, three pivot paths exist:
+
+1. **Free portal → paid modules.** Make portal free. Use it as top-of-funnel for dd0c/cost and dd0c/alert. "Free service catalog → discover your services → see that Service X costs $847/month → upgrade to dd0c/cost." Portal becomes the world's most effective upsell mechanism.
+
+2. **AI-assisted onboarding.** If autonomous discovery fails, pivot from "zero-config auto-discovery" to "AI-assisted catalog building." LLMs analyze repos, Slack history, and AWS resources, then chat with team leads to build the catalog interactively. Still faster than Backstage YAML, but with a human-in-the-loop.
+
+3. **Agent Control Plane.** If AI agents make static catalogs obsolete, pivot dd0c/portal to be the registry and governance layer for AI agents operating in infrastructure. "Which agents have access to which services? What did they do? Who authorized it?" The portal becomes infrastructure for AI, not a competitor to AI.
+
+---
+
+## 7. SUCCESS METRICS
+
+### North Star Metric: Daily Active Users (DAU), Not Seats
+
+Most IDP companies measure seats (how many engineers have accounts). This is a vanity metric. An engineer can have an account and never log in. dd0c/portal's north star is **Daily Active Users as a percentage of total seats (DAU/Seats).**
+
+**Why DAU, not seats:**
+- DAU measures habit formation. If engineers open the portal daily, it's their browser homepage. If it's their browser homepage, switching costs are enormous.
+- DAU correlates with retention. High DAU = low churn. Low DAU = the product is a novelty that will be forgotten.
+- DAU drives the viral loop. Active users use the Slack bot, share screenshots, and recommend the product to colleagues. Inactive seat-holders do nothing.
+
+**Target:** >40% DAU/Seats by Month 6. (For context: Slack achieves ~60% DAU/Seats. Linear achieves ~40%. Most enterprise SaaS tools achieve <15%.)
+
+### Leading Indicators (Weekly Review)
+
+| Metric | Month 3 Target | Month 6 Target | Month 12 Target |
+|--------|---------------|----------------|-----------------|
+| DAU / Total Seats | >25% | >40% | >45% |
+| Cmd+K searches per user per week | >3 | >5 | >7 |
+| Slack bot queries per org per week | >5 | >10 | >15 |
+| Auto-discovery accuracy (1 - correction rate) | >75% | >85% | >90% |
+| Time-to-first-value (signup → first search) | <10 min | <5 min | <5 min |
+| Organic signup rate (word-of-mouth %) | >20% | >30% | >40% |
+
+### Lagging Indicators (Monthly Review)
+
+| Metric | Month 6 Target | Month 12 Target |
+|--------|---------------|-----------------|
+| Paying customers | 10-25 | 50-120 |
+| MRR | $4K-12.5K | $25K-72K |
+| Net Revenue Retention (NRR) | >105% | >110% |
+| Monthly logo churn | <8% | <5% |
+| Monthly revenue churn | <6% | <3% |
+| Catalog completeness (% of actual services discovered) | >85% | >90% |
+| Module attach rate (portal customers adding 2nd dd0c module) | N/A | >20% |
+
+### Milestones
+
+| Milestone | Target Date | Significance |
+|-----------|------------|--------------|
+| Auto-discovery engine working (>75% accuracy) | Month 3 | Technical thesis validated |
+| 10 beta users with weekly active usage | Month 4 | Product resonates with real users |
+| First 5 paying customers | Month 6 | Willingness to pay confirmed |
+| "I Quit Backstage" post hits 10K+ views | Month 3-4 | Content-market fit validated |
+| 20 paying customers, <10% churn | Month 9 | Retention thesis validated |
+| $10K MRR | Month 12 | Solo founder business viable |
+| First customer adds second dd0c module | Month 12 | Platform flywheel activated |
+| $50K MRR | Month 18 | Hire first team member |
+| >90% auto-discovery accuracy | Month 12 | Technical moat established |
+| AWS Marketplace listing live | Month 6 | Distribution channel opened |
+
+### The Anti-Metric: Feature Count
+
+Do NOT measure or celebrate feature count. Every feature added is maintenance burden for a solo founder. The goal is maximum value from minimum features. Measure value delivered per feature, not features shipped. The product with 10 features used daily beats the product with 100 features used quarterly.
+
+---
+
+## APPENDIX: SCENARIO PROJECTIONS
+
+### Scenario A: "The Rocket" (15% probability)
+Everything works. Auto-discovery is accurate. Content goes viral. Backstage refugees flock to dd0c.
+
+| Month | Customers | Avg Engineers | MRR | ARR |
+|-------|-----------|--------------|-----|-----|
+| 6 | 25 | 50 | $12,500 | $150K |
+| 9 | 60 | 55 | $33,000 | $396K |
+| 12 | 120 | 60 | $72,000 | $864K |
+
+### Scenario B: "The Grind" (50% probability)
+Product works but growth is slower. Content gets moderate traction. Word of mouth builds gradually.
+
+| Month | Customers | Avg Engineers | MRR | ARR |
+|-------|-----------|--------------|-----|-----|
+| 6 | 10 | 40 | $4,000 | $48K |
+| 9 | 25 | 45 | $11,250 | $135K |
+| 12 | 50 | 50 | $25,000 | $300K |
+
+### Scenario C: "The Stall" (25% probability)
+Discovery accuracy is a persistent challenge. Market is smaller than expected.
+
+| Month | Customers | Avg Engineers | MRR | ARR |
+|-------|-----------|--------------|-----|-----|
+| 6 | 5 | 35 | $1,750 | $21K |
+| 9 | 10 | 35 | $3,500 | $42K |
+| 12 | 15 | 40 | $6,000 | $72K |
+
+### Scenario D: "The Kill" (10% probability)
+GitHub ships a service catalog, or discovery never reaches acceptable accuracy.
+
+| Month | Action |
+|-------|--------|
+| 6 | <5 paying customers. Reassess. |
+| 9 | No improvement. Kill standalone portal. |
+| 9+ | Pivot: portal becomes free feature within dd0c platform to drive paid module adoption. |
+
+**Expected Value (Month 12 ARR):**
+E(ARR) = (0.15 × $864K) + (0.50 × $300K) + (0.25 × $72K) + (0.10 × $0) = **~$298K**
+
+---
+
+*This product brief synthesizes findings from four prior phases: Brainstorm, Design Thinking, Innovation Strategy, and Party Mode Advisory Board Review. All contradictions between phases have been resolved in favor of the most conservative, execution-focused position. The brief is designed for investor-ready presentation and solo founder execution planning.*
+
+*Build the portal. Build it third. Build it fast. And build the discovery engine like your business depends on it — because it does.*
+