Three SaaS companies hired us this year to ship 12-week MVPs from scratch. Different domains — one healthcare ops platform, one B2B procurement tool, one creator-economy analytics product. All three picked MongoDB + Express + React + Node, the MERN stack, as the foundation. All three shipped within budget, on schedule, with paying customers signing up in week 13.
The MERN stack has had its share of ‘is it dead yet’ takes over the last few years. Our short answer is no. It remains the most defensible 12-week MVP architecture in 2025 for the kind of work most early-stage SaaS founders need to do. Here is the actual breakdown from the three launches.
Why MERN, in 2025
The stack is not new. The reason it still wins is operational. Every piece in MERN has a deep talent pool — React developers, Node developers, MongoDB administrators are all common enough that staffing the next phase of the company is not a bottleneck. The hosting story is mature — Vercel for the front end, Railway or Render or AWS for the API, MongoDB Atlas for the database, all of which work out of the box for a small SaaS.
The alternative architectures we considered for these three projects:
- Next.js + Postgres + Prisma: faster to ship initially, but lock-in to the Vercel hosting model that the founders did not want for backend logic.
- Django + React: solid but the team had no Django experience and the founders did not want to staff for it.
- Rails + React: similar reasoning. The Rails developer market is healthy but smaller than the Node market.
- T3 stack: appealing for the type safety story, but the founders wanted MongoDB for flexible schema reasons.
MERN won on team-shape fit, not on technical superiority. That is usually how the architecture decision goes in the real world.
The 12-week timeline
The shape of every project was similar.
Weeks 1-2: Discovery and architecture. User flows mapped, data model designed, auth approach selected (Auth0 in two cases, Clerk in one), payment provider integrated (Stripe in all three), hosting and CI set up.
Weeks 3-4: Core data layer and API. Database schemas in MongoDB, Mongoose models, REST endpoints for the core entities, basic test suite. By the end of week 4 the API was complete enough to seed the front end.
Weeks 5-8: Front-end build. React app structure, authentication flow, the four to six core screens that the MVP needed. By the end of week 8 the application was usable end-to-end on a staging environment.
Weeks 9-10: Polish and integrations. Email service (Postmark in two cases, Resend in one), analytics (Mixpanel in two, Plausible in one), error tracking (Sentry in all three), customer support (Intercom in two, Crisp in one).
Weeks 11-12: Internal testing, security audit, payment flow validation, soft launch with first paying customer.
What we built and what we did not
The MVPs shipped with a deliberately narrow feature set. The list:
- User registration, email verification, password reset, single-org or multi-org account model
- Subscription billing with Stripe Checkout and a single pricing tier
- The two or three core workflows the customer was paying for
- Basic admin tools (user list, account-level overrides, refund handling)
- Email notifications for the critical flows
- A simple dashboard for the customer to see what they had done
The list we did not build:
- Multi-tier pricing — single tier on launch, more later
- SSO — typical SAML flows are not needed for week-1 customers; SSO came in month 4 on each project
- Audit logs — added in month 6 when a customer asked
- Reports and analytics — added piecemeal based on actual customer requests
- API for customer integrations — added in month 4 or 5 when a customer asked
- White labeling, custom domains, custom branding — added in month 5+
The discipline to not build these in the first 12 weeks is the discipline that makes the 12-week timeline work. Founders ask for them. Customers do not.
Where MongoDB earned its keep
The three SaaS products had three different reasons to use MongoDB.
The healthcare ops platform had a deeply nested data model — patients with treatment histories with embedded provider notes with embedded medication lists. The structure mapped naturally to MongoDB documents. The same data in Postgres would have been five tables with complex joins.
The B2B procurement tool had an evolving schema — every customer had slightly different fields on their orders, suppliers, and approval workflows. MongoDB’s flexible document model meant the engineering team did not have to run a migration every time a customer needed a new field.
The creator-economy analytics product ingested data from a dozen platforms (YouTube, Instagram, TikTok, Substack, others) with different shapes. MongoDB let us store the raw payloads from each platform without forcing them into a normalized schema.
For all three, Postgres would have worked, but MongoDB was a meaningfully better fit. The flexibility paid back in development velocity.
The Node API decisions
We standardized on a small set of libraries across the three projects:
- Express for the HTTP layer. It is plain and well-known. Not the newest. Not the fastest. The team knows it.
- Mongoose for the ORM. The validation and middleware story is the cleanest for the document-mapping pattern.
- Zod for request and environment validation.
- Jest for testing.
- TypeScript for type safety on both API and front end.
The choices are deliberately conservative. The point of an MVP architecture is to be boring enough that the team can ship features instead of debugging the framework.
The React front end
React with Vite for the build tooling, React Router for routing, TanStack Query for server state, Tailwind for styling, shadcn/ui for the component primitives. Roughly the same stack the rest of the industry is on this year.
The choice to not use Next.js on these projects was deliberate. For a SaaS product, the front end is an authenticated application. SSR is mostly unnecessary because the pages are not public, the bundle size is acceptable, and the deploy model is simpler with a static front end and a separate API. Next.js’s value proposition is highest for content sites and marketing sites, not for authenticated SaaS apps.
What the founders got at week 13
All three founders signed their first paying customers in the week after launch. The price points ranged from 199 dollars a month to 1,200 dollars a month. The early customer count by week 24 was between 8 and 25 across the three projects.
The architecture has held up. Two of the three projects are now past 100 customers and have not had to rebuild anything we shipped at MVP. The third is at 60 customers and starting to scale the API layer, which was the part we expected to scale first.
The takeaway
MERN is not the most fashionable stack in 2025. It is the stack with the broadest talent pool, the most mature operational story, and the cleanest path from MVP to product-market fit for the kind of work most early-stage SaaS founders need to do. For a 12-week MVP that has to support real paying customers from day one, it remains our default recommendation, and we expect it to remain so through at least the rest of the decade.