Users don't care about your tech stack

Original Article ↗ Hacker News Discussion ↗

What “Users Don’t Care About Your Stack” Really Means

  • Broad agreement: end‑users rarely know or care about language/framework names.
  • Strong pushback: they absolutely care about effects of those choices—latency, reliability, battery life, ability to ship features, stability over years.
  • Many see the slogan misused as a motte‑and‑bailey: rhetorically true (“users don’t read about:tech”) but then stretched to justify bloated apps and cutting engineering corners.

Performance, Latency, and Bloat

  • Big debate around “they won’t notice 10 ms”:
    • One side: at scale, or per‑keystroke, tiny delays and microseconds do matter; users feel sluggishness even if they can’t articulate it; research and A/Bs (e‑commerce, UI studies) support that.
    • Other side: for most CRUD/business apps, a few hundred ms or seconds of startup are negligible versus development speed and feature delivery.
  • Heavy criticism of Electron apps, oversized web UIs, slow ecommerce sites, and multi‑second GC pauses; others argue disk/RAM are cheap, idle memory is harmless, and binary size rarely matters until it’s huge.
  • Consensus nuance: “performance is a feature,” but optimizations must be driven by measurement, not guesswork; premature performance work is often wasted.

Tech Stack Choice as Strategy

  • Multiple commenters stress stack is a business decision:
    • Hiring availability, long‑term maintainability, ecosystem maturity, and avoiding rewrites matter as much as raw speed.
    • Complex polyglot stacks can hurt iteration and onboarding, though there are successful counterexamples with mixed stacks.
  • Some criticize advice like “use what you enjoy” for non‑personal projects; better framing: “use what your team knows and what fits the problem and future roadmap.”

Developer Experience vs User Experience

  • Many note tech debates among devs are mostly about developer ergonomics, not hypothetical user concerns.
  • Still, internal code quality and architecture feed back into user value: tech debt and poor architecture can calcify a product and slow feature delivery.
  • Several emphasize pride in craft: even if users don’t see the stack, engineers should care about good tools, clean design, and avoiding needless waste.

LLMs and Future Abstractions

  • Some speculate LLMs will make natural‑language specs and rapid stack switching routine.
  • Others doubt this soon: LLMs aren’t reliable compilers, specs alone aren’t version‑stable, and nontrivial migrations (e.g., databases) are still hard.