10 technical strategies to avoid when scaling your startup (and 5 to embrace)

Here's what nobody tells you about scaling: premature optimization is the root of all evil. Donald Knuth said it in 1968, Ron Jeffries reinforced it with "You aren't gonna need it," and Intercom's Brian Scanlan lives it. Day one of your startup is probably not the time to be learning Kubernetes. Unless you already know Kubernetes cold, or you're building infrastructure for Kubernetes users, the quickest way to get a service running is boring tech: EC2 hosts in an autoscaling group behind a load balancer.

The cloud gives you unfathomable scale—S3, SQS, DynamoDB, sure. But you can do a lot with a small number of computers talking to a single database. Adding extreme scalability before you need it leads straight to technical debt. Intercom calls this "Run Less Software." Being technically conservative has helped them avoid building and maintaining stuff that would have slowed them down over time.

Same with multi-cloud. You hear about it at every conference. Sounds smart. It's a terrible technical strategy for startups. You're doubling complexity, fragmentation, costs, and training burden for resilience you probably don't need yet. Pick one cloud, learn it deeply, use it well.

What you should do instead: make security job zero. Not just because consumer expectations are higher and GDPR exists, but because security breaches kill startups. Bake it in from the beginning. Run less software so you have less surface area to defend. Use boring, battle-tested technology that doesn't require a PhD to operate. Keep your architecture simple enough that any engineer on the team can understand it.

The five things Intercom actually embraces: security first, running less software, being technically conservative, keeping things simple, and focusing on delivery over novelty. One surefire terrible technical strategy? Doing whatever you hear at a conference. Only you understand your business context and technical challenges. Don't blindly follow anyone's advice—including this article's. These are opinions based on experience at one company in one situation. What works for Intercom might not work for you, but the principles are solid: build for what you need now, not what you might need someday.