IdeaWell

Project ideas from Hacker News discussions.

The most important product decision is what you don't build

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

1. Question the need for custom reporting / avoid featuritis
Many commenters note that requests for “custom reporting” often stem from unclear requirements or inadequate built‑in tools, and that probing the real question can lead to simpler, more valuable solutions.

  • “The one I get constantly is we want 'custom reporting'. Well what the hell is that really? Why, why, why do you need that? Then I just build a new feature they will actually use and defer 'custom reporting' for another month.” — swader999
  • “I see this all the time… custom reporting, reports… Most of the time they have little clue of what they want reported, or how they want the data to look like.” — pelagicAustral
  • “Sometimes 'reporting' / 'monitoring' is how someone does an end‑run around normal product and engineering, and we skip adding what ought to be a feature or domain concept.” — Terr_

2. Prioritize high‑impact work and cut low‑value features
A strong emphasis is placed on focusing effort on what truly moves the needle, aggressively trimming scope, and avoiding wasted sprints on nice‑to‑have ideas.

  • “Or as I like to say ‘the best way to launch is to cut features’. As an engineering leader you’ve got to advocate for it against product/design all the time.” — djtriptych
  • “Instead of 5 low impact features, build the one high impact one. Instead of a cheap notifications hub, fix the need for why you need one.” — jmathai
  • “Saved countless sprints by killing features that sounded cool but didn't solve core problems. Less code, less maintenance.” — Prydown

3. Keep constraints, maintenance, and user expectations in mind
Decisions should reflect realistic limitations, long‑term upkeep, and aligning with what users actually expect, rather than chasing every idea that seems feasible.

  • “I would say that 'what not to build' is the second most important decision. The most important decision is what limitations and constraints you are prepared to accept.” — jongjong
  • “I find myself often trapped (enticed?) by how fast and inexpensive it is to build software… what do I actually want to build and maintain?” — jimkleiber
  • “Part of the question may be how do you change the users expectations. If you are building a product the user already knows, that might not be difficult.” — pedalpete

🚀 Project Ideas

QueryBuilder Lite

Summary

  • A low‑code web UI that lets business users construct ad‑hoc queries over a company data mart without writing SQL.
  • Provides auto‑join suggestions, instant result preview, and one‑click export to CSV/Excel, turning vague “custom reporting” asks into self‑service answers.

Details

Key Value
Target Audience Product managers, analysts, and ops staff who need quick data pulls
Core Feature Drag‑and‑drop table/field selector with smart foreign‑key join inference, filter builders, aggregation options, and live result grid
Tech Stack React + TypeScript frontend, Node.js/Express backend, PostgreSQL (or any SQL DB) with SQL‑builder library (e.g., Knex), Docker for deployment
Difficulty Medium
Monetization Revenue-ready: SaaS subscription ($15 per active user/month)

Notes

  • HN commenters lamented that users often just want to “join all the tables … and dump everything on an Excel spreadsheet” (pelagicAustral, randochatter). QueryBuilder Lite gives them that power safely, reducing the need for ad‑hoc engineering work.
  • By exposing the underlying data model through a guided UI, product teams can see what fields are actually being requested, informing real feature ideas (as suggested by tytho and gedy).

InsightIntent

Summary

  • A lightweight widget that intercepts a “custom reporting” request and guides the requester through a short questionnaire to articulate the underlying business question.
  • Outputs a concise problem statement, suggests existing features or data points that may already answer it, and logs the interaction for product review.

Details

Key Value
Target Audience Support teams, product managers, and anyone fielding reporting requests from stakeholders
Core Feature Interactive form (via modal or embedded widget) that asks: “What decision do you need to make?”, “Which metric matters most?”, “Time period?”, then matches against a knowledge base of existing reports/features
Tech Stack Plain JavaScript widget (no framework) or Svelte for tiny bundle, backed by a Node/Express micro‑service storing FAQs and logging to Postgres; can be embedded via iframe or script tag
Difficulty Low
Monetization Hobby (open‑source MIT license; optional hosted version for enterprises)

Notes

  • Commenters repeatedly asked “What question are they wanting the answer to?” (tytho, mmonaghan). InsightIntent forces that clarification up front, turning vague requests into actionable feedback.
  • Product teams love the logging aspect: it creates a backlog of genuine user needs that can be prioritized instead of building one‑off reports (as noted by gedy and Pxtl).

DataLens API

Summary

  • A read‑only, versioned API that exposes canonical, well‑documented data models (entities, metrics, dimensions) from the core data warehouse.
  • Supports filtering, sorting, pagination, and basic aggregations (SUM, AVG, COUNT) via standard HTTP verbs, enabling analysts to build their own reports in any tool (Excel, Power BI, Looker) without custom engineering.

Details

Key Value
Target Audience Data‑savvy analysts, BI developers, and power users who need flexible access to trusted data
Core Feature REST/GraphQL endpoints with OpenAPI spec, role‑based access, automatic SQL generation from query parameters, caching layer, and SDKs for Python/JS
Tech Stack Go (or Rust) API server, PostgreSQL (or Snowflake/BigQuery) as source, Kong/Envoy for auth & rate limiting, Docker/K8s for deployment, Swagger UI for docs
Difficulty Medium
Monetization Revenue-ready: Usage‑based pricing ($0.001 per 1K rows returned) with free tier for low volume

Notes

  • Several HN users suggested “Give them an API with the data so they can get create their own reports” (pier25). DataLens API delivers exactly that, reducing the “custom reporting” burden on engineering.
  • By providing a stable, versioned contract, product teams can avoid ad‑hoc table joins and the “golden standard” of dumping everything to Excel (pelagicAustral), while still empowering users to answer their own questions.

Read Later