Teams use Renovate for automated updates but lack visibility into which packages are approaching EOL, which are unhealthy, and where risk is accumulating across their codebase. They cobble together SBOM tools, GitHub API scripts, and EOL feeds manually.
A SaaS dashboard that ingests SBOMs, connects to GitHub/registry APIs, and overlays EOL dates, vulnerability data, and maintenance health scores. Provides a single pane of glass showing obsolescence risk by service, team, or org with alerting on approaching EOL deadlines.
Freemium - free for up to 5 repos, paid tiers ($49-$299/mo) for org-wide dashboards, SSO, and custom alerting.
Pain is real but moderate. The Reddit thread confirms teams cobble together manual solutions, and large codebases need 'a dedicated developer' for this. But it is a slow-burn operational pain, not a hair-on-fire emergency. Teams tolerate the status quo with spreadsheets and scripts. The pain spikes only around major EOL events (Node 16 EOL, Python 2 sunset) rather than being constant. It is more of a 'this is annoying and risky' problem than 'we cannot ship without this.'
TAM is meaningful. Every company with 10+ services and modern dependency management is a potential customer. Estimated ~50K+ mid-to-large engineering orgs globally. At $100/mo average, that is $60M+ addressable. The broader SCA market is $3B+ and growing. However, DependencyRadar targets a niche within this market (lifecycle/health vs. security), and the niche-within-a-niche risk means realistic near-term serviceable market is smaller — probably $5-15M.
This is the weakest dimension. Existing free tools (endoflife.date, deps.dev, Renovate) cover adjacent needs. Engineering teams are accustomed to building internal tooling for this exact problem ('use the GitHub API to generate reports'). The Reddit comments suggest people solve this with scripts, not purchased products. At $49-299/mo it competes with 'we could just build this internally in a sprint.' Security tools (Snyk, Mend) justify their pricing via compliance requirements — EOL tracking lacks that regulatory forcing function today. The SBOM mandate angle could change this.
Very buildable. Core data sources exist and have APIs: endoflife.date API, deps.dev API, Libraries.io API, OpenSSF Scorecard API, GitHub API, npm/PyPI/Maven registry APIs. SBOM parsing is well-defined (CycloneDX, SPDX libraries exist). The MVP is essentially an aggregation layer + dashboard. A competent solo dev could build SBOM ingestion + EOL overlay + basic health scoring + a React dashboard in 6-8 weeks. No novel algorithms required — it is integration engineering, not ML.
This is the strongest dimension. No existing product combines EOL tracking + obsolescence risk scoring + package health + SBOM ingestion into a unified cross-org dashboard. Security tools (Snyk, Mend, Sonatype) focus on CVEs. Compliance tools (FOSSA) focus on licenses. Update tools (Renovate) focus on version bumps. Data sources (endoflife.date, deps.dev) are raw APIs. The 'dependency lifecycle management' layer genuinely does not exist as a product. The gap is clear and well-defined.
Strong subscription fit. Dependencies change constantly — new releases, new EOL announcements, packages losing maintainers, new vulnerabilities. The dashboard must be continuously updated, which justifies ongoing subscription. Monitoring/alerting is inherently recurring. Once integrated into an org's workflow (SBOM pipeline, team dashboards, planning cycles), switching costs increase. Per-repo or per-service pricing scales naturally with customer growth.
- +Clear, well-defined gap in the market — no existing product does this. The competitive moat is being first to productize a capability every platform team wishes they had.
- +Technically straightforward MVP — aggregation of existing APIs and data sources, not novel R&D. Can ship fast.
- +Strong regulatory tailwinds — SBOM mandates (US, EU) create a growing pool of orgs that already have SBOMs and need tools to analyze them.
- +Natural integration story — complements Renovate, Snyk, Backstage rather than competing. 'Connect your existing tools' positioning.
- +Sticky once adopted — becomes part of planning cycles, quarterly dependency reviews, platform team workflows.
- !Willingness-to-pay is the critical risk. Teams currently solve this with spreadsheets and scripts. The pain may not be acute enough to justify a paid SaaS, especially at the $49-299/mo range where budget holders ask 'can we just build this?'
- !Snyk, Sonatype, or Mend could add EOL/lifecycle features in a product update. They have the customer base, data, and distribution. You would be competing with a feature, not a product.
- !The 'nice-to-have' trap. Vulnerability scanning is compliance-driven (must-have). EOL tracking is operational best practice (nice-to-have). Without a regulatory forcing function, adoption may be slow.
- !Small Reddit signal — 7 upvotes and 7 comments is low engagement. Needs more demand validation beyond one thread.
- !Enterprise sales cycle. The target audience (platform teams at mid-to-large companies) implies long sales cycles, security reviews, and procurement processes that are brutal for a solo founder.
Developer-first SCA platform that scans dependencies for known CVEs, suggests auto-fix PRs, and integrates deeply into IDE/CI/CD pipelines. Covers containers and IaC as well.
Enterprise software supply chain platform that scans components for vulnerabilities, license risks, and quality issues. Nexus Firewall blocks known-bad components at the repository proxy level.
Enterprise SCA platform for open source security and license compliance. Also owns Renovate, the popular dependency update bot, giving them an update+scan story.
Open source license compliance and vulnerability management platform. Core value is automated license scanning and policy enforcement
endoflife.date is a community-maintained API/site tracking EOL dates for 300+ products
A web dashboard that: (1) accepts SBOM upload (CycloneDX/SPDX) or connects to GitHub repos to scan manifests, (2) cross-references every dependency against endoflife.date API + deps.dev + Libraries.io SourceRank + OSV vulnerability data, (3) displays a per-service 'dependency health score' with color-coded EOL timelines (green/yellow/red), (4) sends email/Slack alerts when a tracked dependency enters its last 6 months before EOL. Start with npm + Python ecosystems. Skip SSO, skip team management, skip custom alerting rules — just nail the core value of 'paste your SBOM, see your risk.'
Free: SBOM upload for 1-5 repos, basic EOL timeline view. $49/mo (Team): GitHub org connection, up to 25 repos, Slack alerts, weekly digest emails. $149/mo (Pro): Unlimited repos, multi-org, historical trending, export reports for leadership. $299/mo (Enterprise): SSO, API access, Backstage/PagerDuty integrations, custom SLA. Long-term: usage-based pricing per-service scanned; data licensing (anonymized dependency health benchmarks by industry).
MVP in 6-8 weeks. First free users in weeks 8-12 via Show HN, DevOps subreddits, and Twitter/X dev community. First paying customer in months 3-5, contingent on landing 1-2 design partners from platform teams who are already building this internally. Realistic path to $1K MRR in 4-6 months, $5K MRR in 9-12 months. Enterprise revenue ($10K+ MRR) likely requires 12-18 months and at least one compliance-driven buyer.
- “how do you keep track of which of your packages are obsolete, approaching EOL or still fine? I mean in a dashboard way”
- “renovate handles updates, but visibility is the real gap here”
- “a lot of teams combine SBOM tools + dashboards to actually see risk over time”
- “checking multiple tools manually”
- “if your codebase is big enough, you basically need a dedicated developer for fixing this”
- “use the github api and a couple of other data sources to generate reports... pretty sweet once you have it set up”