Removing stuff is never obvious yet often better

Reaction to Removing the Pricing Calculator

• Many agree the core problem was users’ misunderstanding of metrics (QPS, vector counts), not the calculator UI itself. Small input errors could yield 10–1000× overestimates.
• Some argue removing the calculator plausibly improves signups but may simply hide sticker shock, pushing painful surprises to later bills.
• Others counter that incorrect self-estimates are worse than no estimate, and once users are onboarded they can see real usage-based billing and extrapolate more reliably.
• A few think the real fix should be a simpler pricing model, not deleting the tool.

Pricing Transparency and “Contact Us for Pricing”

• Strong dislike for “contact us for pricing” in B2B and especially consumer contexts; many say they will skip such vendors entirely.
• Concerns: price discrimination based on company size, sales “games,” sunk-cost pressure after lengthy sales calls, and difficulty piloting a tool when usage is initially unknown.
• Some defend non-public or negotiated pricing in narrow enterprise markets or bespoke solutions, but others insist there should at least be clear ballpark tiers.

A/B Testing, Metrics, and Dark Patterns

• Multiple comments criticize shallow A/B practices: optimizing for signups or clicks without tracking long-term outcomes (retention, complaints, churn).
• Removing information (like pricing details or snippet content) often increases short‑term engagement but may harm user trust or satisfaction.
• Some note this dynamic creates incentives for dark patterns and information asymmetry rather than genuine clarity.

Simplicity vs. Necessary Complexity

• Broad support for the “removal” mindset: YAGNI, “less is more,” and the idea that good design often comes from deleting features, not adding.
• Counterpoint: overzealous YAGNI can backfire; cheap, future‑useful structures removed early can be expensive to reintroduce later. The “right” deletion rate is debated.
• Several reference engineering cultures that deliberately encourage removing components, accepting that some must later be added back.

Organizational and Cultural Factors

• Long internal debates, polls, and Slack threads are seen as symptoms of over‑hiring, unclear ownership, and design‑by‑committee.
• Removing user‑visible features is politically hard; once something exists, some workflows inevitably depend on it, making deletion risky and unrewarded.