IdeaWell

Project ideas from Hacker News discussions.

I paid people to try and follow my README

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Theme 1: Emoji overuse is distracting and unprofessional
- commandersaki: "I hate READMEs with a gazillion emojis, too much noise."
- layer8: "these make me back out of a project immediately if I don’t have a strong need to use it, and it takes extra cognitive effort to ignore the emojis and focus on the actually meaningful text."
- chanux: "Cannot agree more. Looks kinda childish too."

Theme 2: Clear assumptions and prerequisites are essential
- BoppreH: "My rule of thumb for my READMEs: there should be a list of commands, that when executed in order and in a clean machine, result in the software doing something useful. Yes, this includes git clone."
- layer8: "Installation instructions usually (should) have a 'prerequisites' section. You don’t have to explain how to install the prerequisites, but they should be listed."
- Telaneo: "If Windows/MacOS doesn't ship git by default, then yes, that should be included. On Linux, the people who are running Linux From Scratch can probably infer what the problem is."

Theme 3: Real‑user testing (usability testing, friction logs) uncovers hidden problems
- nkrisc: "This sounds exactly like UX usability testing. Sit down with someone and watch them work through whatever process you’ve created. It’s normal to compensate them for their time."
- bryanhogan: "Yes, this is right! It's closest to usability testing in UX design."
- bambax: "I think I read somewhere (and in any case it matches my experience) that the first user will catch 50% of the problems and that with 5 users you can catch close to 90%. So human testing is not just invaluable, it's pretty cheap for the benefits it brings."
- aleda145: "I've done this for internal dev tools! It's amazing how many assumptions you have about everything. I've great success with friction logs: [link]"

🚀 Project Ideas

Generating project ideas…

EmojiScore

Summary

  • A CLI tool that scans README.md files for excessive emojis, noise, and missing essential sections (like project purpose or prerequisites) and outputs a score with actionable suggestions.
  • Core value proposition: Helps maintainers quickly identify and clean up distracting emoji overuse and vague documentation, improving first‑impression clarity for potential users.

Details

Key Value
Target Audience Open‑source maintainers and developers who want cleaner, more professional READMEs
Core Feature Emoji density detection, section‑presence checker (what it does, prerequisites, usage), and automated rewrite suggestions
Tech Stack Python (typer/click), regex, optional spaCy for language hints, packaging via PyPI
Difficulty Low
Monetization Hobby

Notes

  • HN users complained: “I hate READMEs with a gazillion emojis, too much noise.” and “These make me back out of a project immediately if I don’t have a strong need to use it.”
  • Integrates into CI pipelines; low barrier to adopt and can spark discussion about documentation quality standards.

ReadmeFriction

Summary

  • A service that runs README instructions in isolated containers (or VMs) to verify they work end‑to‑end, logs any friction points, and optionally pairs the run with a human tester who records notes for a small fee.
  • Core value proposition: Automates the tedious “follow the README and see if it works” step, giving maintainers objective feedback on setup clarity and missing assumptions.

Details

Key Value
Target Audience Project owners, devrel teams, and anyone distributing software via GitHub/GitLab
Core Feature Automated execution of README steps (git clone, build, run) in Docker, capturing errors, timing, and optional human‑tester video/notes
Tech Stack Docker or Podman for isolation, Go or Rust agent for orchestration, web UI (React + Node) for results, optional marketplace for testers
Difficulty Medium
Monetization Revenue-ready: $5 per automated run, $20 per human‑tested friction log

Notes-

  • Commenters praised friction logs: “I've done this for internal dev tools! It's amazing how many assumptions you have…” and “Paying people to record themselves using your software… might actually be very informative.”
  • Provides concrete data to improve READMEs, directly addressing the pain of missing prerequisites and unclear steps.

DocuScaffold

Summary

  • A generator (CLI/web) that scaffolds a Diataxis‑compliant README template with prompts for project purpose, prerequisites, tutorial, how‑to, reference, and example sections.
  • Core value proposition: Reduces the cognitive load of writing good documentation by providing a proven structure and placeholders, encouraging concise, useful docs from the start.

Details

Key Value
Target Audience Developers starting new projects or refactoring existing documentation
Core Feature Interactive questionnaire that outputs a ready‑to‑edit README.md following the Diataxis framework (tutorial, how‑to, reference, explanation)
Tech Stack JavaScript/TypeScript (Node.js) with Inquirer.js, templating via Handlebars, distributed via npm
Difficulty Low
Monetization Hobby

Notes

  • HN discussion highlighted the diataxis framework: “I tried to follow the organization outlined in https://diataxis.fr/” and “Being short and concise is usually the better way.”
  • Encourages adoption of better documentation practices, likely to be welcomed by commenters who value clear, structured READMEs.

Read Later