Do things that don't scale, and then don't scale

Personal Tools vs Startups

• Many commenters resonate with building tiny, purpose-built apps for themselves or a handful of users, likening them to “jigs” in carpentry: tools that help you do the real work faster.
• Distinction is drawn between:
  • Hobby projects that improve your own life and don’t need revenue or scale.
  • “Startups” explicitly designed for rapid growth and large markets.
• Some argue we should favor “companies” that become profitable quickly and may never scale large, rather than growth-at-all-costs startups.
• Others note there’s a middle ground (e.g. modest tech businesses that support a few salaries) and that most real-world businesses are micro or small.

Scaling, Consolidation, and Risk

• Multiple comments stress: don’t engineer for a million users until you’re close to that breaking point; premature scaling is wasteful.
• Discussion of niche but profitable businesses (including non-software ones) being targets for private equity rollups; debate over what moats really matter (customer relationship, land, brand, cost structure).
• Point raised that “zombie” businesses may underpay founders once risk and opportunity cost are factored in.

Hosting, Longevity, and Security

• If you want personal projects to last, run them on your own server with simple, “boring” tech.
• Open-sourcing and making self-hosting easy is suggested as a way for others to adopt these tools.
• Even tiny sites get hammered by automated attacks (botnets probing for known vulnerabilities); cheap for attackers because compute/bandwidth are stolen. Simple honeypots can help.

Social Networks: Small Vibes vs Context Collapse

• Strong agreement with the article’s claim that some communities work because they’re small; people recall early Facebook as “magical” before relatives and acquaintances arrived.
• Once networks include family, coworkers, and strangers, people self-censor; “context collapse” is cited as a core problem.
• Attempts to solve this (e.g. friend “circles”, follower limits, small shards, private forums, federated instances) are discussed; many liked the ideas, but friction and social dynamics limited adoption.
• The “dark forest problem” is used as a metaphor: people go quiet on big networks because they fear being judged by employers, family, or online mobs, leaving only performative, curated content.

AI/LLMs and the Cost of Building

• Some think the article over-credits AI: small, non-scaling apps have existed forever, and cloud APIs were the bigger enabler.
• Others argue LLMs fundamentally change the cost-benefit curve:
  • Remove “blank page” paralysis and glue-code tedium.
  • Let even modestly skilled developers spin up custom webapps, maps, agents, etc. in hours.
• Concerns are raised about:
  • Environmental, privacy, and trust costs of large AI providers.
  • Quality and maintainability of “vibe-coded” AI output (“instant legacy code”, “mass-produced software”).
  • Juniors relying on AI without the experience to recognize bad patterns.
• Local models and open weights are mentioned as a partial answer, but hardware demands remain significant for near–frontier quality.

Philosophies of Ambition

• One camp embraces “move slow and fix things”: keep products small, focused, profitable, and pleasant to run, even at the cost of growth.
• Another explicitly wants moonshots and “obscene wealth,” seeing hobby-scale projects as unsatisfying.
• Several note that the real win of this era may be psychological: people can now build more things “just for joy,” without needing every project to be a business.