MVP Tech Stack

A founder came to us in June with a working product and a problem that had nothing to do with code. Three paying customers had asked for the same small integration, and shipping it meant touching a message queue, a second database, and an auth layer a departed contractor had written. Nothing was broken. The team simply could not answer a customer question in under a fortnight.

That is what a bad MVP tech stack costs. Not downtime, not a rewrite, not the hosting bill — response time to the market. Choosing an MVP tech stack looks like a technology question and is almost never one, which is why the debate runs for two weeks and settles nothing.

What the MVP Tech Stack Decision Is Actually Deciding

CB Insights' post-mortems of failed startups put lack of market need at the top of the list at 42 percent, ahead of running out of cash at 29 percent and the wrong team at 23 percent. Read as an engineering brief, that says something uncomfortable: your first guess about the product is probably wrong, and the stack's job is to make finding that out cheap.

So the question is not "which technology is best." It is three narrower ones:

• How fast can we change our mind? Measured from deciding to change the data model to having it in production.
• Who else can work on this? Not in theory — in your city, at your budget, next month.
• What have we made permanent by accident? Anything you write yourself, you maintain forever.

A stack that scores well on those three is a good MVP stack even if it is deeply unfashionable.

Start From the Boring Default, Then Argue Your Way Off It

The useful discipline is inversion. Rather than assembling a stack from scratch, start with the default for each layer and require a stated reason to deviate. "It felt cleaner" is not one. "Our core object is a document with 200 optional fields" is.

Layer	Reasonable default	Deviate when
Database	PostgreSQL	The core object has no stable shape, or graph traversal is the primary access pattern
Backend	One language, one deployable process — TypeScript, Python, Go or Rails	Never at MVP stage. A second runtime doubles your CI, secrets and on-call surface
Frontend	React, or the framework your team already ships	The product is content-first and a static site would do
Hosting	A managed platform (Vercel, Render, Railway, Fly, a small VM)	You have data-residency or compliance constraints
Auth, payments, email	Bought, always	Effectively never
Background jobs	A database-backed queue in your existing process	You are already at sustained throughput, which pre-launch you are not
Search	Postgres full-text	Search is how users primarily navigate

The defaults are boring on purpose, and the industry has quietly converged on them. In Stack Overflow's 2025 developer survey, PostgreSQL reached 55.6 percent of all respondents and 58.2 percent of professional developers, up from 48.7 percent the year before — its largest single-year jump, and an 18-point lead over MySQL. Node.js and React sit at 49.1 and 46.9 percent among professional developers. That popularity is not an argument about quality. It is an argument about how many people can help you, and how likely your next hire has already used it.

The two-runtime tax

The most common self-inflicted wound we see is a Python service, a Node service and a third thing "for the real-time bit," all before the first paying customer. Each runtime brings its own dependency management, build pipeline, logging format and security updates. Three services do not cost three times one; they cost more, because now the failures happen between them. At MVP scale the correct number of deployable services is one. Split it later, once you can see where the seam actually is.

What Managed Infrastructure Costs in 2026

Founders routinely over-engineer to avoid a hosting bill smaller than an afternoon of engineering time. The current numbers:

Service	Free tier	Paid entry point
Supabase (Postgres + auth + storage)	500 MB database, 1 GB file storage, 2 projects — paused after about a week of inactivity	25 dollars a month, including a 10 dollar compute credit
Neon (serverless Postgres)	0.5 GB storage, 100 compute-hours, scale-to-zero	Usage-based: about 0.35 dollars per GB-month and 0.106 dollars per compute-hour, no monthly minimum since December 2025
Vercel (hosting)	Hobby, non-commercial only	20 dollars per user per month, with a 20 dollar usage credit and 1 TB of transfer

Two things worth noticing. The entry price is trivial relative to salary — nobody should build their own deployment pipeline to save 25 dollars a month. And the shape of the pricing differs more than the amount: scale-to-zero billing is excellent for bursty traffic and awful for a background job that runs constantly, while per-seat pricing looks cheap at two founders and is a line item at fifteen.

Say the quiet part plainly, too. A free tier that suspends your database after a week of inactivity is the wrong choice for a product you demo to investors. The cold start is not a technical detail; it is the first ten seconds of your pitch.

Buy Everything That Isn't the Reason You Exist

Every MVP contains three or four capabilities that are necessary and completely undifferentiated. Auth. Payments. Transactional email. A support channel. Each looks like a two-day job and each has a long tail — password resets, tax handling, deliverability, out-of-hours coverage — that only appears once real users arrive.

The test: would a prospect notice the difference between your version and a bought one? If not, buying it converts directly into roadmap weeks. Our longer piece on build versus buy works through where the line moves once you have revenue.

The capability founders forget to price

The Four Things That Actually Force a Rewrite

Scale is not on this list. Almost no MVP dies of traffic. What we see force rewrites, in order of frequency:

1. A data model that encoded a guess as a constraint. The one genuinely hard-to-reverse decision. Migrating a schema with real customer data is slow, risky, unglamorous work.
2. A homegrown auth or billing layer. Fine until the first enterprise security questionnaire, or the first tax jurisdiction you did not know existed.
3. More than one runtime, adopted without a reason. Nobody rewrites because of this directly; they rewrite because velocity collapsed, and this is why.
4. A private framework. One senior engineer builds abstractions only they understand, then leaves. The code is fine. Nobody can safely change it.

AI assistance sharpens the last point rather than softening it. Stack Overflow's 2025 survey found 84 percent of developers using or planning to use AI tools while only a minority trust the output, and 66 percent naming "almost right, but not quite" as their leading frustration. That failure mode is worst where training material is thinnest — obscure frameworks, young libraries, in-house abstractions. A mainstream stack pays you back twice: in hiring, and in every suggestion nobody has to verify line by line.

When This Advice Is Wrong

Boring defaults are right for most products and wrong for some. Ignore this framework if:

• The infrastructure is the product. A video transcoder, a trading engine, an on-device ML feature. The thing you would normally buy is what customers are paying for.
• You have a hard residency or certification constraint. Regulated data turns hosting from a preference into a requirement, and designing for it on day one is far cheaper than retrofitting. Our cloud migration guide covers the retrofit case.
• Your team has deep expertise in something unusual. Five years of Elixir beats a framework that polled well — provided it is genuine expertise and not enthusiasm.

The One-Page Version

1. Write down the one thing your product does that nothing else does. That is the only place custom engineering is justified this quarter.
2. Take the default for every other layer, and deviate only with a reason you would say to a customer.
3. Choose one language and one deployable service. Split later, when you can see the seam.
4. Spend your careful thinking on the data model — the only decision that is expensive to reverse.
5. Buy auth, payments, email and support. Rebuild them later if they become differentiating, which they mostly will not.
6. Pick hosting on billing shape, not headline price. Per-seat and usage-based fail in opposite directions.

The best MVP tech stack is the one that lets you ship a change on Tuesday because a customer asked on Monday. Everything else is a preference with a marketing budget behind it.

If you are weighing two stacks against a deadline, our consultancy team does this assessment in about a week — send us the spec and we will tell you which decisions are reversible and which you only get to make once.

Frequently Asked Questions