The stack we reach for, and why

Every agency has a default stack, whether they admit it or not. The honest ones tell you theirs and explain why, because a default that has been used on dozens of real projects is worth more than a fresh "best tool for the job" debate started from scratch every time. Ours is deliberately unexciting, and that is the whole point. Here is exactly what we reach for, the reasoning behind each piece, and, more usefully, the specific moments we put the default down and pick something else.

The default, in one breath

For most products we build: Next.js and React on the front end, TypeScript everywhere, Postgres for the database, and boring managed infrastructure underneath. That sentence covers maybe eighty percent of what we ship. The remaining twenty percent is where the interesting decisions live, and we will get to those.

None of this is chosen to win an argument online. It is chosen because the talent pool is enormous, almost every problem has already been solved by someone else, and a new engineer can be productive in it within a day. Novelty is a cost you pay forever. We would rather spend that budget on your product.

Next.js and React, because the boring path is paved

The front-end framework war burns the most oxygen and matters the least. Any mainstream choice works. We reach for Next.js because it covers marketing pages, dashboards, and SEO-sensitive content in one codebase, and because hosting it is a genuinely solved problem rather than a science project.

The reason underneath that is React itself: the largest component ecosystem in existence, which means the date picker, the table, the auth flow, the thing you would otherwise spend a week building, already exists and is battle-tested. When you hire on a popular framework you are not just buying code, you are buying every Stack Overflow answer and every library author who solved your problem before you had it.

We do deviate here, and predictably. If a product is a pure internal tool behind a login wall with no SEO needs, we will often drop Next.js for a plain React single-page app on Vite. Server rendering is a real complexity tax, and there is no reason to pay it when nobody outside your login ever sees a page. The framework should match the job, and sometimes the lighter tool is the right one. We dig into that trade-off more in Next.js versus Astro, because for content-heavy sites the answer occasionally tips the other way too.

TypeScript everywhere, because future-you is the maintainer

TypeScript is non-negotiable for us, and we run it strict. The argument against it is always "it slows us down at the start," which is true and irrelevant. The cost lands on day one and the payoff compounds for years, every time you rename a field, refactor a function, or hand the codebase to a new engineer who needs the compiler to tell them what is safe to touch.

One language across the front end and back end genuinely helps small teams. Shared types between your API and your UI mean a change in one place lights up the other before it ever reaches a user. We made the longer case for running it strict in is strict TypeScript worth it, and the short version is: yes, and the projects that skip it pay the difference in 2am bugs.

Where we ease off: throwaway scripts, spikes, and genuine prototypes meant to be deleted. Strictness is a tool for code that has to live, and not every line does.

Postgres first, because one boring database does almost everything

We default to Postgres and we mean it. The temptation on every project is to match a trendy store to each shape of data, one for documents, one for search, one for the queue. We have learned the lazy answer is usually right: start with one Postgres instance and only add a second system when Postgres genuinely cannot do the job, which is rarer than the architecture diagrams suggest.

A single Postgres can act as your relational store, your document store with jsonb, your full-text search, and your job queue. That is one backup strategy, one connection pool, one thing to monitor at 3am, instead of four systems that all have to be online for your app to work. The reflex to reach for MongoDB rarely survives the question "what do you actually gain," which we get into in Postgres versus MongoDB.

Boring, reliable infrastructure underneath

Underneath all of it we run managed, boring infrastructure: a managed host, a managed Postgres, object storage for files, and as little bespoke ops as we can get away with. The goal is that nobody on your team needs to become a part-time platform engineer to keep the lights on.

The real cost of infrastructure is almost never the hosting bill. It is the operational surface. Every extra system is another upgrade path, another security advisory to read, another failure mode, another thing a new engineer has to learn before they can ship. We treat each new piece of infrastructure as a standing tax on the whole team, and we refuse to pay it until something forces our hand. That discipline is most of what good cloud and DevOps work quietly buys you.

The complexity we deliberately avoid

A senior team is defined as much by what it refuses to build as by what it ships. The things we steer away from until there is a real reason:

• Microservices on day one. A service per team makes sense at a scale most products never reach. For everything else it is a distributed monolith with network calls where function calls used to be, and ten deploy pipelines instead of one. Start with a well-structured single codebase and split only when a clear seam and a real team boundary demand it.
• Kubernetes for forty users. It is a real tool for real scale problems and dead weight on a product that does not have them. A managed host carries you a remarkably long way.
• A second database "to be safe." Every store you add is another thing to back up, secure, and keep in sync. We add one only when we can name the limit Postgres hit, with a number attached.
• Heavy abstractions for flexibility you do not have yet. The generic plugin system for the one integration you actually need is a tax on every future change. We build the concrete thing first.

The thread tying these together: we add complexity in response to a measured problem, never in anticipation of an imagined one. "Our p99 latency crossed a threshold under load" is a reason. "It feels more scalable" is not.

When we deviate, and why

The default is a starting point, not a religion. The honest reasons we put it down:

• A heavy data or ML workload. Python earns its place on the back end. Doing serious data work in Node to keep one language is a false economy, and we will happily run a Python service alongside the TypeScript one when the work calls for it.
• Realtime-first products like collaborative editing or live multiplayer. There the architecture, not the framework, is the hard part, and we design around it before picking any logos.
• Your team already knows something else cold. A team that ships fast in Rails or Laravel will out-deliver the same team learning Next.js from scratch. If we are building alongside your people, their existing strengths often beat our theoretical default.
• A genuine scale or latency limit where a specialized tool, a cache, a search cluster, a column store, clearly pulls ahead. We reach for it then, with the number that justified it written down.

Every one of those is specific and measurable. None of them is a vibe. That is the difference between a senior default and a fashion.

The takeaway

The stack we reach for is Next.js, React, and strict TypeScript over a single Postgres instance on boring managed infrastructure, because it is hireable, stable, and good enough at everything that we get to spend our energy on your product instead of on plumbing. We deviate when a constraint we can name and measure says to, and not a day before.

If you want a straight second opinion on a stack you are about to commit to, or you want it built right the first time, tell us what you are working on. That is the good kind of lazy: a default sharp enough that we rarely have to reinvent it, and the judgment to know exactly when we should.