Choosing the Right Tech Stack
A practical framework for selecting technologies that scale with your startup.
The tech stack debate is one of the most common and often least productive discussions in startup engineering. Strong opinions about frameworks and languages generate more heat than light, while the factors that actually matter for startup success receive less attention than they deserve. Here is a practical framework for making these decisions.
Optimize for Hiring
The most important quality of a tech stack is whether you can hire engineers who are productive in it. A technically superior but obscure technology is a liability if it takes three months to fill every open position. Mainstream technologies like Python, TypeScript, Go, and React have large talent pools, extensive documentation, and mature ecosystems of libraries and tools.
This does not mean you should never use newer or less common technologies. But the decision should be deliberate and justified by a specific technical advantage that mainstream alternatives cannot provide. “It would be fun to try” is not a valid justification for a technology that your next five hires need to learn from scratch.
Boring Technology Is a Feature
Dan McKinley’s concept of “choosing boring technology” is especially relevant for startups. Boring technologies are well-understood, predictable, and have known failure modes. When something breaks at 2 AM, you want to be debugging a well-documented database, not an experimental distributed system that three people in the world understand.
Every startup gets a limited budget of innovation tokens. Spend them on your core product, not on your infrastructure. If your competitive advantage is in AI, use a standard web framework and a proven database. If your advantage is a novel user experience, use reliable backend technologies that you do not have to think about.
The Monolith-First Approach
Starting with a monolithic architecture is almost always the right choice for early-stage startups. Microservices add operational complexity, network latency, and distributed system challenges that you do not need when you have five engineers and are still figuring out your product-market fit.
A well-structured monolith with clear module boundaries can be decomposed into services later when you have concrete evidence about which components need to scale independently. Premature decomposition, on the other hand, creates coordination overhead that slows down the rapid iteration startups depend on.
Database Selection
For most startups, PostgreSQL is the right default choice. It handles relational data well, supports JSON for semi-structured data, has excellent full-text search, and scales to millions of rows without breaking a sweat. Adding a specialized database should be driven by a specific requirement that PostgreSQL cannot meet, not by a theoretical preference for polyglot persistence.
When you do add a second data store, make sure you understand the consistency implications. Keeping data synchronized across multiple databases is a non-trivial operational challenge that will consume engineering time for as long as both systems exist. The convenience of a specialized tool must outweigh this ongoing cost.