The honest answer is a toolbox, not a sacred stack: the twenty or so tools we reach for, what job each one is for, and the judgment of when the heavier machinery earns its place. On your own accounts, near free until real users, nothing thrown away when traction arrives.
Boring wins. The MVP is an experiment about your product. Exotic technology adds a second experiment underneath it, and two experiments at once is how you learn nothing from either. Every tool below is dull, documented and battle-tested, which is exactly the compliment intended.
Managed beats self-hosted, for now. Before traction, your scarcest resource is attention. Let vendors run the database, the hosting and the email. The bill for all of it is trivial at this stage, and the day it stops being trivial is the day you can afford it.
Own everything. Every service on your own accounts, your own domain, your own data. Done this way from day one it costs nothing extra. Retrofitted later, after a platform or a vendor held it for you, it is a migration. This principle is most of the difference between an asset and a subscription.
These are defaults, not a religion. Real builds swap pieces when the product demands it: Elasticsearch when search is the product, Kafka when there are real event pipelines, DynamoDB for certain access patterns, Three.js when the product is a world. The value below is the reasoning, so you can tell when a swap is earned and when it is a developer entertaining themselves.
Web: Next.js on Vercel. One framework for pages, API routes and server rendering, deployed by pushing to git. Fast by default, effectively free until real traffic, and so widely used that every problem you will hit is already answered somewhere. Serverless has a real limit though: it is built for request-and-response, not for work that runs long. WebSocket servers, heavy jobs, model pipelines and anything that must stay alive for minutes runs better on a persistent host like Render, or a plain Hetzner server, sitting alongside the Vercel app. Most products need both eventually.
Mobile: one Expo codebase. Compiles to native iOS and Android from a single React codebase, with the web app sharing most of the logic. The alternative, two native codebases, is three products to keep in sync before you know anyone wants one.
Database: Postgres, managed, usually Supabase. Postgres is the default answer to every data question until measurement says otherwise: relational data, JSON, full-text search, queues in a pinch, all well enough for years. Supabase bundles it with auth, storage and realtime subscriptions on your own account, which collapses three integrations into one. Neon is the leaner alternative when you only want the database.
Auth: Supabase Auth or Clerk. If the data already lives in Supabase, its auth rides along next to the rows it protects and costs nothing extra. Clerk is the pick when you want polished sign-in, organizations and SSO working in an afternoon. Rolling your own auth needs a reason you can say out loud, and there rarely is one at this stage.
Real time: Pusher, Ably, or Supabase Realtime. Chat, presence, live dashboards and collaborative cursors need a socket layer, and the managed ones cost nothing at prototype volume. Supabase Realtime is already there if that is your database. Pusher and Ably are the dedicated picks. And when the product is real time to its core, a socket server of your own on that persistent host is the honest answer.
AI: a layer, not a feature. Most new apps are AI apps somewhere: Claude, GPT or Gemini for text, agents and structured extraction, Replicate and fal for image and video models, ElevenLabs for voice, Suno for music. The integration pattern matters more than the vendor: API keys on your own accounts, responses streamed so the app feels alive, and per-call costs measured from day one, because model spend is the one line item that can outgrow hosting by an order of magnitude.
Money: Stripe on the web, RevenueCat for mobile subscriptions. Stripe for checkout, subscriptions and invoices. RevenueCat when app-store subscriptions enter, because reconciling Apple, Google and Stripe by hand is a full-time job nobody wants back.
Files and media: S3 or R2 for originals, Cloudinary when media is the product, Vercel Blob for the simple cases. Everything behind signed URLs, cheap and portable because the API is a standard. Cloudinary earns its keep the moment you are resizing, cropping and transcoding constantly instead of just storing.
Eyes: error tracking and an uptime check, from day one. An hour of setup buys you learning about bugs from a dashboard instead of a churned user. The single highest-leverage item on this page, and the one prototypes most often skip.
Later, when earned: Redis, then the heavy machinery. Redis enters when the same reads repeat at volume. Kafka, replicas, search engines and the rest wait for the measurements that justify them, in the order covered by from prototype to production. None of it belongs in an MVP.
The point of these choices is what does not happen when the product starts working. No rewrite, because Postgres and Next.js carry real load once indexed and cached. No migration, because everything already runs on your accounts. No platform ceiling, because there is no platform, only standard tools you own, which is the argument of the Lovable comparison in stack form. Traction upgrades this stack with a cache and some indexes. It does not replace it.
Because an MVP has exactly one job: find out if anyone wants the product. Every exotic choice adds a second experiment about whether the technology works, running silently under the first. Postgres, Next.js and Stripe have had their surprises found by millions of teams already. Save the novelty budget for the product.
Close to zero. The free tiers of a managed Postgres, hosting and email service comfortably cover a prototype and its first users, and the first paid tiers are tens of dollars a month. Cost at this stage is not the constraint. The constraint is judgment: choices that let the same stack carry real load later without a rewrite.
Because an app on someone else's accounts is a service you use, and an app on yours is property you own. Your hosting, your database, your domain, your Stripe. You can fire your developer, including us, and lose nothing. This is the sharpest difference between a built app and a platform app, and it costs nothing extra to do from day one.
When measurement says so, and mostly never. Redis earns its place when the same reads repeat at volume. Kafka when you have genuine event pipelines. Kubernetes usually never for a product this size. The order of operations at traction is covered in our prototype-to-production guide, and it starts with indexes and monitoring, not infrastructure.
These are our defaults, not our limits. The default build is Next.js on Vercel, Supabase Postgres, one Expo codebase for native iOS and Android, Stripe and RevenueCat, S3-compatible storage, whichever AI models the product calls for, and Render or Hetzner when something must run long. The bench behind the defaults is deep: Redis, Kafka, Elasticsearch, DynamoDB, Snowflake, Kubernetes, Three.js, each pulled in when a specific build earns it. Defaults keep an MVP cheap and fast. The bench is why the same team can also take it to scale.
Related: from prototype to production, what makes an app hard to build, and all articles.
A free 20 minute call. One week later it is live on these tools, on your accounts, with all the code yours.
Or see how the week works.