From Android push notification hell to actually useful AI tools developers might pay for.
If you've ever built an Android app for global users, you know the pain. FCM works fine until your users are on Huawei devices in China, or Xiaomi phones that decide push notifications are optional today. Developers report 20-40% of their notifications just vanishing into the void. You end up maintaining separate integrations for HMS Push, MiPush, and whatever proprietary system each OEM cooked up.
Unified Push Relay & Reliability Layer for Android (FCM + OEM) is basically a translation layer that sits between your server and every OEM's push system. One SDK, one API, and it figures out whether to route through FCM, HMS, or whatever else based on the device. It validates receipts, retries failures, and falls back to websockets when everything else breaks.
The opportunity is real but messy. The developers who need this most are building for markets where regulations change overnight. And maintaining compatibility with every OEM's shifting APIs is basically a full-time job. Still, with the right execution, you could own a very specific but painful problem before OneSignal notices.
Code review tools exist, but they're mostly pattern matching and linting with extra steps. The AI ones hallucinate half the time and miss obvious logic bugs the other half. What's missing is a tool that actually understands your codebase well enough to catch the subtle stuff - like when you're passing user input to a function that expects sanitized data three calls deep.
The idea is an AI reviewer that ingests your entire repo, learns your patterns and conventions, then reviews PRs with actual context. It knows that your auth middleware always expects certain headers, or that your database layer has specific transaction patterns. Instead of generic "consider error handling" comments, it catches actual bugs.
This could work because code review is a task developers actually want to automate, unlike writing code itself. The challenge is building something that's helpful without being annoying. Most AI tools err on the side of verbose feedback that developers ignore. The sweet spot is probably catching 2-3 real issues per review while staying quiet the rest of the time.
You write a query that looks innocent enough in development. It hits production with real data and brings your database to its knees. By the time you notice, users are timing out and you're frantically adding indexes while everything burns.
The tool would analyze your queries during development and predict performance issues before deployment. It simulates query execution against production-scale data distributions, catches missing indexes, identifies N+1 patterns, and warns about queries that will get exponentially slower as your tables grow.
This is interesting because it solves a very expensive problem - database performance issues cost real money in downtime and emergency fixes. The technical challenge is building accurate performance models without requiring a full production database copy. But if you could nail the prediction accuracy, developers would pay serious money to avoid 3am database fires.
Notion and Google Docs are fine for regular people, but try collaborating on technical documentation or project planning as a developer and you'll hit walls fast. No syntax highlighting, terrible code block handling, and everything breaks if your internet hiccups. Plus your company's internal docs shouldn't live on someone else's servers anyway.
A local-first collaborative editor built specifically for technical teams would store everything locally while syncing changes between teammates. Think Obsidian's local storage model but with real-time collaboration like Figma. Markdown-native, proper code highlighting, and it works offline.
The timing feels right because developers are getting tired of putting everything in the cloud. Local-first tools are having a moment, and teams want more control over their data. The challenge is nailing the collaboration UX without sacrificing the local-first benefits. But if you can make it feel as smooth as Google Docs while keeping everything on disk, that's a compelling value prop.
Your app breaks because a third-party API changed their response format. You find out when users start complaining, not when the change happened. API providers are terrible at communicating breaking changes, and when they do, the notice gets buried in some newsletter you don't read.
This tool would monitor every API your app depends on, detect schema changes in real-time, and alert you before anything breaks. It intercepts your API calls in development and staging, learns what fields you actually use, then watches for changes that would break your code.
The genius here is that it protects you from other people's mistakes. You can't control when Stripe adds a new required field or when some startup pivots and breaks their API. But you can know about it immediately instead of discovering it in production. For any company that depends on external APIs - which is everyone - this is cheap insurance against expensive downtime.
I like this one because the pain is universal and immediate. Every developer has been burned by unexpected API changes. The technical execution is straightforward but requires good product sense around noise vs signal. Get the alerting right and you've got something people will pay for without thinking twice.