Stack conversations get emotional because they feel like identity. They are not. A tech stack is a bet about which problems you will have, and the only honest way to make it is to be specific about what you are actually building, who is building it, and by when.
The four questions that decide it
Before naming a single technology, we answer these. Nine times out of ten they make the decision for us.
1. Who maintains this in a year?
If the answer is "a solo founder who is not technical" or "whoever we hire", the stack must be mainstream. An elegant Elixir backend is a liability if nobody in your hiring pool writes Elixir and the person who did has moved on. This one question kills more clever choices than any benchmark.
2. What is the deadline, really?
Six weeks means you use what the team already knows. Six months buys you exactly one new thing — one — and only if it is load-bearing. Learning a framework, a language and a deployment model simultaneously is how a three-month project becomes a nine-month project, and every team believes they are the exception.
3. What is genuinely hard about this product?
Most products are CRUD with a good interface, and the hard part is the product, not the plumbing. But sometimes there is a real technical core: sub-100ms latency, offline-first sync, heavy geospatial queries, real-time collaboration, on-device inference. Optimize the stack around that one thing and take the default for everything else.
4. What is irreversible?
Rank your decisions by how expensive the mistake is:
| Decision | Cost to change later |
|---|---|
| Database and data model | Brutal |
| Auth and identity model | Painful |
| Language / runtime | Expensive |
| Hosting platform | Moderate |
| Frontend framework | Annoying but survivable |
| CSS approach, component library | A weekend |
Spend your thinking at the top of that table. Teams routinely spend three days on the component library and forty minutes on the data model, and it shows.
Our defaults, and when we break them
Absent a forcing constraint, this is where we start — because these are the choices where the ecosystem, the documentation and the hiring pool do the most work for us.
Frontend: React, or Next.js if content matters
Plain React with Vite for app-shaped products behind a login — fast builds, no server, no ceremony. Next.js when SEO, marketing pages and rendering strategy are part of the product, because you get server rendering and routing without assembling it yourself.
We break it when: the site is genuinely content-first with little interactivity. Then a static generator, or plain HTML, beats shipping a framework to the browser. (Every product page and blog post on this site is static HTML. It renders instantly, it is trivially crawlable, and it has never broken.)
Backend: Node/TypeScript, or serverless functions
The same language across the stack is a real productivity gain on small teams — shared types, shared validation, one mental model, one set of tooling. For most products the backend is a handful of endpoints, and serverless functions on the platform you are already hosting on remove an entire category of operational work.
We break it when: the workload is CPU-heavy or data-science-adjacent. Then Python, and no apologies.
Database: PostgreSQL
Almost always. It does relational, JSON documents, full-text search, geospatial and vector search in one boring, reliable, well-understood system that every engineer you will ever hire already knows. Most projects that "needed" a specialist database needed an index.
We break it when: there is a genuinely non-relational access pattern at real scale, or when the platform's native store is a better fit for the deployment model (a Cloudflare-native app with edge-local data, for example).
Mobile: React Native
One codebase, two platforms, and it shares language and mental model with the web team. Fully native is the right call when the product's core is the platform integration — deep hardware access, complex background behaviour, or an experience that has to feel exactly right in a way cross-platform tooling still fights you on.
Hosting: managed, always
Vercel or Cloudflare for almost everything we ship. Nobody is paying us to run a Kubernetes cluster, and a founder's runway is not the place to discover why platform engineering is a full-time discipline. We wrote up how we pick between the two separately.
The novelty budget
The most useful idea we have stolen: you get to spend a small, fixed budget of novelty on any project. Two or three unfamiliar things, total. Everything else must be boring.
Spend it where the product's value actually lives. If you are building a real-time collaborative editor, spend it on CRDTs — and then use Postgres, React and a managed host for everything around it, because you are going to need every hour of the remaining attention for the hard part.
What people do instead is spend the whole budget on infrastructure — a new runtime, a new ORM, a new deploy pipeline, a new state library — and arrive at the actual hard problem exhausted, three months late, and debugging someone else's alpha release.
The uncomfortable summary
The best stack is the one that lets you change your mind about the product cheaply, because you will change your mind about the product. Every hour spent on infrastructure is an hour not spent discovering that the feature you were building is not the one anyone wanted.
Boring stack. Interesting product. That ordering is the whole game.
Weighing a stack decision?
We will tell you honestly what we would use and why — including when the answer is "you do not need us for this."
Ask us →