Why the best startup opportunities right now look boring until you look closer.
There's a pattern I keep seeing in markets that haven't been properly picked over yet. The idea sounds obvious in hindsight. The pain is real and documented. Nobody's building the obvious thing. And when you ask why, the answer is usually some version of: "the incumbents should have done this already."
That's actually the tell. When a problem is so clearly someone else's job that builders assume it's handled, you get a gap. Not a gap because the market is small. A gap because everyone looked at it and kept walking.
Three ideas I've been thinking about lately all share this structure. They're not adjacent to hot trends. They're not riding some new API that just launched. They're sitting in large, unglamorous markets where the status quo is genuinely broken and the people suffering from it have normalized the pain.
The clearest version of this is the Perishable Order Audit & Auto-Claim for Retailers. Grocery stores on DoorDash and Instacart lose real money every time a delivery order gets canceled after the staff has already picked the items. The perishables are often unsellable. The labor is gone. And the claims process to get compensated is a manual, opaque mess that involves emailing PDFs and hoping.
This isn't a tiny problem. There are roughly 8,000 regional grocery chains in the US with 5 to 20 locations using third-party delivery. If you run the numbers even conservatively, you're looking at a $29M market at 1% penetration, and that's before you account for what a real claims success rate improvement does to renewal rates.
So why hasn't anyone built this? My read: delivery platforms benefit from claim rejection. It's a revenue line. Grocery ops managers are drowning in operational fires and don't have the engineering relationships to demand better tooling. And the VCs who fund most dev tools aren't exactly hanging out at FMI conferences.
The problem looks like it belongs to DoorDash to solve. It doesn't. DoorDash has every incentive not to solve it well.
The Adversarial Test Generator for LLM-Authored Code is a different flavor of the same thing. AI-generated code is everywhere now. Teams are shipping faster than ever. The tests pass. Then production breaks three weeks later because the LLM hallucinated an edge case that nobody thought to test for.
This is documented. There's a Reddit thread in r/webdev with 255 upvotes about an Amazon outage caused by an AI coding bot. The comments are full of engineers who recognize the failure mode. The problem looks like it belongs to GitHub Copilot or CodiumAI to solve. They're shipping test generation, sure, but nothing adversarial. Nothing that's specifically trying to break AI-generated code the way AI-generated code actually fails, which is different from how humans write bugs.
The third idea, the Architectural Linter & Policy Engine, follows the same logic. AI coding assistants write code that works at the file level and breaks at the repo level. Wrong dependencies. Layer violations. Packages that should never talk to each other, now talking. ArchUnit exists for Java. Dependency Cruiser exists for TypeScript. Nothing works across languages, and nothing is specifically aware of AI provenance.
Polyglot teams using Cursor and Copilot are accumulating tech debt in a form that current tooling can't see. The problem looks like it belongs to SonarQube or JetBrains. It doesn't, at least not yet.
I want to be honest about what I don't know here. All three of these ideas have real risks. The claims tool could get kneecapped if DoorDash decides to spend one PM sprint on a better dispute flow. The adversarial test generator is genuinely threatened by platform bundling from GitHub within 18 months. The architecture linter faces a sales motion problem where the person who wants it (the architect) isn't the person who controls the budget (the engineering manager).
These aren't invented risks. They're the actual structural vulnerabilities.
But here's what I keep coming back to: the incumbents have had years to fix these problems and haven't. DoorDash launched Fulfillment Visibility tools in 2023 and the claim process is still opaque. GitHub has had test generation since Copilot launched and adversarial testing is still not a thing. SonarQube has been around for fifteen years and cross-language architectural policy enforcement is still a manual process involving architecture documentation that nobody reads.
At some point, "they could build this" becomes a weaker argument than "they haven't."
The other thing these ideas share is that the wedge is small enough to actually ship. You can validate the perishable claims tool with a Typeform, a Zapier, and a Google Doc. Seriously. Ten grocery ops managers, free claim packets, see if they come back. The adversarial test generator can be manually operated, just a founder running GPT-4 and Semgrep against a PR and delivering a report, long before any CI integration exists. The architecture linter has a CLI path that a solo developer can build in six to eight weeks.
The market being large doesn't mean you have to eat it all on day one. It means you have room to be wrong about the exact entry point and still find something real.
The obvious thing to say here is "look for overlooked markets." That's not helpful. Everyone says that.
The more specific thing is: look for pain that lives at a boring interface. The grocery store's relationship with DoorDash is boring. The PR review process is boring. The architecture documentation meeting is boring. Boring interfaces attract less builder attention than they deserve relative to how much economic activity runs through them.
Also look for situations where the platform has a conflict of interest. DoorDash benefits from claim rejection. GitHub benefits from keeping test generation native and basic. IDE makers benefit from keeping code quality inside the IDE. When the obvious owner of a problem profits from the problem continuing, a third party has a window.
That window isn't permanent. It never is. But "they'll probably build this eventually" is not the same as "they'll build it before you can get to 100 paying customers and real switching costs." The race is always closer than it looks in both directions.
I don't think any of these three ideas is a guaranteed winner. Honestly, the architecture linter worries me the most, because the configuration onboarding problem is real and the buyer/champion mismatch is a known startup killer in developer tools. The claims tool worries me for different reasons, mostly that grocery procurement is brutal and the math on ROI per location is thin.
But the pattern they share is worth paying attention to regardless of which specific ideas you pursue. Large markets, unglamorous pain, platform incumbents with wrong incentives, and a wedge small enough to ship in a few weeks. That combination shows up more than people expect, and it shows up most often in industries where the dominant players are marketplaces or platforms that make money on friction they'd rather keep.