Product matrix for indie developers

const riskScore = this.normalize(
  (openIssuesCount * 0.5) + 
  (maintenanceComplexity > 7 ? 30 : 0)
);

// 4. Strategy Score: Alignment
const strategyScore = this.normalize(
  strategicAlignment * 10
);

// Weighted Total
const total = 
  (impactScore * this.config.weights.impact) +
  (effortScore * this.config.weights.effort) +
  (riskScore * this.config.weights.risk) +
  (strategyScore * this.config.weights.strategy);

const recommendation = this.getRecommendation(total);

return {
  total,
  breakdown: { effort: effortScore, impact: impactScore, risk: riskScore, strategy: strategyScore },
  recommendation
};

}

private normalize(value: number): number { return Math.min(100, Math.max(0, value)); }

private getRecommendation(score: number): AssetScore['recommendation'] { if (score >= this.config.thresholds.investScore) return 'invest'; if (score >= this.config.thresholds.harvestScore) return 'harvest'; if (score >= this.config.thresholds.killScore) return 'maintain'; return 'sunset'; } }

#### 3. Automated Data Ingestion

To prevent manual data entry, the system should ingest metrics from GitHub/GitLab APIs. A cron job or CI pipeline step can update the `AssetMetrics` based on repository activity.

```typescript
// src/metrics/github-ingestor.ts

import { Octokit } from '@octokit/rest';

export async function fetchRepoMetrics(repo: string, token: string): Promise<Partial<AssetMetrics>> {
  const octokit = new Octokit({ auth: token });
  const [owner, name] = repo.split('/');

  const { data: repoData } = await octokit.repos.get({ owner, repo: name });
  const { data: issues } = await octokit.issues.listForRepo({ owner, repo: name, state: 'open' });
  
  // Calculate days since last commit
  const { data: commits } = await octokit.repos.listCommits({ owner, repo: name, per_page: 1 });
  const lastCommitDate = commits[0]?.commit?.committer?.date 
    ? new Date(commits[0].commit.committer.date) 
    : new Date();
  const daysAgo = Math.floor((Date.now() - lastCommitDate.getTime()) / (1000 * 60 * 60 * 24));

  return {
    openIssuesCount: issues.length,
    lastCommitDaysAgo: daysAgo,
    // Star count can proxy for market interest
    marketGrowthPotential: Math.min(10, Math.log10(repoData.stargazers_count + 1) * 3)
  };
}

4. Dashboard Integration

The matrix scores should feed into a lightweight dashboard. For indie developers, a static site generator (like Next.js or Astro) consuming a JSON output from the matrix engine is sufficient. This dashboard visualizes the portfolio as a scatter plot (Effort vs. Impact) and lists assets by recommendation status, enabling rapid decision-making during weekly reviews.

Pitfall Guide

Implementing a Product Matrix introduces new complexities. Avoid these common mistakes based on production experience with indie portfolios.

1. Over-Engineering the Scoring Model:

   • Mistake: Creating complex algorithms with 20+ variables.
   • Consequence: The matrix becomes opaque and hard to maintain. Developers stop trusting the scores.
   • Best Practice: Limit dimensions to four core pillars. Use logarithmic scaling for metrics like MRR to prevent outliers from skewing the entire matrix.

2. Ignoring "Zombie" Assets:

   • Mistake: Focusing only on active projects and neglecting archived or low-traffic repositories.
   • Consequence: Security vulnerabilities and dependency rot in unused assets cause incidents.
   • Best Practice: Include all repositories in the matrix. Assign a "dormant" flag that triggers automated dependency updates but suppresses feature development recommendations.

3. Static Weighting:

   • Mistake: Setting weights once and never adjusting them.
   • Consequence: The matrix fails to adapt to changing business phases (e.g., growth vs. stability).
   • Best Practice: Review weights quarterly. During a cash-flow crisis, increase the weight of impact and risk. During R&D phases, increase strategy.

4. Analysis Paralysis:

   • Mistake: Spending more time optimizing the matrix than building products.
   • Consequence: Zero shipping velocity.
   • Best Practice: Cap matrix review time to 30 minutes per week. The matrix is a decision aid, not a game. If a decision is obvious, skip the calculation.

5. Vanity Metrics Inclusion:

   • Mistake: Including metrics like "GitHub Stars" or "Twitter Followers" as primary inputs.
   • Consequence: Prioritizing marketing-friendly features over revenue-generating ones.
   • Best Practice: Correlate vanity metrics with business outcomes. Only include them if there is a proven conversion path to revenue or retention.

6. Emotional Attachment Bias:

   • Mistake: Manually overriding matrix recommendations to save a favorite project.
   • Consequence: Resource drain on low-value assets.
   • Best Practice: Treat the matrix as an objective advisor. If you override a "sunset" recommendation, document the business case and set a hard deadline for re-evaluation.

7. Lack of Actionable Outputs:

   • Mistake: Generating scores without clear actions.
   • Consequence: Developers see a score but don't know what to do.
   • Best Practice: Map scores to explicit actions. Invest = Allocate 70% dev time. Harvest = Optimize monetization, reduce dev time. Sunset = Archive code, notify users, redirect traffic.

Production Bundle

Action Checklist

• Audit Assets: List all active repositories, SaaS products, and digital assets in a master inventory.
• Define Config: Create product-matrix.config.ts with weights and thresholds aligned to current business goals.
• Implement Ingestion: Set up scripts to pull metrics from GitHub/GitLab and payment gateways (Stripe/LemonSqueezy) automatically.
• Build Dashboard: Deploy a lightweight view to visualize portfolio distribution and asset scores.
• Schedule Reviews: Block 30 minutes weekly to review matrix recommendations and update qualitative metrics.
• Establish Kill Criteria: Define hard rules for sunsetting assets (e.g., MRR < $50 for 90 days with low strategic fit).
• Automate Alerts: Configure CI/CD to flag assets where maintenanceComplexity or risk scores exceed safe limits.

Decision Matrix

Configuration Template

Copy this configuration to bootstrap your matrix. Adjust weights based on your current phase.

// product-matrix.config.ts

import { MatrixConfig } from './src/matrix/types';

export const matrixConfig: MatrixConfig = {
  weights: {
    // Current focus: Growth
    impact: 0.40,  // Revenue and user value
    effort: 0.20,  // Development cost
    risk:   0.20,  // Technical and market risk
    strategy: 0.20 // Long-term alignment
  },
  thresholds: {
    investScore: 75,   // Top tier: Allocate maximum resources
    harvestScore: 50,  // Mid tier: Optimize revenue, minimize dev
    killScore: 25      // Bottom tier: Plan sunset or pivot
  }
};

// Usage
// const engine = new ProductMatrixEngine(matrixConfig);

Quick Start Guide

1. Initialize Repository:

   mkdir indie-product-matrix && cd indie-product-matrix
   npm init -y
   npm install typescript @octokit/rest dotenv
   npx tsc --init
   

2. Add Core Files: Create src/matrix/types.ts, src/matrix/engine.ts, and product-matrix.config.ts using the code templates above.

3. Configure Environment: Create .env with your GitHub token and asset list:

   GITHUB_TOKEN=ghp_xxxx
   ASSETS=my-saas-repo,my-tool-repo,my-template-repo
   

4. Run Audit: Create src/audit.ts to load assets, fetch metrics, calculate scores, and output a JSON report.

   npx ts-node src/audit.ts
   

   Review the output JSON for recommendations.

5. Iterate: Integrate the audit script into your weekly workflow. Update qualitative metrics manually in a assets.json file if needed, and let the engine drive your prioritization.