Choose the most widely used technology that your builders are already fluent in, keep everything in one application on one relational database, rent every component that is not your product (login, payments, email, file storage), and host it all in accounts you own. That answer covers the large majority of MVPs. The rest of this guide explains the reasoning and the exceptions.
What an MVP stack has to do
A stack for a first release has two jobs. It has to get a small team to launch quickly, and it has to avoid forcing a rewrite if the product works. It does not have to handle a million users, impress engineers on social media, or be the stack you would choose for year five.
Selection criteria
1. Team fluency
The fastest stack is the one your builders have shipped with before. A team experienced in Rails will beat the same team learning something newer, every time, at MVP scale. If a vendor proposes a technology they have not released a product with, you are funding their education.
2. Hiring pool
If the product works, someone else will maintain this code: a first engineering hire, a new agency, a CTO. JavaScript and TypeScript, Python, PHP, Ruby, Java and C# all have deep talent pools in every major market. A niche language or framework narrows your options and raises the price of every future hire.
3. Speed to a working product
Look for a mature ecosystem: libraries for the dull parts, good documentation, answers to common errors already online. One language across front end and back end (TypeScript is the usual choice) lets a small team move between layers without handoffs.
4. Hosting and running cost
At MVP scale the bill should be tens to low hundreds of dollars a month. Be wary of architectures that need many always-on services, and of usage-priced platforms whose costs you cannot predict. Read the pricing page for the tier after the free one.
5. Avoiding a rewrite
Three habits matter more than the framework: a relational database with a considered data model, a clear separation between the interface and the business logic, and standard deployment that any engineer can reproduce from the repository's documentation.
6. Portability and ownership
Can you export your data? Can the application run somewhere else if a provider changes pricing or shuts down? Open-source frameworks and standard PostgreSQL score well. Proprietary platforms that hold both your logic and your data score poorly.
Recommended defaults by product type
These are starting points, not rules. An equivalent mainstream framework your team knows well is just as valid.
| Product type | Front end | Backend and data | Rent, do not build | Notes |
|---|---|---|---|---|
| Web SaaS | React with Next.js, TypeScript | Node.js, PostgreSQL, one application | Auth, subscription billing, transactional email, error monitoring | Decide the tenancy model early. See the SaaS architecture and stack guide. |
| Mobile app | React Native with Expo, or Capacitor for web-first products; Flutter is a credible alternative | Node.js and PostgreSQL, or a backend platform such as Supabase or Firebase; small web admin panel | Auth, push delivery, store subscription management, crash reporting | One codebase for iOS and Android. Go fully native only for a specific reason. |
| Marketplace or booking platform | Responsive web app first; mobile app for the high-frequency side only if needed | Node.js, PostgreSQL; database search before a dedicated search service | Split payments and payouts, identity checks, messaging or email relay, maps | Payouts and seller onboarding are the hardest part. Use the payment provider's marketplace product. |
| AI product | Web app as above | Node.js or Python, PostgreSQL (with a vector extension if retrieval is needed), a background job queue | Hosted model APIs, document parsing, speech services | Do not train models for an MVP. Keep the model provider behind a thin interface so it can be swapped. |
Each of these has a deeper page. For the web layer see React and Next.js development; for the server side, Node.js development; for apps, React Native development. The mobile decision itself is covered in native vs cross-platform and Flutter vs React Native, and the AI choices in the LLM integration guide.
Where BBR stands. BBR builds with TypeScript, React, Next.js, Node.js, PostgreSQL, React Native and Capacitor. We do not build with Flutter. It appears in the table because it is a sound choice, and a guide that listed only our own tools would not be much of a guide.
What to buy instead of build
Every hour spent on a component users never notice is an hour not spent on the product. These are solved problems with mature providers, and several of them carry security or compliance risk if built in-house.
| Component | Why not build it | Typical options |
|---|---|---|
| Authentication | Password storage, resets, email verification, social login, multi-factor and session security are easy to get subtly wrong | Supabase Auth, Firebase Authentication, Auth0, Clerk, or a well-maintained open-source library |
| Payments and subscriptions | Handling card data yourself brings PCI obligations. Providers also cover invoices, tax calculation, retries and customer self-service. | Stripe, Paddle, Lemon Squeezy; for marketplaces, the provider's split-payment product |
| In-app purchases | The app stores generally require their own billing for digital goods sold inside an app, with regional exceptions that keep changing | StoreKit and Google Play Billing, often through a wrapper such as RevenueCat |
| Transactional email | Deliverability is a specialty. Self-run mail servers land in spam. | Postmark, Resend, SendGrid, Amazon SES |
| SMS and push | Carrier rules and device tokens are tedious and change often | Twilio and similar for SMS; Firebase Cloud Messaging, Expo or OneSignal for push |
| File and image storage | Cheap, durable and already solved | S3-compatible object storage, Cloudflare R2, Supabase Storage |
| Analytics and error monitoring | You need them on launch day, not after | PostHog, Mixpanel or Amplitude; Sentry for errors |
| Search and maps | Start with database queries. Add a search service only when users feel the limit. | PostgreSQL full-text search first; Algolia, Typesense or Meilisearch later; Google Maps or Mapbox |
What you should build yourself
The core workflow, the data model, and anything that is the reason a customer would choose you. If your differentiator is the matching logic, do not outsource it to a plugin. If it is not the login screen, do not hand-craft the login screen.
Two cautions when renting. Open every third-party account in your company's name, with the builders invited as members, so that nothing has to be transferred later. And check the pricing at ten times your expected usage, so that success does not arrive as an unpleasant invoice.
No-code and low-code: when it is the right call
No-code tools are a legitimate way to build a first version, and sometimes the best one.
Good fit
- Marketing sites, waitlists and content: site builders such as Webflow or Framer
- Internal tools and simple client portals over a spreadsheet or Airtable base: Softr, Glide, Retool
- Workflow automation between existing tools: Zapier, Make, n8n
- Web apps that are mostly forms, lists and simple logic: Bubble and similar
- Any situation where demand is unproven, money is tight and you can build it yourself in a few weeks
The ceiling
- Custom logic. Anything beyond the platform's model turns into workarounds that are harder to maintain than code.
- Native mobile features. Background tasks, offline use, device sensors and polished native interaction are limited or absent.
- Performance and volume. Large datasets and heavy concurrent use expose limits you cannot tune.
- Pricing. Per-user, per-record or per-workload pricing can outgrow what equivalent hosting would cost.
- Lock-in. Several platforms, Bubble being the best known, do not let you export the application as source code. You can export your data. The application logic has to be rebuilt.
- Due diligence. Some investors and enterprise buyers will ask what happens if the platform changes terms. Have an answer.
The sensible way to use no-code is with open eyes: it buys you evidence cheaply, and if the product works you will rebuild it with revenue or funding behind you. Keep your data model tidy and exportable so that rebuild is a project and not a rescue. Low-code backends such as Supabase and Firebase are a different case. They are developer tools that remove backend work while your own front-end code stays portable, and they are a reasonable foundation for a custom MVP.
Stack mistakes that cost founders the most
- Choosing by trend. New frameworks have thin documentation, few experienced engineers and breaking changes. Let someone else find the problems.
- Microservices from the start. A distributed system multiplies deployment, monitoring and debugging work for no user benefit at this size.
- A document database for relational data. Users, orders, bookings and payments are relational. Starting in a schemaless store usually ends in a migration.
- Fully native iOS and Android apps by default. Two codebases double the build and every future change. Justify it with a specific requirement.
- A vendor's proprietary framework or CMS. If only one company can maintain it, you are locked in regardless of what the contract says about ownership.
- Letting a single freelancer's preference decide. Ask whether another engineer could take this over in a week. If the honest answer is no, reconsider.
- No staging environment, no backups, no deployment notes. These are part of the stack. They cost a day or two at the start and far more when missing.
- Accounts in the developer's name. Cloud, domain, app store and payment accounts belong to your company from day one.
Questions to ask whoever proposes your stack
- Have you released a product with this stack before?
- Why this choice for this product, in two sentences a non-engineer can follow?
- What will hosting and third-party services cost per month at launch, and at ten times the usage?
- Which parts are rented, and what is the exit path for each?
- How hard is it to hire for this in my market?
- What would make you choose something different?
Stack choice is one step in a longer sequence. The step-by-step MVP guide covers what comes before it, and BBR's default choices for client projects are listed on the MVP development page.