HR data politics, geopolitical hardware risk, and the problem with AI-generated code nobody's solved yet.
Something shifted in the past few weeks. Three ideas that looked like edge cases are suddenly getting traction, and when you look at them together, they're pointing at the same underlying thing: the infrastructure we built in calmer times is cracking under new pressures, and nobody's built the tooling to deal with that yet.
Let's get into it.
Comp & Leveling Analytics for HR is getting attention, and it's not for the reasons you'd expect.
On the surface this looks like a data normalization product. You ingest org chart data from Workday or a CSV, an LLM maps your internal titles to market levels, and you get a report showing which "Senior Directors" are actually performing at the IC4 level. 67% of comp teams cite job architecture inconsistency as a top pain point, per WorldatWork. There are r/humanresources threads about this every week.
But here's what I think is actually going on: the real product isn't the leveling report. It's the artifact. It's the PDF a compensation director can put in front of a CFO and say "the system flagged this, not me." That's a fundamentally different thing to be selling.
Think about what it costs a comp manager to tell a VP that their title is inflated. That's a political conversation that ends careers. But if an AI-generated audit says it? Now it's data. Now it's a compliance posture. The person delivering the message has cover.
This is why the product has legs despite the obvious problems. And there are real problems. The buyer-blocker dynamic is genuine: the comp manager who would buy this often can't act on its output without executive sponsorship, so you're selling a tool whose outputs require political will to use. There's also the one-time audit trap — this thing wants to be a consulting engagement, not a SaaS subscription, and convincing HR to pay $29/employee/year for something they currently think of as a project is a harder budget conversation than it looks.
Pay transparency laws are the tailwind here, but California's been in effect since 2023 and Colorado's since 2021. Companies that needed to clean up their title inflation largely did it. So there's a version of this where the urgency already peaked. I genuinely don't know how to feel about the timing.
What I do think is true: if you can get 50+ customers, the data moat becomes real. The model learns that "Senior Associate" means IC3 at a 200-person SaaS startup and IC5 at a Big 4 firm. Pave has 1,000+ customers' comp data but doesn't own this specific workflow. That gap exists today. It probably won't exist in two years.
This one has a specific moment of demand I want to point at. When Texas sued TP-Link, a thread in r/msp generated 12 substantive comments asking some version of "how do we document our due diligence on this?" MSPs are already doing this vetting. They're cross-referencing the NDAA prohibited vendor list, running Google searches, checking BIS entity lists. Then they're billing clients for that time.
Geopolitical Procurement Risk Scorer for IT Equipment is a bet that those MSPs will pay for automation that produces a client-ready PDF instead of a manual research session.
The pitch is simple: type in "TP-Link," get a risk score backed by BIS, NDAA Section 889, and OFAC citations in under 60 seconds, download a one-page procurement report you can attach to a client proposal. At $149/month for a team plan, you're replacing maybe 3-4 hours of analyst time per month. The math works.
What makes this interesting is the competitive situation. Exiger and Resilinc exist, but they're enterprise tools with enterprise price tags and enterprise implementation timelines. There's genuine space at the $49-$499/month tier for something self-serve. No YC company has built here. That's a meaningful signal.
But I want to be honest about the fatal flaw because it's a real one: this is a data business wearing a SaaS costume. The risk score is only as good as the ownership chain data underneath it. If your tool marks a vendor as Chinese-state-linked after it already divested, trust evaporates immediately. Building accurate, current data on thousands of hardware vendors from public sources alone is probably impossible at the quality level that earns trust. Commercial data licensing from companies like Sayari or D&B could push your costs to $30K-$100K per year before you've hit meaningful revenue.
There's also a liability question nobody talks about in the early-stage discussion: what happens when you score a vendor as "low risk" and they get sanctioned six months later? Credit score companies have legal safe harbors. This space doesn't have that framework yet. You'll need a startup attorney involved before launch, not after.
The validation approach here is smart though. Post in r/msp offering free TP-Link risk reports, manually produce 10 PDFs, then try to sell a $49 follow-up report to those same people. If 3 out of 10 pay, you have something. If nobody does, the "willingness to pay" question answers itself before you've written a line of code.
This is the one I find most technically interesting, and also the one with the most uncomfortable competitive ceiling.
The premise of Automated Test & Fuzz Generator for AI-Generated Code is that LLM-generated code fails in statistically predictable ways. Hallucinated method calls. Off-by-one boundary errors. Silent integer overflow. Incorrect async handling. These aren't random bugs — they're artifacts of how language models generate code. And if the failure modes are predictable, you can build adversarial tests specifically targeting them.
The demand signal is real. An r/programming post about an Amazon service taken down by an AI coding bot got 1,537 upvotes and 171 comments. G2 reviews of CodiumAI specifically call out brittle tests and poor handling of complex integrations. The problem is visible and people are talking about it.
The product is a GitHub App that triggers on PR open, analyzes the diff for AI-generated segments, returns a risk score comment, and can recommend blocking the merge. You can build a functional MVP in 6-8 weeks. The pricing is developer-friendly ($49/month per dev, $199 flat for teams up to 10). The go-to-market is organic: post a Loom of the tool catching a real bug in a Copilot-generated PR, search GitHub for repos with `co-authored-by: GitHub Copilot` in commit history, and DM the maintainers.
Here's the problem I keep coming back to: GitHub sees every Copilot-generated commit. They know which lines came from the model. They could ship native AI code risk scoring into Copilot for Business at zero marginal cost, and Microsoft's 2024 Copilot roadmap already mentions AI code review features. If that ships, standalone tools in this category face instant commoditization.
There's also a deeper structural risk. The failure modes that justify this product's existence exist because current LLMs produce them. GPT-5-class models are actively working on reducing hallucinations and boundary errors. If the failure signatures become rare over the next 18-24 months, the TAM shrinks regardless of whether a competitor enters.
The counterargument is speed. You don't need to win forever — you need to accumulate enough proprietary failure signature data fast enough that you either become the standard or become an acquisition target. 500 active teams in 12 months is the number that matters. Every PR analyzed trains a classifier that new entrants can't easily replicate.
I think this works as a business if you treat GitHub as the acquirer you're building toward, not the competitor you're running from.
Strip away the verticals and you see the same pattern in all three.
Legacy workflows — HR comp audits, vendor due diligence, code review — have become visibly insufficient under new pressures. Pay transparency laws, geopolitical hardware bans, AI code generation at scale. The pressures arrived faster than the tooling did.
And in each case, the thing people actually want isn't just the analysis. It's the artifact. The PDF. The risk score with citations. The remediation report they can show someone. A comp director needs political cover. An MSP needs a client-ready deliverable. An engineering lead needs a defensible record that they flagged the risk before the merge.
If you're building something that produces a trustworthy, shareable artifact from messy inputs, you're closer to product-market fit than most SaaS tools. That's the real pattern here.
All three of these are worth watching. None of them are sure things.