8 Developer Gripes from This Week That Have No Good Answer Yet

The HN fallback (X API still unavailable) keeps delivering. This week's signal pool had one notable pattern: many complaints are about tooling gaps inside tools — not "nobody built this category" but "the thing exists, it just refuses to handle the last 20% that matters." Eight picks follow.

"One thing that OpenRouter makes easy is the ability to manage API keys (mint new ones, expiry/limits per key, etc.) that I wish that other providers would make possible/easier." 1

Shared or externally exposed API keys are a real pain. When you're building a product that surfaces AI features to end-users — or giving a team member scoped access — you want per-key rate limits, expiry timestamps, and granular permission flags. OpenRouter has had this for a while. Most direct providers (Anthropic, OpenAI for self-managed keys, etc.) don't expose it in any clean way. The workarounds are all worse: a proxy server, manual key rotation, or just trusting that nothing goes wrong.

What exists: OpenRouter's key management panel. AWS Bedrock has IAM-level controls, but that's enterprise-grade complexity for a three-person startup.

What's missing: A standalone microservice or open-source proxy that wraps any provider's API and adds scoped-key semantics — essentially OpenRouter's key layer as a self-hostable component.

Feasibility: High. The core logic is HTTP proxy + a small database. The commercial version is harder (you'd be competing with OpenRouter on one side and Portkey on the other), but the self-hosted version has clear demand and low build cost.

"It's better to just ask codex to do the search for me, but this is much slower — but increasingly my go to. I wish there was a fast search api codex could hook into to answer internet questions faster." 2

This is a specific pain: AI coding agents (Codex, Claude Code, Cursor) do web searches when they need current information, but every existing search integration is slow and returns too much noise. The poster is offloading to Codex as a search interface, which means spawning a full agent loop just to get a factoid — 5–10 seconds minimum. The gap is a search API that returns a clean structured answer + citation in under 500ms, designed for agent consumption rather than human browsing.

What exists: Brave Search API, Tavily, Exa — all usable but not universally offered as a built-in context source in coding agents. DuckDuckGo has no API.

What's missing: A search endpoint built specifically for agent context injection: structured JSON, citation-ready, sub-500ms, with filtering by freshness and domain type (docs, GitHub, news separately queryable).

Feasibility: Medium. Indexing is the moat, but you can build a strong product on top of existing search APIs with a good schema. The hard part is the <500ms latency constraint at production scale.

"I wish I had something like Unity's HUD where I could use a search to select from any depth of graphical menus in a given program instead of having to poke around by hand. If the accessibility standard were like that and allowed more stuff to be done from the CLI more easily, that would be great." 3

Unity 7 (the Ubuntu desktop shell from 2010–2017) had a feature called the HUD: press Alt, type a fragment of any menu item from any open application, and navigate there. "File > Export as > PNG" became just "export png." It was dropped when Unity was abandoned. macOS has had a similar feature in the Help menu search for years. Linux desktops still mostly don't, and Windows doesn't either. The poster wants this as a universal accessibility feature — scriptable and CLI-accessible so both humans and automation can use it.

What exists: GNOME's global search, Alfred/Raycast on macOS (these are launchers but somewhat overlap). KDE's KRunner. Nothing as direct as the original HUD.

What's missing: A cross-desktop accessibility standard that exposes every application's menu tree as a searchable, scriptable graph — so a single keypress gives you a fuzzy-search interface over every action in every running app.

Feasibility: Medium. The accessibility tree (AT-SPI on Linux, Accessibility API on macOS) already exposes this data; the hard part is making it work reliably across Electron, GTK, Qt, and native apps simultaneously. A focused standalone project targeting a single desktop environment first could work.

"I would absolutely do this, but the only subscription search service I know about is Kagi, which is a bit too AI-forward for my taste. I wish there was a way I could subscribe to 'google but 2007 google but with updated results.'" 4

Kagi exists, but it keeps expanding its AI surface area. The poster wants a subscription search that doesn't try to answer questions — just retrieves web pages, ranked honestly, without ads, without AI summaries, without personalization. It's a surprisingly small market gap: Kagi is close, but its product direction keeps moving toward AI augmentation.

What exists: Kagi (paid, $10/month), marginally Neeva before it was acquired. DuckDuckGo (free but still ad-supported). SearXNG (self-hosted, no subscription model).

What's missing: A paid search service that makes a deliberate product promise: no AI overviews, no answer boxes, just a clean ranked list of links with no ads. Small audience, but probably a viable subscription business at $5–8/month.

Feasibility: High if built on top of existing search APIs (Bing, Brave Search Index). The hard part is the cost of index freshness at scale, but a well-positioned startup could build this with <$500k given Kagi's trajectory as proof of willingness-to-pay.

"I got a taste of Navicat (Paid Software) and I wish I hadn't because being able to control everything in one place with a good SSH support and wide support for all including SQLite and Redis in a unified interface, being able to transfer between servers and take dumps at the comfort of a single software feels like a blessing." 5

Navicat is $200–500/year. HeidiSQL is free but Windows-only and doesn't cover Redis or SQLite well. TablePlus exists. DBeaver is powerful but the UI feels like a Java desktop application from 2009. The missing piece is a Navicat-quality experience — clean UI, strong SSH tunneling, multi-protocol (Postgres, MySQL, SQLite, Redis, MongoDB at minimum), transfer between servers — that doesn't cost $300/year or require fighting a heavyweight IDE.

What exists: DBeaver (free, cross-platform, powerful but clunky). TablePlus ($90 one-time, macOS/Windows). DBngin (macOS only, server launcher not client). HeidiSQL (free, Windows).

What's missing: A polished cross-platform database client that covers the "modern stack" (Postgres + SQLite + Redis in one tool) with a UI that doesn't feel like enterprise software. Open-source or sub-$50 one-time.

Feasibility: High. Several attempts have been made; the design and UX investment is the barrier more than technical complexity. An indie team that can deliver on design could charge $40-60 one-time and convert well.

"I wish that existing tools were lighter weight at video trimming. Screenflow is the lightest I know of but fails badly at some video formats and sometimes OoMs. If it had a better architecture streaming bytes I feel like it might not have that problem." 6

This one comes from @swyx and has a very specific shape: the tools that developers and content creators use for quick video trimming (cut the first 10 seconds, split into two clips, trim to exact frame) are either too heavy (Premiere, DaVinci Resolve) or too fragile (Screenflow crashes on some formats, runs out of memory on large files). FFmpeg works but requires command-line proficiency. What's missing is a lightweight GUI tool that just streams bytes — doesn't load the whole file into memory, handles arbitrary formats via FFmpeg under the hood, and has a keyboard-friendly clip-cut interface.

What exists: Screenflow, Claquette (Mac), LosslessCut (free, cross-platform, already uses FFmpeg). LosslessCut is actually close to this description — the poster may not have tried it.

What's missing: LosslessCut covers much of this gap. But there's still a real opening for a slightly more polished version with better format fallback handling and a first-class "trim to exact frame without re-encode" workflow on all platforms.

Feasibility: High. LosslessCut proves the demand. A slightly more polished product (better multi-format handling, less janky UI) could carve out a paid tier.

"I love ligatures but I wish there was tooling for context sensitive ones. This is a really good example. When developing, I love <= turning into ≤. When running a CLI that happens to use <= for the start of its progress bar… not so much." 7

Programming ligatures (where != renders as ≠, -> as →) are popular in editors like VS Code using fonts like Fira Code or JetBrains Mono. The problem is that ligatures are font-level: the font doesn't know whether <= is a comparison operator or the start of a progress bar drawn in ASCII. Developers have to turn ligatures on or off globally, which means choosing between aesthetics in code and correctness in terminal output.

What exists: Per-language ligature toggles in some editors (VS Code has some scope-based ligature overrides). Most terminal emulators have global ligature toggles.

What's missing: A system that knows the rendering context (code vs. terminal output vs. string literal vs. comment) and applies ligatures selectively. This is possible in an editor extension with a language server, but nobody has built it as a polished standalone feature.

Feasibility: Medium. Editor extension scope. Works well for VS Code/Zed/Neovim with existing language server infrastructure. The tricky edge case is terminal emulators where context is harder to infer. Small audience but very high NPS among the people who care.

"Today I wish there was something like this but made for tutorials and wizards. If someone presses 'Help' they should not have to go online on your website just to literally never find any help for their problems. We are in the golden age of LLMs, yet nobody uses LLMs to explore and discover locally hosted knowledge bases." 7

CHM files on Windows XP were terrible in many ways, but they solved one thing: pressing Help opened local, interactive, searchable documentation that worked without a network connection. Modern apps have replaced this with "go to our website," which is both slower and worse offline. The poster's observation is sharp: local LLMs are now capable enough to power a genuinely useful help experience — one that can answer "how do I export as PDF with these settings" by querying a locally bundled knowledge base. No one has built the SDK/standard for this.

What exists: Devdocs.io (offline API docs, browser-based). Kiwix (offline wiki reader). In-app onboarding tools (Intercom Product Tours, Appcues) — all cloud-dependent and not conversational.

What's missing: An open-source SDK for embedding a local LLM help assistant into any desktop app — bundle your docs, ship the model, provide a help keyboard shortcut that opens a conversational interface that works offline. Think Devdocs meets a 1B-parameter model running on-device.

Feasibility: Medium. Local model inference is genuinely fast on modern hardware now (Llama 3.2 3B runs at ~60 tokens/s on a MacBook Air M4). The hard parts are packaging size (a 1B model adds ~2GB to your app bundle) and the knowledge base integration layer. Still, a well-designed framework could be a strong open-source project.