Shipping a SaaS MVP in weeks with Next.js + Convex
Most MVPs die in the gap between "looks done" and "actually works." The demo renders, the happy path clicks through, and then the first real user hits an empty state nobody designed, a webhook that never fired, or an auth edge case that locks them out. We've shipped enough of these to treat that gap as the actual product — so we sequence the build to close it fast.
Our default stack is Next.js on the App Router with Convex as the backend. Next gives us server components, edge-friendly rendering, and a single codebase for marketing pages and the authenticated app. Convex gives us a typed, reactive database where queries and mutations are just TypeScript functions — no separate API layer to scaffold, no GraphQL schema to babysit, and live-updating data out of the box. For a small team racing to first revenue, removing the API tier is the single biggest accelerator.
Week one is auth, data model, and a deployed skeleton. We wire up Clerk or Convex Auth, model the core entities, and push something to a preview URL the same week. It's deliberately ugly — the point is that the plumbing is real. From there we build in weekly vertical slices: a whole feature, end to end, demoed live every Friday. You see the product grow instead of waiting for a big reveal that lands three weeks late.
Billing is where most MVPs cut a corner they regret. We integrate Stripe early — usually by week three — because pricing assumptions shape the data model, and retrofitting metered usage or seat-based plans into a schema that wasn't built for it is its own small project. Getting a real checkout flow live early also forces the unglamorous questions: trials, proration, failed payments, and what a user actually sees when their card declines.
By week five or six you have a deployed app real customers can pay for: typed end to end, reactive, observable, and documented. It won't have every feature on the roadmap — that's the point. It has the spine, and the spine is solid, so the next ten features bolt on instead of forcing a rewrite. (Timelines here are typical for a focused single-product MVP; complex integrations or compliance work extend them.)
The trap to avoid is treating "MVP" as permission to ship something brittle. Fast and disposable are not the same thing. The whole reason we lean on Next and Convex is that the speed comes from removing ceremony, not from cutting corners you'll pay for at scale. Ship in weeks, but ship something you'd be happy to still be running a year from now.