The 2026 Startup Stack: What We Ship On, What We Dropped, and Why

Ask ten agencies what stack they use and you will get ten lists of tools. The list is the least interesting part. What actually matters is the reasoning underneath it: a stack is a set of bets about which problems you are willing to spend your only nine months of runway solving, and which ones you are going to pay somebody else to have already solved.

This is the default we start every new client product on in 2026. It is a default, not a doctrine — the last section of this article is a list of the things we removed from it, and every layer below ships with the condition that tells you to leave.

The default, layer by layer

One codebase for the marketing site and the product. One database that holds relational data, documents and embeddings. One deploy target until the product earns a second one. Everything that is not your differentiator, bought rather than built.

The column on the right is the one that matters. Most stack arguments are really arguments about scale that has not arrived yet — teams adopting the architecture of a company a hundred times their size, and paying for it in velocity every single week until they run out of money.

Six things we stopped defaulting to

None of the following are bad technology. Several of them are excellent, and we still use most of them when the situation calls for it. They simply stopped being the right first choice for a team of four with nine months of runway.

Hand-rolled authentication

This is the single change that has saved our clients the most money and the most embarrassment. Authentication looks like a two-day job and it is not. It is sessions, refresh, password reset, email verification, social providers, multi-factor, rate limiting on every one of those endpoints, and an audit trail. It is also the first place a security reviewer looks, and the place where AI-assisted code most often ships something that works but is not safe.

A managed provider gets it right on day one for less than the cost of the security review you would otherwise be paying for. There is exactly one good reason to build it yourself: a compliance or data residency rule that forbids the vendor. Wanting to own it is not a reason.

A separate API service on day one

Splitting the backend out before you have a second consumer for it buys you nothing and costs you a deploy pipeline, a second on-call surface, a network hop, and a versioning problem between two things that ship together anyway. Start colocated. Split it the week a mobile app or a partner integration genuinely needs the same endpoints — and by then you will know what the boundary should actually be, which you do not know now.

A dedicated vector database

This is the newest entry on the list and the one clients push back on most. If your product needs retrieval, the instinct is to add a specialised vector store. For the first few hundred thousand documents, putting embeddings in your existing Postgres database with pgvector is faster to build, cheaper to run, and removes an entire category of bug: the sync job between the database that holds the truth and the index that holds a stale copy of it.

Move when your corpus is genuinely into the millions of vectors or you need hybrid search with re-ranking. Most products never get there, and the ones that do will have the revenue to pay for the migration comfortably.

One default, six deviations

Product type rarely changes the whole stack. It changes exactly one decision, and knowing which one in advance is most of what experience buys you.

Two of these deserve calling out. For B2B SaaS, model organisations, roles and invitations into the very first schema even if launch is single-user — retrofitting multi-tenancy is the most expensive rewrite we are ever asked to do, and it touches every query in the codebase. For marketplaces, build the money path before the browsing experience, because a ledger that was added after launch has to be reconciled against history that was never designed to be reconciled.

The AI layer is part of the stack now

Two years ago the AI layer was a feature decision. In 2026 it is an architectural one, because it changes what the data layer has to do. Retrieval needs the same permission rules as your API. Embeddings need to be regenerated when source content changes. Model responses need to be logged in a form you can evaluate later, which means your observability layer has to handle content, not just metrics.

This is why the AI layer sits inside the stack diagram rather than beside it, and why we treat the model provider like any other critical dependency: routed, budgeted, monitored, and swappable. The single biggest architectural mistake we see is scattering direct model calls across a codebase. Put them behind one module. When pricing changes, a better model ships, or you need to route easy requests to a cheaper tier, you want that to be one file and not forty.

Three rules for adding anything new

1. 1.It has to remove more code than it adds. A tool that saves a hundred lines and introduces a config file, a build step and a new failure mode has not paid for itself.
2. 2.Someone other than its advocate has to be able to debug it at 2am. Novel technology chosen by one enthusiastic engineer becomes a single point of failure the moment that person takes a holiday.
3. 3.There has to be a documented way out. If migrating away requires a rewrite rather than a refactor, it is not a dependency — it is a marriage, and it should be treated with the seriousness of one.

Those three rules have killed more stack proposals in our own team than any technical argument. They are also why our default has changed remarkably little in two years while the surrounding discourse changed completely.

The part that outlives the stack

Assume we are wrong about at least one layer above. We usually are — the dropped list is what being wrong looks like in practice. What protects you is not picking correctly, it is keeping the cost of being wrong low: business logic that does not import your framework, data access behind a boundary rather than sprinkled through components, and an application that could run in a container tomorrow if the platform bill ever overtook the salary of the engineer it saves.

“The stack you choose matters far less than how cheaply you can change your mind about it in eighteen months.”

If you want the longer argument about the framework layer specifically — why we pick Next.js for most client work and the cases where we deliberately do not — we wrote that one separately.

And if you are staring at a greenfield product right now and would rather not spend three weeks arguing about tooling before writing a line of feature code, that first decision is a conversation we have had many times. It usually takes about an hour.