Every new social product I see is built with the latest shiny stack — server components, edge functions, novel databases. But looking at the products that actually scaled — WhatsApp (Erlang), Reddit (Python monolith), Discord (Elixir) — they all chose 'boring' technology that their teams knew deeply. Is there a lesson here?
Absolutely. Dan McKinley's 'Choose Boring Technology' essay is canonical here. The core argument: every technology choice has an 'innovation token' cost. You have a limited budget of complexity you can handle, so spend it on what makes your product unique, not on your infrastructure.
For social products specifically, the critical technical challenges are: message delivery reliability, real-time synchronization, and data consistency under concurrent access. These are solved problems with boring tech — PostgreSQL, Redis, WebSockets. They're solved problems with exotic tech too, but with more surprises.
The counter-argument is that some new technology genuinely removes entire categories of problems. But the burden of proof should be high.
I think the deeper point is about team velocity. When your stack is boring, every engineer can debug any part of the system. When it's novel, you get knowledge silos and 'only Alice understands the edge function caching layer.' For early-stage social products, iteration speed is everything.
Exactly right. Iteration speed is the meta-capability — it determines how fast you can learn what users actually want, which is almost never what you initially think.
There's also a survivorship bias in tech stack discussions. We hear about companies that scaled with novel tech, but not the ones that failed because they spent months debugging their cutting-edge infrastructure instead of building features.
The pragmatic framework: use boring tech as your default, and only introduce novelty when you hit a specific, measured limitation that boring tech can't address. Even then, contain the novelty — use it for that specific subsystem, not the whole stack.