A risk-scoring tool for engineering teams wants to make invisible reliability work visible at review time.
Here's a thing that happens constantly in engineering orgs: someone spends six weeks hardening a payments service, reducing deploy batch size, adding contract tests, fixing the retry logic. No incidents happen. At review time, their manager asks what they shipped. They say "reliability improvements." The manager nods and moves on. The engineer who built the flashy new feature gets the promotion.
This isn't a career-ladder rant. It's a data problem. The existing toolchain (Datadog, Jira, GitHub) was never designed to prove a negative. There's no artifact for "incident that didn't happen."
Module Risk Scorer is a bet that this gap is large enough to build a business around.
The core idea is a per-service risk score, updated weekly, that blends four data sources: telemetry (error rates, SLO breaches, incident frequency), code metrics (churn, test coverage, complexity), deployment friction (manual steps, rollback frequency), and ownership concentration. When an engineer marks a PR as a reliability intervention, the system starts tracking the post-intervention risk trend against a counterfactual baseline.
The output isn't another dashboard. It's a quarterly PDF report that an SRE lead can paste into a Jira epic or email to their VP Eng. "Before this refactor sprint, payment-service had a risk score of 74. Three months later it's at 41. Estimated incidents averted: 2.3."
That last number is where things get philosophically complicated.
I want to be honest about this because it's the thing I keep turning over. "Incidents averted" is inherently a counterfactual. You're asking someone to accept a projection of what would have happened as real business value. Senior SREs have seen vendor ROI calculators. They know what made-up numbers look like.
One skeptic in a Slack channel saying "this is just marketing math" can kill word-of-mouth in the exact communities you need for cheap distribution. And your target community, r/sre, is specifically trained to distrust this kind of claim.
The product's entire value proposition rests on making that number credible. Which is why the AI angle here matters more than it does in most ideas.
After 18-24 months of accumulating anonymized intervention-outcome data across customers, you could fine-tune a regression model that predicts expected incident reduction for a specific intervention type given a module's current risk profile. At that point, the "incidents averted" number isn't an extrapolation from your own baseline. It's a prediction informed by what actually happened when 50 other teams ran the same playbook. That's a different thing. That's empirical.
But you don't have that data on day one. You're competing on a future promise for the first two years, and a well-funded internal BI team can replicate the GitHub + Datadog risk calculation in a week using Metabase. The data moat is real, but it takes 18-24 months to materialize. That's a long time to survive on vibes.
SRE leads want this tool. They rarely control discretionary budget above $500/month. Engineering managers have budget but need something that looks like CFO-level ROI proof. Platform teams are often cost centers fighting for headcount, not software licenses.
The $199/month tier is deliberately priced below the approval threshold at most Series B-D companies, where SRE leads can expense things on a card without procurement review. That's clever. It's also a ceiling. Getting from $199/month to a $1,500/month enterprise contract requires navigating procurement processes that will add 3-6 months to your sales cycle, which is brutal for burn rate.
The retention hook that auto-sends the quarterly report to the EM or VP Eng CC'd during onboarding is the right call here. You need a second stakeholder inside the company who expects the report and advocates for renewal when procurement shows up with questions.
Datadog acquired Sqreen, launched Software Delivery Insights with DORA metrics, and has the telemetry data advantage to build module-level risk scoring as a dashboard extension. They probably could ship something in 12 months if they saw traction here.
But here's the thing: Datadog's incentive is to sell more observability. Building a tool that tells you "you've reduced risk enough that you don't need to instrument this service further" is structurally at odds with their business model. The "incidents averted" framing specifically requires a vendor who isn't selling you more monitoring. That's a real conflict of interest that creates at least some protection.
The validation test the idea proposes is the right call before writing any code: build a Notion template and Google Sheet that manually replicates the risk score for one service, offer to run it free for 5 SRE leads from r/sre, and ask directly whether they'd pay $200/month for it automated. Three out of five saying yes is the only signal that matters.
The problem is real. The r/sre thread with 501 upvotes about career ladders rewarding the wrong behavior isn't proof of tooling demand specifically, but the frustration is undeniably there and it's widespread. The G2 reviews citing "no way to quantify tech debt ROI" in Datadog and SonarQube are more direct evidence.
The opportunity score of 7/10 feels about right to me. The survival verdict of "vulnerable" also feels accurate. This lives or dies on two things: whether the "incidents averted" number can be made credible enough that a cynical technical audience accepts it, and whether the data moat accretes fast enough before a larger player decides the surface area is worth copying.
The 6-8 week MVP timeline for a solo dev is achievable. The GitHub-only onboarding mode that produces a partial risk score in under 10 minutes without needing Datadog credentials is the right first hook. If you're building this, that's where I'd start.
The quarterly PDF is the actual product. Build that first. Everything else is infrastructure.