Why is it so hard to buy things that work well? (2022)

Article reception & readability

• Many found the essay interesting but overlong, rambling, and light on actionable conclusions; others thought it was absolutely worth reading and consistently insightful.
• Common complaint: the page is an unstyled, full‑width wall of text with giant paragraphs, making it “designed to be unreadable,” especially on large monitors.
• Defenders argue the bare HTML is intentional: fast, accessible, easy for reader modes and tools; critics say minimalism shouldn’t mean zero typography and that a single max-width line of CSS would greatly help.
• There’s extended debate over writing style: some see it as unedited and dense; others see it as highly deliberate, prioritizing nuance and many examples over “clean” essays or short takes.

Why things (and software) don’t work well

• Commenters link the article’s examples to broader “enshittification”: marketing and sales optimized over actual quality; trust and honesty not enforced culturally; products that only have to be “just good enough” to keep selling.
• They highlight information asymmetry: buyers often lack expertise (accountants, dentists, JS libraries, SaaS, appliances), can’t reliably evaluate quality, and face corrupted signals (fake reviews, SEO, affiliate content).
• Several connect this to the “market for lemons” and the Vimes “Boots” theory: poor people or time‑pressed buyers end up repeatedly buying cheap, mediocre goods.

Markets, incentives & organizational culture

• Many push back on simplistic “efficient markets” stories: real markets tolerate large inefficiencies, especially under monopolies/oligopolies, high switching costs, and bad information.
• Econ‑101 models are criticized as a kind of “secular religion” that ignores transaction costs, power, and incomplete information.
• Anti‑trust and concentration (Big Tech, app stores, cloud) are repeatedly blamed for declining product quality and lack of incentive to improve.
• Inside firms, webs of mistrust and politics are likened to Prisoner’s Dilemmas/Nash equilibria: without leadership that enforces honesty, fiefdoms optimize for self‑protection, not quality.

Build vs buy, software ecosystems, and JS

• The discussion reinforces the article’s build‑vs‑buy theme. Many describe buying SaaS/low‑code tools that look great on paper but are fragile, misleadingly marketed, and hard to integrate.
• Others note that in huge, noisy ecosystems (especially JavaScript/npm), popularity metrics (stars, downloads) are poor quality indicators; winners are often chosen by marketing, hype, and “being top of mind,” not engineering quality.
• Some engineers respond by re‑implementing things themselves, building small internal libraries, or vertically integrating, accepting higher upfront cost for long‑term control and reliability.

Buyer coping strategies

• Suggested heuristics:
  • Read 1‑star reviews to detect systemic issues.
  • Judge libraries by docs, issue churn, and maintainer history rather than stars.
  • Buy older, proven models or used gear (cars, tools, appliances, audio) that have “passed the test of time.”
  • Buy less overall, or buy cheap first and upgrade only if you actually wear something out.
• Many note this still often fails: brands quietly cost‑cut, models change quickly, and even expensive products (cars, mice, laptops, B2B software) can be deeply compromised.

AI and “will this fix it?”

• One commenter asks if AI can solve the selection problem by assessing who/what is “good.”
• Most replies are skeptical or negative: AI is seen as likely to widen understanding gaps, accelerate disposable products, and become yet another overhyped “panacea” narrative (like blockchain before it), rather than structurally improve quality.