Producto · 10 min

MVP in 90 days: what to include and what to leave out

The difference between a defensible MVP and an eternal prototype comes down to eight specific decisions. Here they are.

"MVP" means different things in different companies. For some founders it is "a landing page with a Calendly and a Notion". For others it is "the commercial product, but ugly". The useful definition is in the middle: an MVP is the smallest version of the product that can operate in production without breaking the team. It is not a demo, it is not a prototype, it is product.

What ALWAYS goes into a 90-day MVP

  1. Authentication with roles (minimum 2). Owner and member is enough to start. Without this you cannot operate with real clients.
  2. Real billing, not fake billing. Stripe, Mercado Pago or whatever applies. "We will charge manually at first" ruins the most important metric: do people pay?
  3. Internal admin panel. For support and debugging. Not optional. It saves 80% of tickets in month 1.
  4. Logging and errors in Sentry (or equivalent). Without this, you do not know what breaks until a user writes to you.
  5. Working CI/CD. Deploy with git push or a button. Without this, every release is a stressful event.
  6. Complete onboarding. If a new user cannot reach the first "aha moment" alone, the rest of the product does not matter.
  7. Terms, privacy policy and legal notice. Generated from a serious template, not copied from Google.
  8. Basic metrics. PostHog or Plausible. How many users, month-2 retention, paid vs free.

What NEVER goes into a 90-day MVP

  1. Internationalization. Launch in one language. Add languages when you have traction.
  2. Sophisticated multi-tenant architecture (accounts -> workspaces -> projects -> granular roles). 1 account = 1 organization at first.
  3. Native mobile app. If your product is web, responsive web is enough. Mobile-first only if usage is 80%+ mobile.
  4. Push notifications. Transactional emails yes; push only once you reach the commercial product.
  5. Enterprise SSO. SAML, SCIM. You do not need them until an enterprise customer asks.
  6. Full event auditing. Simple logs yes; SIEM, no.
  7. Public API. Until 3 customers ask for it, do not build it.
  8. Discount and coupon system. Start with one price. Promotions can be "manual" at first.
  9. Dark mode. No, seriously. Not a priority.
  10. "Small UX improvements" the founder wants now. Make a list and prioritize after launch.

Time budget (honest 90 days)

WeeksFocusExpected output
1-2Discovery + architectureADRs, data model, prototypes of critical screens
3-4Infra + auth + billing setupLogin, roles, Stripe, staging deploy
5-8Core functionalityThe 3-5 things the user does every day
9-10Onboarding + admin + emailsEnd-to-end flow from signup to first value
11Closed beta with 5-15 real usersBugs discovered in real use
12Critical fixes + launchProduction with paying users

Minimum team for real 90 days

  • 1 dedicated product manager / founder. If the founder is not > 50% on the project, it will not happen.
  • 1 tech lead / senior full-stack dev. Makes architecture decisions and writes critical code.
  • 1 semi-senior dev. Executes features and does basic code review.
  • 1 product designer (50% time). Designs screens and the base system, does not perfect everything.
  • Part-time QA (weeks 9-12). Regression testing before launch.

With less team, the timeline stretches to 4-5 months (typical). With more team, you do not accelerate proportionally; coordination eats the gains after 5 people.

3 anti-patterns that kill MVPs

  1. "We will do it in microservices from the beginning." Modular monolith. Break into microservices when you have a real scaling problem, months after launch.
  2. "Since we are here, let's also add X." No. X comes later. If X is critical, it was V1, not MVP.
  3. "Let's wait until everything is perfect to launch." Launch ugly and functional before beautiful and empty. 5 real users are worth more than 10,000 polished pixels.

What to measure after launch

  • Activation rate: % of signups that reach first value in the first 7 days.
  • Month-2 retention: % of active users who return in month 2. > 25% = good, > 40% = excellent.
  • Paid conversion: % of signups who pay within 14 days. It varies by category, but < 2% = suspicious, > 8% = good.
  • Time-to-value: how long a new signup takes to perform the first meaningful action. Aim for < 5 minutes.

What if I need complex feature X to validate?

You probably do not. Wizard of Oz: do manually what the product will eventually automate. If 5 users pay for that manual service, you validate the model without building anything.

What happens if people ask for features during the MVP?

Keep a public "after MVP" list in Notion or Linear. Every new feature goes there, not into the current sprint. It only moves into the sprint if the MVP becomes indefensible without it.

How much does a 90-day MVP cost?

With a senior LATAM agency: US$28-45k. With a well-assembled internal team (without admin overhead): US$22-35k. With one senior freelancer: US$15-22k but the realistic timeline moves to 110-140 days.

What we recommend

Write the MVP in one paragraph. If you cannot explain what it does and for whom in 3 sentences, you are not ready to build it yet. Then write the "what is NOT included" list before the "what IS included" list; that is the list that breaks most often during the project and the one most worth defending.

And when you are in week 7 and someone says "since we are here, let's add X", repeat out loud: "X goes to v1, not to MVP". The MVP that ships in 90 days is worth more than the perfect product that ships in 270.

Want this applied to your company?

Book a discovery call →