Choosing a Tech Stack for Your Startup

There's no universal 'best' stack. Here's a framework for making technology choices based on your specific constraints, team, and stage.

There is no best stack

Founders ask me which stack to pick. I almost never give them a single answer. The question is malformed. The right stack depends on who you have, what you are building, and how much time and money you can spend before you need to be right.

The teams that pick well treat stack selection as a constraint-solving exercise. The teams that pick badly pick whatever is loudest on Hacker News this month. This piece is the framework I use when I help founders make this decision, usually as part of a start project engagement.

Start with the people

The most expensive stack is the one your team cannot maintain. Before I look at the problem, I look at who is going to write the code.

If you have one founding engineer, the stack should be whatever they are most productive in. Period. Switching costs at the start of a company are real. A founder who is fluent in Rails and Postgres will outship a founder who is teaching themselves a fancier stack at the same time as the product.

If you are hiring soon, the stack should be one a competent engineer in your market can join without a six-week ramp. That argues for popular, well-documented choices over niche ones. Popularity is not a virtue in itself. It is a hiring discount.

Look at the workload, not the trend

Before picking, I describe the system in three sentences:

What kind of latency do users expect?
What is the dominant data shape (relational, document, time series, embeddings)?
What is the read-to-write ratio and how much of it can be cached?

These three answers cut the field of options dramatically. A latency-insensitive analytics dashboard with mostly relational data has different needs from a real-time multiplayer canvas, and confusing the two is how stacks become unfit.

I cover the database side of this in PostgreSQL for everything and the real-time side in real-time architecture patterns.

Default to boring, deviate with reason

A boring stack at a startup is not a failure of imagination. It is a deliberate trade. Boring tools have:

Better documentation
More Stack Overflow answers
Easier hiring
Predictable failure modes
Mature observability

I usually default to: a popular framework on a major language (TypeScript with Next.js, Python with FastAPI, Ruby on Rails, Go with chi/echo), a managed Postgres, a managed cache, a managed queue, and a managed deployment platform. Then I deviate from this baseline only where the problem genuinely demands it.

In my experience, the founders who pick three exotic technologies before launch lose six months to integration problems they did not know they were signing up for.

Pay for time you do not have

Hosted services are usually a good trade for early-stage teams. The math is simple: how many engineering hours per month would it take to run this thing yourself, and is that worth more than the bill?

The services I happily pay for at the start:

A managed deployment platform (Vercel, Fly, Render, AWS App Runner)
A managed database with backups and point-in-time recovery
A transactional email provider
An auth service unless auth is a differentiator
An error tracker like Sentry
An analytics tool that does not require self-hosting

The teams I see save the most money are not the ones who self-host the most. They are the ones who pick the right managed services and free engineers to work on the product.

Avoid these traps

A short list of mistakes I keep watching teams make.

Premature microservices

A three-person team does not need ten services. Microservices solve organizational problems you do not have yet. Start with a modular monolith. Split when you have a real reason, not a theoretical one.

Resume-driven development

Picking a tool because it will look good on your CV is a real cost paid by the company. I am not above the temptation, but I notice it and steer the team toward what serves the product.

Coupling to a single cloud feature

Lock-in is fine if it is a feature you cannot replace cheaply. Lock-in is bad if it is something a competing provider does just as well. I keep my data layer portable on principle, even when it costs me a little leverage on the convenient features.

Confusing tools with architecture

The framework you pick will not save you from a bad domain model. Most of the bugs I get called in to fix are not framework bugs. They are conceptual ones. A good architecture in a boring stack beats a bad architecture in a fancy one every time.

A simple stack-picking exercise

When I sit with a founder, we walk through this in under an hour:

Who is writing this? What are their two strongest stacks?
What does the system do? Latency, data shape, read/write ratio
What are the deal-breakers? Compliance, data residency, edge geography
What can we buy instead of build? Auth, queue, search, analytics
What changes in 12 months? Hiring plan, traffic shape, integrations
Pick the boring default. Then justify each deviation in one sentence

By the end I have a stack that fits the team and the problem, and a written record of why we deviated where we did. The written record matters as much as the choice itself, because the team will revisit it in a year.

The takeaway

Choosing a stack is not about picking winners. It is about matching tools to people, problem, and stage, defaulting to the boring choice, and deviating only with a reason you would defend in writing. Done well, the stack disappears into the background and lets the team focus on the product. Done poorly, the stack becomes the product.

If you want help running this exercise on a specific company, that is exactly the kind of advisory work I do.