SharePoint chaos, server-driven UI safety nets, and API auth testing for devs who hate security tools.
Something is happening in the tooling space right now that I keep noticing. The three ideas getting the most traction this week aren't trying to replace entire categories. They're all doing the same quieter thing: taking a real, specific pain that exists inside existing workflows, and building exactly enough infrastructure around it to make that pain stop. No platform plays. No grand visions. Just "this thing keeps breaking and nobody has fixed it."
Let's get into it.
If you've never worked inside a mid-size enterprise, you might not know how bad SharePoint actually gets. Permissions inherited from three mergers ago. Sites owned by people who left in 2019. External shares that went out for a vendor review and never got revoked. Admins who know it's a mess but have no way to visualize it, so they just... live with it.
The Enterprise Content Map & Permission Visualizer is a dashboard that crawls your Microsoft 365 tenant, draws out the permission hierarchy visually, surfaces orphaned content and stale owners, and lets you fix things in bulk. The signal that made this land on our radar: a Reddit thread in r/sharepoint with 522 upvotes where the top comments were admins describing their own specific disasters and asking what tools exist. Nobody had a good answer.
The market case is straightforward. Varonis charges $50K and up. Microsoft's own Purview tooling is genuinely bad at visualization. There are 180,000-ish mid-market companies sitting in the gap between "too small for enterprise security spend" and "too big to pretend this isn't a problem." A $199/month self-serve tool that connects via OAuth in 15 minutes and shows you what you've got should, in theory, convert.
Here's my honest read on it though: the Microsoft platform risk is real in a way that should give any builder pause. Microsoft has explicitly called M365 compliance and security tooling a core growth area. Purview already does data classification and access governance. Adding an interactive hierarchy view is not a hard engineering problem for a company with Microsoft's resources. It's a UI sprint. So the question isn't whether the pain is real (it clearly is), it's whether you can build enough of a moat before Microsoft closes the gap. The answer probably lives in vertical specialization. Healthcare. Legal. Finance. Places where HIPAA and SOX map directly onto permission structures and where a generic Microsoft update won't satisfy an auditor's specific evidence requirements. That's where switching costs get real.
The validation path here is unusually concrete. Post a Loom of a real (anonymized) tenant scan to r/sysadmin. DM admins who've complained in relevant threads. Offer a free audit using a manually-run Graph API script. If five people will pay $199 before a line of product code is written, you have something.
This one is more niche but the pain is sharp. Teams that ship UI from the backend (React Native and Flutter shops doing server-driven UI, or SDUI) have solved the delivery problem and created a new operational one. Product managers can push screen changes by updating a JSON manifest. Engineers own the on-call pager. Those two facts being true at the same time is a problem.
Current feature flag tools don't really help here. LaunchDarkly and its peers are built around boolean flags for code paths. They're not built for versioned UI manifests as atomic units. There's no diff view, no PM preview URL, no automatic rollback when a manifest change tanks engagement or causes crashes.
Runtime Feature Flags & Safe Rollouts for Server-Delivered Screens is a service that stores manifest versions, supports staged rollouts by audience segment, lets PMs preview any version via a shareable URL, and triggers automatic rollback when health signals drop. The elevator pitch is basically: engineers stop getting paged at 2am because a PM pushed a bad screen, and PMs stop feeling blocked waiting for engineering to review every change.
I want to be honest about the size problem here. The companies that have built SDUI in production and haven't already built internal tooling for this probably number in the hundreds globally, not thousands. That's a real ceiling. The $180M addressable market estimate in the idea data is plausible in the long run as SDUI adoption spreads, but the paying market right now is narrow. This is a bet on timing. The companies at the leading edge of SDUI adoption are too sophisticated to need this (they've built it internally). The companies that will need it in two years aren't there yet.
That said, the right go-to-market for this is clear. Design partners. Find the mobile engineering leads at fintech and gaming companies who are visibly working on SDUI architectures (GitHub repos with server-driven UI patterns are public). Offer free design-partner slots. Build with them, not for a hypothetical customer. The aha moment in this product is specific enough that you'll know quickly whether it resonates: a PM previews and approves a manifest change via a shareable URL and engineers see zero alerts. Either that unlocks something for teams or it doesn't.
The LaunchDarkly risk is worth taking seriously. They've mentioned JSON payload flags in their enterprise roadmap. They won't build a full SDUI system, but they don't need to. Adding manifest blob storage and a diff view is a sprint for a company with 400 engineers. The window to embed deeply into mobile CI/CD pipelines and build manifest version history that's annoying to migrate away from might be 12 months. Maybe 18.
This one I find the most interesting, partly because the insight driving it is so clear.
Developers don't want to become security engineers. They want their existing workflow to catch security bugs automatically. Every existing security tool ignores this. They ship the experience as a security tool, with security reports, security concepts, and security expertise requirements. The developers who most need them bounce immediately.
REST Authorization Auditor (AuthFuzz) is built on a different premise. Point it at your API with two JWT tokens (one per user role), and it fuzzes identifier fields, attempts cross-user access, and outputs failing CI tests, not security reports. The thing in your repo is a test. It lives in your CI pipeline. It goes red when there's an IDOR vulnerability and green when there isn't. You never have to think about it as a security tool.
The demand signal is strong. A r/webdev thread with 438 upvotes and 166 comments where developers confessed to shipping APIs that accepted arbitrary user IDs. The top complaints on G2 for every existing tool are "too complex" and "too many false positives." There's a real gap between what developers need and what's available.
The legal exposure is the thing I'd think hardest about before building this. Automated fuzzing that makes authenticated requests impersonating other users carries real risk under CFAA even when you're testing your own API, because CI environments running against staging sometimes share infrastructure with production. One incident where a developer accidentally ran this against production and leaked real PII would be catastrophic for a bootstrapped product. The mitigation (read-only mode, explicit ToS acknowledgment, mandatory staging warning, actual legal counsel) is manageable, but it's not optional. Budget $1,500 for a lawyer before you launch, not after.
The open-source free tier is both the right call and a risk. It's right because developers discover tools this way, because GitHub Actions Marketplace discovery is real, and because the fence around the paid tier (CI test export, PoC reports) is genuinely valuable enough that paying customers will pay. It's a risk because any developer with moderate Python skills will fork the CLI within weeks of launch. The moat has to be the generated test fixtures accumulating over time across customers, training better heuristics that the open-source fork can't replicate. That's a real data advantage. It just takes time to materialize.
Demo mode using Juice Shop or DVWA is the right onboarding default. First value hit in under two minutes, no configuration required. Then prompt: "now try your API." That's the activation flow.
None of these are category-creating bets. All three of them are taking existing infrastructure (Microsoft 365, mobile CI/CD, REST APIs) and adding a specific operational layer that the original platform never thought to build.
The pattern is: a mature platform creates a new class of problem that the platform doesn't solve, and the problem is specific enough that it falls through the cracks of general-purpose tooling. SharePoint doesn't visualize its own permission chaos. Feature flag tools don't treat manifests as atomic units. API scanners don't speak developer.
What makes all three worth watching is that the demand evidence is community-generated, not manufactured. Real admins describing their disasters. Real engineers worried about PM-pushed screen regressions. Real developers confessing they shipped APIs with broken auth. That kind of demand signal, unprompted, in public forums, is the thing you want to see before you build anything.
The risk across all three is the same: incumbents who notice. Microsoft, LaunchDarkly, Escape.tech. Each one has the resources to close the gap if any of these products show meaningful traction. The race is to build switching costs faster than the incumbents notice the category.