How I Would Build an MVP - and How I Actually Pick the Stack

If you asked me tomorrow to build an MVP, I would not open a comparison of 40 frameworks. I would not draw a microservice map. I would not “future-proof” a product that has never met a paying user. I would write down one sentence: who this is for, what job it does, and what we will measure in four weeks. The stack comes after that sentence - not before.

Most failed MVPs are not too small. They are fake-big: a half-built “platform” with auth, dashboards, notifications, and three environments - and still no one completing the one job that would prove the idea. Technology is usually the alibi. This article is how I would actually ship.

1. What an MVP is - and what I refuse to call one

MVP is not “version 1 with fewer screens.” It is the cheapest experiment that can kill or strengthen the riskiest assumption. If the assumption is “people will pay to book this service online,” the MVP is a booking flow plus payment plus a human on the other end - not a CRM, not a loyalty program, not a native app.

• Viable means a real user can finish a real job. A clickable Figma prototype is research, not an MVP.
• Minimum means everything that does not serve that job is a later ticket - even if it looks “easy to add.”
• Product means you can repeat it next week without heroics. A Google Form plus a spreadsheet can be an MVP. A rewrite of Netflix’s architecture cannot.

2. Five questions before any repository exists

Stack arguments are cheap. Unanswered product questions are expensive. I do not pick Postgres versus Mongo until I can answer these out loud - with the founder, not with a blog post.

• Who is the first ten users, named if possible - not “everyone with a phone.”
• What is the one job they hire the product for this month? One. Not a platform.
• Where does the money or the signal come from - card charge, signed contract, booked slot, qualified lead?
• What constraint is real: four weeks, one developer, a regulated domain, an existing CRM, a Telegram audience?
• What would make us stop? If we cannot name a kill criterion, we are building a hobby, not an experiment.

3. Five filters I use to pick technology

I do not pick tools because they are trending. I pick them because they survive contact with a solo developer, a small budget, and the first angry user. Every technology has to pass these filters.

• Time to first real user. If the stack adds a week before anyone can click, it is the wrong stack for an MVP. Boring tools that I already ship in production beat a fashionable one I would learn under deadline.
• One-person operability. I should be able to deploy, read logs, restore a backup, and rotate a key without a platform team. Kubernetes fails this test for almost every early product.
• Hireable and replaceable. TypeScript, Postgres, and React are not exciting. They are the languages other good people already speak. An MVP that only I can extend is a hostage, not an asset.
• Data gravity. Put the source of truth in a real database with migrations from day one if the product has users and money. Spreadsheets are fine for the experiment next to the product - not inside the checkout.
• Escape hatch. I will use a managed auth, a hosted Postgres, a payment provider. I will not sign a five-year lock-in that makes export painful. Vendor is fine. Trap is not.

4. The default web stack I would start with in 2026

For a typical B2B or service MVP - booking, lead capture, a small customer portal, a calculator that turns into a quote - I would start here. Not because it is fashionable. Because I can ship it, SEO it, and still be able to hire someone else in six months.

• Next.js + TypeScript + Tailwind: one app for marketing pages (SEO, server rendering) and the product UI. Fewer repos, one deploy, shared types. App Router is fine if the team already knows it; I will not rewrite a working Pages app “for purity.”
• Postgres (often via Supabase, Neon, or a small VPS): relational data, transactions, and SQL I can inspect at 2 a.m. I reach for a document store only when the shape is genuinely document-shaped - not because “NoSQL is faster.”
• Auth: a managed provider (Clerk, Auth.js + a known IdP, or Supabase Auth) unless the product is the auth. Rolling custom sessions in week one is how you leak tokens and stall the actual feature.
• Payments: Stripe (or the local equivalent the first users actually use). No homemade billing engine. Invoices can wait; a working charge cannot.
• Hosting: Vercel for the Next.js app if traffic is web-shaped and the team wants previews; a Hetzner/VPS + Docker Compose if we need a long-running worker, predictable cost, or data residency. I wrote about that trade-off separately - the MVP rule is: one environment you understand, nightly backups, HTTPS, and a domain.
• Email and files: Resend or a similar transactional API; S3-compatible storage. Not “we will build an attachments module.”

5. When I throw the default away

A default is a starting bet, not a religion. I change it when the constraint is the product.

• The audience already lives in Telegram: a bot or Mini App can be the whole MVP. A website they will not open is not “more professional.” It is a second empty room.
• The job is in the field with bad signal: I consider a local-first or PWA path, not a native rewrite in week one. Native is a distribution decision, not a badge.
• The core is language (support, quoting, document extraction): I add an LLM API behind a strict schema and a human review step. I do not wrap a chat widget and call it a product.
• The founder is the operator and content is the product: a fast site plus a CMS they will actually use can beat a custom admin. WordPress is still allowed if the job is publishing, not an application.
• Two-sided marketplace: I still ship one side first. Supply or demand - whichever is harder to get. A “platform” with empty seats on both sides is a landing page with extra tables.

6. What I refuse to add before the first users

The fastest way to miss the experiment is to build the company around the experiment. This is the list I keep next to the backlog.

• Microservices, a message bus, and Kubernetes. One process, one database, one deploy. Split when a real bottleneck or a real team boundary appears - not when a diagram looks senior.
• A design system with 80 tokens and no screens. Ship the three screens that collect money. Extract components when the third copy-paste hurts.
• Roles, permissions, audit logs, and SSO - unless a paying B2B buyer blocked the deal on them. Then they are the MVP, not a side quest.
• A second mobile app. Responsive web or a Mini App covers the first hundred users in most service businesses I see.
• Perfect test coverage of glue code. I do want tests on money, auth, and the core job. I do not want a week of mocks for a landing form.

7. How the first four weeks would actually look

I treat the calendar as a product decision. If we cannot describe weeks, we do not have a plan - we have a wish.

• Week 0 (two days, not two weeks): write the one-pager. User, job, kill criterion, non-goals. Sketch the three screens. Agree what “done” means: a stranger can complete the job without a Zoom call from us.
• Week 1: vertical slice. Domain, deploy, database, empty layout, one happy path in production (even if ugly). If we cannot deploy on day three, the stack is already lying.
• Week 2: the job. Booking, quote, upload, payment - whatever we named in week 0. Manual operations behind the UI are allowed: a Telegram ping to the owner is a feature if it closes the loop.
• Week 3: the ugly edges. Empty states, errors, mobile, emails, basic analytics (where did they drop). Not a data warehouse. A funnel you can read.
• Week 4: put it in front of the ten named people. Watch. Do not add a feature during the calls. Write down what they did instead of what they said they wanted.

8. After launch: keep, extract, or rewrite

A good MVP is allowed to be slightly embarrassing. It is not allowed to be a trap. The stack above is boring on purpose: you can grow into it. You rarely have to grow out of it in the first year.

• Keep: the language, the database, the domain names in code. Those are cheap to live with and expensive to throw away.
• Extract: a worker, a second service, a real queue - when a job is slow, dangerous, or owned by another team. Not before.
• Rewrite only the part that learned the wrong lesson. If checkout is wrong, rewrite checkout. If the whole app is a vibe-coded maze, that is a people problem first: someone has to be able to explain it at 2 a.m.

Conclusion: pick the stack that survives the first no

I would build an MVP the unglamorous way: one job, one database, one deploy, tools I can operate alone, and a date when we decide to continue or stop. The “best” technology is the one that does not distract us from that decision. Next.js, TypeScript, Postgres, a managed auth, and a payment provider are not a personality. They are a way to spend the scarce weeks on the product instead of on the platform.

If you have an idea, a deadline, and a fear of picking the “wrong” stack - write via the contacts section. We can scope the one job, name the non-goals, and ship a slice you can put in front of real people without building a fake platform first.