Choosing the Right Stack for Your Project

One of the most common questions we hear from founders: "What stack should we use?"

The honest answer is: it depends less on the technology and more on the constraints of the project. Here is how we think through the decision.

Start With the Constraints

Before picking a framework, we ask four questions:

1. How fast do we need to ship? If you need something live in six weeks, reaching for a new framework your team has never used is a risk that rarely pays off.
2. What are the traffic patterns? A marketing site that handles 100 visitors a day and a real-time collaboration tool require completely different architectures.
3. Who maintains it after launch? A bespoke stack with no documentation is a liability the moment the original engineers move on.
4. What integrations are non-negotiable? Sometimes a CMS or payment provider makes the decision for you.

Our Default Positions

For most marketing and content sites: Next.js with static output. It is fast to build, fast to serve, and easily maintainable by any mid-level engineer.

For complex web applications: Next.js App Router with a dedicated API layer. The separation of concerns keeps things manageable as the product grows.

For projects with heavy content editing needs: we evaluate whether a headless CMS gives enough value to justify the added complexity. Often it does not — Markdown with a git workflow is more resilient.

The Trap to Avoid

Choosing a stack because it is interesting is a legitimate reason to use it on a side project. It is not a good reason on a client's live product.

The best stack is the one that delivers the right experience for users, can be shipped on time, and can be maintained without heroics.