I spent six months building my first SaaS product. When I finally launched, I had a feature-complete system with microservices, event queues, and auto-scaling infrastructure. I also had exactly zero paying customers.
The problem wasn't the tech. It was that I'd built a palace before anyone asked for a room.
Since then, I've shipped three more SaaS products from Dhaka on bootstrap budgets between $20 and $100 total. The fastest one took five weeks from first commit to first dollar. The difference wasn't cutting corners—it was knowing which corners don't exist yet in an MVP.
If you're building your first SaaS or you've burned months on something that hasn't launched, this is the tech stack and timeline that works.
What Makes an MVP "Minimal"
An MVP isn't a bad version of your big idea. It's the smallest thing that proves people will pay for the outcome you're selling.
I start every project with this question: What's the one workflow this product needs to nail? Not three workflows, not the admin dashboard, not the analytics page. One.
For a project management tool, maybe it's creating and assigning tasks. For an email tool, it's sending a campaign. For my last SaaS, it was uploading a file and getting back a processed result. Everything else—collaboration features, API access, webhooks—came later, after people paid.
Here's the filter I use:
Must-have: The user can't complete the core job without it. If you remove this, the product doesn't work.
Nice-to-have: The user wants it, but they can still complete the core job without it. Defer.
Over-engineering: You think the user needs it because "real products have this," but you haven't proven demand yet. Delete.
The goal is to time-box your MVP to 4-8 weeks. Any longer and you're either building features users haven't asked for or you've picked a problem too complex for a bootstrap launch. Scope down or pivot.
Feature creep is the silent killer. I've watched founders add "just one more thing" for months, then launch to silence because the core value was buried under features no one needed. If you catch yourself saying "but real SaaS products have X," stop. Your job isn't to build a real SaaS product. It's to prove one person will pay for one outcome.
Tech Stack Decision Framework
Every article about SaaS tech stacks gives you a list of tools. What they don't give you is the framework for choosing between them.
Here's mine. I pick tools based on four factors:
1. My existing skills. If I already know Next.js, I'm not rewriting the whole app in SvelteKit just because someone on Twitter said it's faster. Speed to launch beats theoretical performance every time in an MVP.
2. Bootstrap budget. I need a stack that runs for under $50/month until I hit my first 10 paying customers. Managed services are great, but if they start at $99/month, they're not an MVP choice.
3. Scale target. Am I aiming for 100 users or 100,000? For an MVP, I'm always optimizing for the first 100. I'll refactor when revenue justifies the time.
4. Solo or team. If I'm the only developer, I want a monolith. If I'm working with a team, I might split frontend and backend. For MVPs, I default to monolith—it's faster to iterate.
Frontend: Next.js vs Remix vs SvelteKit
I use Next.js 14 (App Router) for almost everything. It's not the fastest framework, but it's the most productive for solo founders. You get server components, API routes, static generation, and a massive ecosystem of libraries and tutorials. When you hit a problem, someone's already written the Stack Overflow answer.
Remix is great if you're deep in the React ecosystem and want better data loading patterns. But for MVPs, the learning curve isn't worth it unless you're already fluent.
SvelteKit is fast and elegant. The bundle sizes are tiny. But the ecosystem is smaller. If you're choosing a framework for an MVP, pick the one where you'll spend less time debugging obscure issues and more time shipping features.
Backend: Monolith vs API-First
For MVPs, I ship monoliths. Same codebase, same deployment, fewer moving parts.
The API-first pattern (separate backend + frontend repos) makes sense when you're building mobile apps alongside web, or when you have separate teams. For a solo founder building a web app, it's over-engineering.
Next.js lets me colocate my frontend and backend logic in one project. I write server actions or API routes in the same file as my components. I deploy once. That's the speed I need.
Database: Postgres vs MySQL vs Firebase
I use Postgres for everything. It's open-source, rock-solid, and handles relational data, JSON blobs, full-text search, and queues all in one place.
MySQL is fine, but Postgres has better JSON support and a richer feature set. Unless you're already running MySQL infrastructure, there's no reason to pick it in 2026.
Firebase (Firestore) is fast to set up, but you'll hit scaling limits and cost explosions faster than you expect. The real-time features are great if your product needs real-time (like a chat app). For most SaaS products—billing tools, content platforms, dashboards—you don't need it, and you'll regret the vendor lock-in when you outgrow it.
For Postgres hosting: Neon's free tier gives you 3GB of storage, which is plenty for an MVP. If you want full control and you're comfortable with SSH, you can self-host Postgres on a $5 VPS.
Auth: NextAuth.js vs Supabase vs Clerk
I use NextAuth.js (now Auth.js). It's free, open-source, and integrates directly into Next.js. You control the user table, you own the session logic, and there's no per-user pricing.
Supabase gives you auth + database + storage in one package. It's a great choice if you're using their Postgres hosting and want everything under one service. But for me, I like separating concerns. I'd rather own my auth logic than depend on a managed service for something this foundational.
Clerk is polished and handles edge cases beautifully—passkeys, social logins, MFA. But it starts at $25/month for 10,000 monthly active users. For a bootstrap MVP, that's a hard sell when free alternatives exist.
Payments: Stripe vs Paddle
Stripe is the default. The API is well-documented, the webhooks are reliable, and almost every SaaS tutorial assumes you're using Stripe. Use Stripe Checkout for the MVP—it's hosted, PCI-compliant, and you don't have to build a payment form.
Paddle is a merchant of record, which means they handle tax compliance globally. That's valuable when you scale, but it's overkill for an MVP. Stick with Stripe, handle tax manually for your first few customers, and switch to Paddle later if international sales become a bottleneck.
Hosting: Vercel vs VPS vs Railway
For Next.js apps, Vercel is the fastest path to deployment. The Next.js deployment comparison — Vercel vs VPS vs Docker covers the full setup in detail. The free tier is generous: unlimited deployments, 100GB bandwidth, serverless functions. You push to GitHub, Vercel builds and deploys automatically. Zero config.
If you're comfortable with Docker and Nginx, a $5 DigitalOcean or Hetzner VPS gives you full control and predictable costs. I run most of my SaaS products this way once they're past the MVP stage. But for launch speed, Vercel wins.
Railway is a middle ground—easier than managing your own VPS, more flexible than Vercel. I've used it for apps that need long-running background jobs (which don't fit Vercel's serverless model). But their free tier is time-limited, so you'll need to plan for paid hosting within a few weeks.
The Bootstrap Stack (Recommended for Solo Founders)
Here's the exact stack I used for my last three SaaS launches:
- Next.js 14 (App Router)
- Postgres (Neon free tier, or self-hosted on a $5 VPS)
- Prisma ORM (type-safe database queries, migrations built-in)
- NextAuth.js (email/password + Google OAuth)
- Stripe Checkout (hosted payment pages, webhook handling)
- Tailwind CSS + shadcn/ui (fast styling, accessible components)
- Deployment: Vercel (free tier) or $5 VPS with Docker
Total monthly cost: $0 (Vercel free tier + Neon free tier) to $50 (VPS + domain + email service).
This stack gets you:
- User signup and login
- Subscription billing (monthly/annual plans)
- Webhook handling for payment events
- Responsive UI that doesn't look like a 2015 Bootstrap template
- Type-safe end-to-end (TypeScript + Prisma)
Starter Template Overview
I don't start from scratch anymore. I maintain a private template with these flows pre-built:
Auth flows: Signup, login, password reset (email-based), Google OAuth fallback. I store users in Postgres with NextAuth's database adapter.
Subscription management: Stripe Checkout links for each plan, webhook handler for checkout.session.completed and invoice.payment_succeeded events. I store subscription status (active, cancelled, past_due) in the database and check it in middleware before rendering protected pages.
Email: I use Resend (100 emails/day free) for transactional emails—welcome emails, password resets, payment receipts. Postmark is another solid choice if you need higher volume.
User dashboard: A simple settings page where users can update their email, view their plan, and manage their subscription (using Stripe's customer portal).
The template is about 1,000 lines of code. It's not open-source yet, but it saves me a week on every new project.
MVP Development Timeline
Here's how I structure an 8-week MVP build. I've done this three times now, and the pattern holds.
Week 1-2: Setup, Auth, Database Schema
- Initialize the Next.js project, set up Prisma, connect to Postgres
- Build auth (signup, login, password reset)
- Design the database schema for the core feature
- Deploy to Vercel or staging VPS
- Set up environment variables (DATABASE_URL, NEXTAUTH_SECRET, STRIPE_SECRET_KEY)
At the end of week 2, I can sign up, log in, and see an empty dashboard. That's it. No features yet, but the foundation is solid.
Week 3-4: Core Feature MVP
This is where I build the one thing that defines the product. For my last SaaS (a document processing tool), it was the upload form, the background job, and the result display. Two weeks, 600 lines of code.
I don't build admin dashboards, analytics, or API access here. Just the core loop: input → process → output.
Week 5-6: Payment Integration, User Dashboard
- Set up Stripe products (one-time or subscription plans)
- Build the pricing page with Checkout links
- Implement the webhook handler to update subscription status in the database
- Add subscription gating: free users see a paywall, paying users see the full feature
- Build the account settings page (view plan, update email, cancel subscription)
This is the hardest part. Webhooks are finicky. Stripe's test mode behaves differently than live mode. I always budget extra time here because something will break.
Week 7-8: Polish, Testing, Soft Launch
- Fix obvious bugs (broken links, bad error messages, mobile layout issues)
- Write a one-page landing page explaining the product
- Set up basic analytics (I use Plausible or PostHog)
- Set up error monitoring (Sentry free tier)
- Test the payment flow end-to-end in Stripe test mode, then live mode with a $1 test purchase
- Soft launch: share the link with 5-10 people (Twitter, Indie Hackers, a Slack group)
By the end of week 8, the product is live, people can pay, and I'm watching for the first conversion.
Real Example: My last SaaS took exactly this timeline. I shipped in 7 weeks because I skipped the subscription model—it was one-time payments only. I added subscriptions in month 2 after I had 15 paying customers.
Common MVP Mistakes to Avoid
I've made all of these mistakes. You don't have to.
Over-engineering the architecture. Microservices, message queues, Redis caches—these are solutions to scaling problems you don't have yet. For your first 100 users, a monolith on a single server will handle the load. I've run SaaS products serving 500 users on a $5 VPS. Don't prematurely optimize.
Building features before validation. You don't need a mobile app, an API, webhooks for third-party integrations, or a Chrome extension in your MVP. You need one person to pay you. Build that first. Add features after you have revenue.
Ignoring performance until it's too late. I'm not saying ship a slow product. But if you're spending week 4 optimizing database queries that run in 50ms instead of 20ms, you're over-optimizing. Get the feature working first, then measure, then optimize the slow parts. When you do need to go deeper, PostgreSQL optimization for Node.js covers indexing strategies that make a real difference.
Skipping analytics and logging. If you don't know which pages users visit, where they drop off, or which errors they hit, you're flying blind. Install Plausible (or PostHog, or even Google Analytics) on day one. Install Sentry for error tracking. You can't fix what you can't see.
Complex deployment setups. I've seen founders spend two weeks setting up Kubernetes for an MVP. Unless you're deploying 50 microservices, you don't need orchestration. Vercel handles deployment for you. A VPS with Docker Compose handles the rest. Save the DevOps deep dive for month 12, not week 1.
Launch Checklist
Before I call an MVP "done," I run through this list:
Pre-launch QA:
- Sign up and log in work on mobile and desktop
- Password reset email arrives (check spam folder)
- Core feature works end-to-end (I test it 5 times with different inputs)
- Payment flow completes successfully in Stripe test mode
- Payment flow completes successfully in Stripe live mode (I make a real $1 purchase)
- Webhook fires and updates the database correctly
- Paid users see the full feature, free users see the paywall
Analytics and Monitoring:
- Plausible or PostHog tracking script installed
- Sentry error monitoring active (check by triggering a test error)
- Stripe dashboard webhooks configured and showing "succeeded" status
Content:
- Landing page explains what the product does in one sentence
- Pricing page lists plans clearly (what's included, what's not)
- Basic onboarding flow (even if it's just a tooltip: "Click here to start")
Legal Basics:
- Terms of Service page (I use a free template from Termly or Avodocs, customized)
- Privacy Policy page (same)
- Link to both from the footer
I'm not a lawyer, so I keep the legal stuff simple for the MVP. If the product gets traction, I hire someone to review it properly.
Post-Launch: What to Build Next
You launched. Now what?
Watch these metrics:
- Signups per day. Are people even finding the landing page?
- Activation rate. What percentage of signups use the core feature?
- Conversion rate. What percentage of users who use the feature end up paying?
If signups are low, your problem is distribution (SEO, Twitter, Indie Hackers, word-of-mouth). If activation is low, your onboarding is confusing. If conversion is low, your pricing is wrong or the feature isn't valuable enough.
Set up customer feedback loops. I email every new user personally (yes, manually) and ask: "What problem were you trying to solve?" Their answers tell me what to build next.
Prioritize features by frequency of request. If three people ask for the same thing, it goes on the roadmap. If one person asks for something niche, I note it but don't build it yet.
When to refactor vs ship. If the codebase is messy but the product is growing, ship. You can refactor later. If the codebase is messy and you're spending hours debugging the same issue over and over, refactor now. The rule: refactor when the mess slows you down. Not before.
I've refactored too early and regretted it (wasted a week cleaning code for a feature I deleted the next month). I've also refactored too late and regretted it (spent three days fixing a bug that wouldn't exist if I'd cleaned up the database schema earlier). You learn the timing by doing it wrong a few times.
Building a SaaS MVP is less about the tech stack and more about knowing what not to build. Use boring, proven tools. Time-box the work. Ship something ugly that works. Then iterate based on what people actually pay for.
I've launched SaaS products from Dhaka with bootstrap budgets under $50. You can too.
Tested environment: Next.js 14, Postgres 16, Node.js 20 LTS