Shipping an MVP in 30 Days: Our Playbook

Why 30 days

The natural impulse when scoping a product is to keep adding. Another user type, another reporting view, another integration. Left unchecked, "two months" becomes five, and five becomes a product nobody has shipped or validated yet.

30 days is short enough to force opinionated decisions early — but not so short that you're cutting the things that actually matter. At 60 days, scope creep is almost guaranteed: there's enough calendar space to say yes to things you should be saying no to. At two weeks, you're not building software; you're building a mockup with a database. At 30, you have no room for second-guessing the scope, and that constraint is the point.

The math is simple. If a feature takes more than three days to build in week two, it's a week-three problem. If it's still a problem in week three, it goes on the post-launch list. Every decision comes back to: does this have to be in the first version for the product to function? If the honest answer is no, it waits. This discipline compounds. By the time you get to week four, you're polishing a focused thing rather than half-assembling a sprawling one.

---

Week 1: Discover and decide

The first week is entirely about removing ambiguity before a line of code is written.

We run two or three focused interviews with the founder — not discovery calls, actual structured conversations. We want to understand who the first ten users are, what they're doing today without this product, and where the friction is. We're looking for the single happy path: the one sequence of actions that a user completes from landing to core value. Not five paths. One.

Scope decisions happen here. We go through every feature on the initial list and ask: what breaks if this isn't in the first version? Anything that doesn't have a clear answer to that question gets cut. Typical casualties are admin panels, multi-user roles, custom reporting, and onboarding flows that aren't strictly necessary to reach value.

Tech stack is chosen at the end of week one based on three questions: what does the team ship fastest in, what does the problem actually require, and what won't create migration debt in six months. We default to Next.js, Postgres, Prisma, and Tailwind because they're boring and productive. The stack only deviates when the problem genuinely demands it.

End of week 1: a written spec (one document, not a Notion maze), an agreed list of what's in and what's out, a chosen tech stack, and a fixed launch date. Everyone signs off before week two starts.

---

Week 2: Design and set up

Week two runs two tracks in parallel: design and infrastructure.

On the design side, we build flows and wireframes — grayscale, no visual polish yet. The goal is to make every screen decision concrete before it's built. Where does the user land after signup? What happens when the main action fails? What does the empty state say? Wireframes answer these before they become code-time debates. We use Figma; the fidelity is low-fi enough that changes are cheap.

On the infrastructure side, the repo is created, CI is configured, environments are set up (local, preview, production), and the database schema is drafted. Auth scaffolding goes in — we use Clerk for most projects because session handling, magic links, and OAuth take time to get right and wrong auth is not recoverable without user trust damage. The schema is reviewed against the spec; any columns that belong to a cut feature don't get added.

A CI matrix that covers type checking, linting, and tests runs on every pull request from day one:

# .github/workflows/ci.yml (excerpt)
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - run: pnpm install --frozen-lockfile
      - run: pnpm typecheck
      - run: pnpm lint
      - run: pnpm test

By Friday of week two, a deploy preview exists — real URL, real database, placeholder pages showing navigation and layout. It looks like nothing. It proves the infrastructure works.

End of week 2: clickable wireframe approved, deploy preview live, schema committed, auth wired.

---

Week 3: Build the spine

Week three is the hardest and the most important. The goal is a single thing: the happy path works end-to-end in real code.

"Works" means a real user can open the app, complete the core action, and reach the outcome the product is supposed to deliver — even if the UI is rough, edge cases are unhandled, and the visual design is placeholder. The happy path running in production is the proof of concept that matters. A Figma prototype running in a browser is not the same thing.

We send the founder a short Slack update every day. Not a status report — a Loom or screenshot showing what's different from yesterday. Founders who can see progress stay engaged; founders who get weekly summaries lose confidence. On Wednesday we run a mid-week demo where the founder actually uses the build themselves in a shared screen. Not a walkthrough — they drive. This surfaces wrong assumptions before they're baked into two more days of code.

By end of week three, the spine is in. The happy path runs. There are rough edges everywhere. That's correct.

---

Week 4: Ship and polish

Week four is execution under time pressure, which is exactly what it should feel like.

The visual design pass happens now — not before. We apply the design system (shadcn/ui components, typography, spacing, color), use real copy and content, and handle the most common edge cases: empty states, loading states, error states on user-facing paths. We don't try to make every edge case perfect; we make sure none of them produce a blank screen or a stack trace.

Real auth is confirmed working (not just the happy path — also session expiry, failed login, logout). Payment flow gets wired with Stripe test mode first; a founder can watch a test payment hit their Stripe dashboard before launch. Monitoring goes in before launch, not after:

// sentry.client.config.ts
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 0.2,
});

Uptime monitoring is configured (Better Uptime or Checkly — two minutes of setup). Error alerting is live. The domain is pointing at production. SSL is on.

Public launch happens Friday. Not "soft launch." Not "we're going to invite a few people." The thing is live and the founder tells people about it.

---

What we always cut

These features are absent from every MVP we ship. Not because they're unimportant in general — because they're not necessary for version one.

Admin panel. Use your database GUI (TablePlus, Postico, Drizzle Studio) to manage data in the first month. Building a custom admin interface takes three to five days and serves exactly one person at launch.

Role-based permissions. Almost every early product has one user type. Multi-role systems are correctly designed once you know the roles from real usage, not from speculation.

Custom design system. shadcn/ui gives you a production-quality component library in an afternoon. Building a custom one from scratch is a month of work that serves your brand preferences, not your users.

Analytics dashboards. Wire up Posthog or Mixpanel to capture raw events from day one. Build the dashboard UI when you know which metrics you actually care about, six weeks from now.

Email templates beyond transactional. Transactional emails (confirmation, receipt, password reset) go in. Marketing sequences, drip campaigns, and digest emails do not. They require product insight you don't have yet.

Internationalisation. Ship in one language. Add i18n when you have users who need a different one.

---

What we never cut

These are non-negotiable. Cutting them produces a product that fails in ways that damage trust and are expensive to fix after launch.

Auth that actually works. Sessions must expire correctly, refresh correctly, and log out correctly. Half-baked auth means data leaks between users, users getting logged out mid-flow, and security incidents. We use Clerk rather than rolling our own.

Payment flow with real test mode. If your product charges money, the payment path must be exercised in Stripe test mode before launch. Not mocked. Not faked. Actually hitting Stripe's test API so the founder can verify the money moves.

Error handling on user-facing paths. Every form submission, every API call on the happy path must have a visible error state. A spinner that never resolves and a blank page that appears after a failed action both destroy trust faster than any missing feature.

Basic monitoring. Sentry for errors, an uptime check for the domain. If the site goes down at 2am, the founder should find out from their phone, not from a user email the next morning.

Mobile-responsive layout. Not beautiful on mobile. Functional on mobile. A signup flow that breaks on an iPhone 13 loses real users from day one. shadcn/ui components are responsive by default; it costs almost nothing to preserve that.

SSL and a sane domain. No amazonaws.com URLs in the launch announcement. SSL is table stakes; a missing padlock icon is a support ticket from every early user.

---

Closing

30 days isn't a stunt. It's a discipline.

The constraint works because it makes the cost of scope visible immediately. When everything has to fit in four weeks, the right trade-offs surface in the first conversation instead of the fourth week. Founders who have gone through this process consistently say the same thing: the month forced them to figure out what the product actually was, rather than what they hoped it might be.

At Reveronix, we use this rhythm because it produces real outcomes for early-stage founders — not polished prototypes, not proof-of-concepts, but working software with real users and real feedback at the end of month one. The next iteration is better because the first one shipped.