Every six months a new wave of "best tech stack 2026" articles appears, ranking frameworks by GitHub stars and benchmark numbers. They are mostly useless for picking what to actually build with.
The right stack is the one that matches your team, your problem, your timeline, and your willingness to operate the result. It is rarely the trendy one. It is sometimes the boring one. It is occasionally the obvious one, but only after you have done the work to know why.
Here is the framework we use when starting a new project.
Step 1: Who is going to maintain this?
This is the first question, not the last. The best technology for a problem is the one that the team responsible for it can operate well.
We do not pick Rust for a team of three Node developers, even if Rust is the "better" choice on paper. The total cost of ownership over three years includes hiring, debugging at 2 AM, and onboarding the fifth engineer. The trendy choice is rarely the cheap choice once you account for those.
If the client will maintain the system after we ship: we use what they use. If we will maintain it: we use what we operate best.
Step 2: What does the workload actually look like?
We force ourselves to answer five questions in writing before we look at any frameworks:
- How many requests per second at peak?
- How much data flows through the hot path?
- How latency-sensitive is the user-facing flow?
- How write-heavy is the data layer?
- How geographically distributed are users?
A typical SaaS B2B product gets 10-50 requests per second at peak, with sub-second latency requirements and read-heavy data. That is a Postgres-and-Node-or-Python problem. Picking Cassandra and Kafka because you might one day be Netflix is a great way to burn 18 months on infrastructure that solves problems you do not have.
Step 3: What are the two or three integrations that drive everything?
Most products are not greenfield. They have to talk to Stripe, or QuickBooks, or Salesforce, or HubSpot, or a custom EDI feed from a partner. The integration with the messiest API tends to dictate your stack more than the framework debate does.
Two examples from real client work:
- A client needed to push events to Salesforce in real time. Salesforce's SDK is best on the JVM. We used Java for that service even though the rest of the system was Node, because the alternative was reverse-engineering the Salesforce auth flow.
- Another client had to consume a partner feed that was only documented in PHP. We wrapped the PHP code in a small service rather than port it. The team groaned. The team also shipped on time.
You will hate this advice while you take it.
Step 4: What is the team's velocity curve?
A senior team with a familiar stack ships fast for the first three months and stays fast. A senior team with an unfamiliar stack is slow for two months, then catches up, then ships fast. A junior team with an unfamiliar stack might never catch up.
If your timeline is three months, do not use anything new. If your timeline is two years, you can afford a learning curve and the gains compound.
We default to:
- TypeScript on Node.js for product backends. Boring, fast, hireable.
- Postgres for almost all data. Cheap, reliable, can do 80% of what people reach for specialty databases for.
- Next.js or Remix for product frontends, depending on the rendering profile.
- React Native or Flutter for mobile, depending on team and platform priority.
- Redis for caching and queues. BullMQ on top for jobs.
- S3 or MinIO for files.
- Stripe for payments unless there's a strong reason not to.
This is not the "best" stack. It is the stack that lets a small team move fast and operate well. We deviate from it only when there is a specific, concrete reason.
Step 5: What do you want to be hard to change later?
Some decisions are easy to change: which CSS framework, which form library, which icon set. Some are hard to change: which database, which auth model, which deployment platform, which cloud.
Spend most of your decision time on the hard-to-change decisions. Spend almost no time on the easy ones. The default is fine.
A useful test: if we wanted to swap this out in six months, how painful would it be? If the answer is "two days," it does not matter much. If the answer is "rewrite half the app," it matters a lot.
What we ignore
We do not pick technologies based on:
- Benchmarks. Benchmarks measure micro-workloads that look nothing like production. The fastest framework in a benchmark might be the slowest in your actual hot path.
- GitHub stars. Stars measure popularity at a moment in time, not staying power. Plenty of starred projects are now abandoned.
- Trends on Twitter or Hacker News. These are dominated by the loud minority working on greenfield projects with no users.
- What the cool startups use. Cool startups can absorb the cost of bleeding-edge tooling because they have generous budgets and tolerance for risk. Your team probably does not.
The shorter version
The right stack is the one that lets the team responsible for it ship and operate well. Boring is fine. Boring is often better. Surprise yourself only on the decisions that earn the surprise.
If you want a recommendation specific to your problem, tell us what you're building.