Craft software that makes people feel something

📝 Discussion Summary (Click to expand)

The three most prevalent themes in the Hacker News discussion are:

Software Should Be Crafted for Personal Enjoyment and Delight: Many users expressed a strong preference for building or using software that prioritizes the creator's personal satisfaction, fun, or utility, rather than immediately aiming for open-sourcing, monetization (SaaS), or mainstream acceptance.
- Supporting Quote: "There’s something refreshing about explicitly saying “this editor exists to delight me, and that’s enough”" (pedrozieg).
- Supporting Quote: "Craft software that makes people feel something" (godelski, quoting OP title sentiment).
Software Often Elicits Negative Emotional Responses (Rage/Dread): A significant number of comments noted that the software they interact with daily, especially corporate or large-scale applications, frequently provokes negative feelings rather than positive ones.
- Supporting Quote: "I make software that makes people feel something - rage - there are two types of software one that no one cares about and software that people use and voice their opinions about :)" (ozim).
- Supporting Quote: "There's definitely software that wants to make people feel dread. Mostly horror games and Atlassian applications." (mcphage).
Tension Between Hobbyist Freedom and Collaboration/Open Source Pressure: There is a clear conflict regarding the expectation that side projects should be open-sourced, with many users wishing they could maintain full control (no contributions, issues, or PRs) if they choose to share their code on platforms like GitHub.
- Supporting Quote: "Unfortunately, and I think to great overall harm, GitHub does not let you disable many of the collaboration features." (mirashii).
- Supporting Quote: "I have a hobby game up on GitHub. The README explains that it's open source for people to fork it and file issues, but that I don't accept contributions." (munificent).

🚀 Project Ideas

Cognitive Load Sandbox (CLS) — AI-Assisted Idea Execution Validator

A tool that acts as an "infinite patience developer friend" to help users rapidly iterate on complex, non-boilerplate architectural ideas, addressing the feeling that AI execution often preempts the fun/discovery part of coding.

🔍 What it does

Conceptualization Chatbot: Allows deeply technical co-design discussions, similar to tacone’s positive experience with AI buddies for idea generation.
Intent Mapping: Automatically translates high-level architectural decisions (e.g., "I want a Rust interpreter for this specific AST structure") into a prioritized backlog of concrete, executable engineering tasks.
Execution Sandboxing (The 'Boring Part' Separator): Generates boilerplate scaffolding, setup code, or standard library hooks for the agreed-upon task, leaving the core, novel logic for the human user to hand-craft, addressing matheusmoreira's concern that AI execution makes things "feel done" before the inspiring, hard execution starts.

Why HN commenters would love it

Maximizing Inspiration: Directly supports the goal of using AI for stimulating conversation (matheusmoreira: "shooting ideas and concepts back and forth... is quite stimulating") without letting the AI remove the satisfying "actually executing" phase of novel engineering.
Niche Problem Focus: Helps users focus on the "breadth" or "wow-factor" parts (Minor49er's example of yt-dlp) by automating away the setup/boring infrastructure which is often repetitive.
Tool for Personal Environments: Fits the ethos of building "your own little lands" (jesse__), where the setup overhead is minimized, allowing the developer to stay immersed in the specific, fun technical challenges of their personal environment.

Example output

User Input: "I want to prototype a simple stack-based language runtime where variables are scoped via lexical closures, similar to Scheme but implemented manually in C." CLS Output: (Generates main.c, boilerplate for memory allocation/garbage collection hook, and a stub execute_instruction function with template structures for AST nodes, ready for the user to implement the actual closure logic and opcode handlers.)

Empathy/Dread Feedback Analyzer — Corporate Software Sentiment Monitor

A light service that ingests user feedback/complaints about established, widely used enterprise or consumer software (like Microsoft Teams, Atlassian products, or DRM tools) and distills the core, actionable friction points that cause "rage" or "dread."

🔍 What it does

Sentiment Analysis: Analyzes large public datasets (e.g., social media, specific subreddits, or specialized issue trackers) for software known to evoke strong negative feelings (e.g., nchmy's JIRA, elcritch's Teams complaints).
Friction Mapping: Extracts specific, reproducible user interaction failures or unintuitive design choices (e.g., the Teams Ctrl+Shift+C shortcut issue mentioned by mcny).
"Craft Value" Report: Presents the findings as a report focused on where the product misses the mark on providing delight or solving a "job to be done" effectively, providing data for developers who prefer to build things that feel good or are highly useful (jamesgill, barrenko).

Why HN commenters would love it

Quantifying "Feeling": It takes the abstract user feelings of "rage" and "dread" (deadbabe, ozim) and tries to ground them in specific, technical implementation errors that skilled programmers can recognize and potentially fix in their own projects.
Focus on Utility over 'Wow': It caters to the desire to solve real problems (jamesgill: "help them with their jobs to be done"), by showing precisely where current market leaders fail on that utility metric due to ignoring craftsmanship.
Niche Counterpoint: It provides a resource for those dissatisfied with the state of commercial software, reinforcing the value of small, delightful tools built by individuals who care about quality control (brailsafe's nostalgia for native editors).

Example output

GitHub Repository Lockdown Manager — Fine-Grained Contribution Control Tool

A service that provides fine-grained, declarative control over contribution mechanisms (Issues, PRs, Discussions) for GitHub repositories beyond GitHub's native settings, specifically addressing the desire for "share source code but ignore unwanted interaction."

🔍 What it does

Declarative Configuration: Allow users to define contribution rules via a .lockdown.yml file in their repository.
Automated Enforcement: A GitHub Action continuously monitors the repository and programmatically locks, ignores, or auto-closes issues/PRs based on the user-defined rules (e.g., automatically closing issues from non-sponsors, or disabling PRs entirely).
Sponsorship Gating: Implement optional tiers where Issues/PRs are only visible or assignable to users who are linked sponsors via GitHub Sponsors.

Why HN commenters would love it

Directly Solves Constraint Frustration: Addresses mirashii and matheusmoreira's pain point regarding GitHub not allowing users to fully disable collaboration features when they only want to "open source their code" without interaction or support burden.
Empowers Personal Playgrounds: Appeals to the desire expressed by pedrozieg and jesse__ to maintain a private playground environment, even while the source is public, balancing openness with personal motivation ("just making it for me").
Tooling Delight: HN users appreciate automation and configuration-as-code. This provides a necessary governance layer that GitHub currently refuses to offer, aligning with community desire for better control over their repos (like Lammy's current Action solution, but centralized and more robust).

Example output

User config (.lockdown.yml):

issues:
  enabled: true
  filter: sponsors_only
pull_requests:
  enabled: false
discussions:
  enabled: true
  filter: none

Result: A repository where source code is public, new PRs are immediately blocked/closed, but Issues are only viewable and actionable by users actively sponsoring the developer.