The stack doesn't matter as much as people think - but it matters more than people who say "the stack doesn't matter" admit.
Founders ask us "what tech stack should we use?" at least once a week. The honest answer is: it depends on your problem, your team, and your timeline. But there are some principles that hold true regardless.
Hire for the stack, or pick the stack for the team
If you have a team of Ruby developers, don't build in Go because someone read a blog post about performance. The productivity loss from learning a new stack will cost you far more than the theoretical performance gain. Conversely, if you're starting from scratch, pick a stack with a deep talent pool in your market.
Our default and why
We default to TypeScript across the stack: React or Next.js on the frontend, Node.js on the backend, and React Native for mobile. One language everywhere means shared types, shared validation logic, and developers who can work across the full stack without context-switching.
When the default doesn't fit
- CPU-intensive work: consider Go, Rust, or Python depending on the domain
- Data science and ML: Python is the ecosystem, don't fight it
- Legacy integration: sometimes you need Java or .NET to talk to existing systems
- Real-time / embedded: different world, different tools
The real criteria
When evaluating a tech stack, ask: can we hire for it? Is it actively maintained? Are there production-grade libraries for the things we need (auth, payments, email)? Has it been used at our scale by companies we respect? If the answer to all four is yes, the stack is fine. Ship the product.
Ben Arledge
CEO & CTO, CloudOwlNeed help building this?
No sales pitch, just an honest conversation about what you're building.
See our AI capabilities, React/Next.js work, or full service list.