Micro-SaaS in 3 Weeks: Where to Cut Corners and Where to Build for Scale

A 3-week MVP isn't a smaller version of the final product — it's a different product with a different goal: proving a business hypothesis before you invest in scaling it. Every decision comes down to one question: does this help us find out if people want this, or is it work we're doing because it feels responsible?

Corners worth cutting

• A custom design system. Use shadcn/ui or a plain Tailwind component set as-is. Nobody churns because your buttons aren't bespoke.
• Multi-tenant architecture from day one. Single-tenant with a clear upgrade path is faster to build and easier to reason about while you still don't know if you have paying customers.
• An admin panel. Query the database directly or use a generic admin tool for the first few weeks of support and onboarding.
• Comprehensive test coverage. Cover the payment flow and anything destructive; skip exhaustive unit tests for UI you might delete next sprint.

Foundations worth laying now

Some decisions are expensive to reverse later, and cutting corners on them creates real technical debt instead of acceptable MVP debt:

• Authentication and authorization, even if simple — retrofitting proper session handling after real user data exists is painful and risky
• A data model that reflects your actual domain, not just what's convenient to query today — schema migrations under live data are a different kind of expensive
• Payments wired to a real provider, not a stub — you need to validate willingness to pay, not just willingness to sign up
• A deployment pipeline that ships in minutes, so the cost of shipping a fix stays lower than the cost of not fixing it

The stack we default to

For a genuinely fast MVP: Nuxt or Next for the frontend/SSR layer, Tailwind with shadcn/ui (or Nuxt UI, if you're already in the Vue ecosystem) for the component layer, a managed Postgres instance instead of self-hosted infrastructure, and a managed auth provider instead of rolling your own. None of these choices are permanent — they're chosen because they get you to a testable product fastest, and every one of them is replaceable later without a full rewrite.

What "done" means for a 3-week MVP

Done means a real user can complete the core flow, pay if the product requires payment, and give you feedback you can act on — not that every edge case is handled or every screen is polished. If you're spending week three refining empty states instead of talking to the first users who signed up in week one, the scope decision already went wrong.

Takeaway

Speed in an MVP doesn't come from working faster — it comes from correctly identifying which 20% of the product actually needs to exist to answer your hypothesis, and having the discipline to leave the other 80% unbuilt until you know it's worth building.