How much does an MVP cost?

Depends on complexity. Simple webapp: R$ 8,000 to R$ 20,000. Full webapp: R$ 20,000 to R$ 50,000. SaaS MVP with billing: R$ 25,000 to R$ 60,000. Timeline: 4 to 16 weeks.

How long does it take to build an MVP?

With the React + Supabase + TypeScript stack, a functional MVP is ready in 4 to 8 weeks. Week 1: auth and structure. Weeks 2-3: core flow. Weeks 4-5: integrations. Week 6: testing and deploy.

Why not build the complete product right away?

Because you don't know if the idea works until someone uses it. I've seen a R$ 200k project that took 8 months and discovered in the first month that the market wanted something different. A R$ 25k MVP validates the hypothesis in 3 weeks and evolves with real data.

MVP: how to build a web product from zero to deploy

Q: What is an MVP?

MVP (Minimum Viable Product) is the leanest version of a system that solves the core problem and lets you validate whether the business works with real users. It's not a prototype or wireframe — it's software running in production.

What an MVP is and what it isn’t

MVP stands for Minimum Viable Product. The leanest version of your system that solves the core problem and lets you validate whether the business works with real users.

What an MVP is not: a Figma prototype. Not a wireframe. Not “let’s build everything and launch all at once.” It’s working software in production, with real people using it, generating real data that informs the next decisions.

The most common mistake: treating an MVP as a “bad version of the final product.” It’s not. It’s the version that gives you information fastest. A well-built MVP has code quality, security, and usability. What it doesn’t have is unnecessary scope.

Another frequent misconception: thinking MVPs are only for startups. They’re not. An established company that wants to test a new product, a new vertical, or a new digital channel benefits from the same process. The reasoning is identical: spend little to learn fast, and only scale after confirming it works.

Why build an MVP before the full product

Because you don’t know if your idea works until someone uses it.

That sounds obvious when I put it that way, but in practice most projects I receive start the other way around. The entrepreneur shows up with 40 screens designed, 15 integrations listed, and 8 user profiles mapped out. They want everything working before showing it to anyone.

The problem: I’ve seen a R$200k project that took 8 months to launch and discovered in the first month of operation that the market wanted something different. Those 8 months of development turned into 8 months of waste. And I’ve seen a R$25k MVP that validated the hypothesis in 3 weeks and evolved from real user feedback.

The MVP isn’t the worse version. It’s the version that answers the question “does this work?” before you invest R$200k on the wrong answer.

There’s a positive side effect that few people mention: the MVP forces clarity. When you have a limited budget and a tight deadline, you have to decide what actually matters. That constraint eliminates “nice to have” features and leaves only what actually solves the problem. Many products end up better precisely because they were forced to be simple in the first version.

The process I follow

1. Define the core problem

Before thinking about features, screens, or technology: what problem does the system solve? For whom? One sentence. If it doesn’t fit in one sentence, the scope is too big for an MVP.

Bad example: “complete auto repair shop management platform with inventory, accounting, scheduling, CRM, reports, customer app, and invoice integration.”

Good example: “system for a repair shop to track ongoing jobs and notify the customer when the car is ready.”

The bad example is 10 months of work. The good example is 6 weeks and solves the shop’s biggest problem: customers calling to ask if their car is done.

Mariah followed exactly this logic. The problem: “my sister doesn’t know how much she sold or who owes her money.” The solution: an app with an order dashboard and financial tracking. It shipped in 4 hours. If I’d tried to build inventory management, a product catalog, and monthly reports in the first version, it would have taken 2 weeks and she wouldn’t have used half of it.

2. Map the main flow

The MVP does one thing well. What’s the flow the user will repeat most? I design that flow from start to finish and build only that in the first version.

In AutoPars, the main flow was: seller lists a part -> buyer searches -> buyer purchases -> seller gets notified -> shipment is created. Everything outside that flow (advanced reports, review system, chat between seller and buyer) went to the backlog.

The rest doesn’t disappear. It just waits. And when it comes back, it comes back with data to justify whether it’s worth building or not.

3. Pick the stack

For webapps, my standard stack:

React on the frontend (components, state, routing)
TypeScript to catch silly bugs before production
Supabase on the backend (auth, PostgreSQL database, storage, realtime)
Tailwind CSS for fast and consistent UI

With this combination, I deliver a functional MVP in 4 to 8 weeks working solo. Supabase eliminates weeks of backend setup, React gives flexibility for any kind of interface, and TypeScript catches errors before they hit production.

If the project also needs a landing page (for lead capture, SEO, or presentation), Astro comes in for the static part. Two stacks, each doing what it does best.

4. Build in short cycles

I don’t spend 6 weeks coding only to show everything at the end. Every week, the client sees what’s working, tests it, and gives feedback. This avoids rework and keeps the project aligned with reality.

Typical MVP timeline:

Week 1: authentication + base structure + data model. By the end of the week, the client can log in and navigate the empty structure. Seems like little, but it validates that the foundation is right. At this stage I already set up Supabase with RLS (Row Level Security), because retrofitting access control later is much more expensive than doing it right from the start.

Weeks 2-3: main flow working. The core of the product is running. You can use it, test it, give concrete feedback.

Weeks 4-5: integrations and refinement. Payment, notifications, file uploads — everything that complements the main flow. Polished interface, edge cases handled.

Week 6: final testing, feedback adjustments, and deploy. The system goes live with a custom domain, HTTPS, and basic monitoring. I set up analytics (Plausible or Umami) to start collecting usage data from day 1 — that data will guide v2 decisions.

5. Deploy and first users

An MVP needs to go live early. Not the perfect version, the functional version. The first 10 users will show you what’s missing, what’s unnecessary, and what needs to change.

Deploy on Vercel (frontend) and Supabase cloud (backend). In 15 minutes the system is online with a custom domain and HTTPS. No server configuration, no infrastructure management, no database provisioning. The setup that used to take days now takes minutes.

What to cut from the MVP

This is the hardest part. Every client wants everything in the first version. The dev’s job is to show what can wait without hurting the product.

Cut:

Analytics dashboard. Use Plausible or Umami for now. Basic data without building a custom panel
Elaborate notification system. Manual WhatsApp or simple email. Automation comes later
Multiple user roles. Start with the main role. Admin and secondary users come in v2
Native app. PWA handles the first phase. Installs on the phone, works offline, no App Store
Integrations that can be manual. Payment via manual Pix before integrating a gateway. Shipping calculated by table before integrating Melhor Envio
Detailed reports. One screen with basic numbers. The full dashboard comes when you know which metrics actually matter

Don’t cut:

Authentication and access control. Security isn’t a feature, it’s a requirement. It doesn’t go live without auth
Responsiveness. If it doesn’t work on mobile, half your users won’t use it. And half is generous — for some products, 80% of traffic is mobile
Data validation. Bad data in the database is expensive technical debt. Validating on input is 10x cheaper than fixing it later
Database backups. Supabase does daily backups on the Pro plan. If you’re on the free plan, set up manual backups. Losing production data has no undo

The myth of “minimum scope” that turns maximal

The biggest risk with an MVP is scope creeping during development. “Since we’re already building this, let’s add that.” Starts with 5 screens, ends with 25. Starts with 1 integration, ends with 4. Starts as an MVP, ends as a full product that took 4 months.

My rule: any scope addition during the MVP goes to the “post-launch” list. If it wasn’t necessary on day 1, it’s not necessary now. Launch, collect data, and decide with real information what to add.

In practice, I keep a shared document with the client called “Post-MVP Backlog.” Every idea that comes up during development goes there with a short note about the problem it solves. When the MVP is live and the data starts coming in, we cross-reference that backlog with actual user behavior. About 40% of the ideas that seemed essential during development turn out to be irrelevant when confronted with data. And features nobody had thought of show up as priorities.

After the MVP: evolving with data

With the MVP running and generating data, the next decisions get easier:

Which features do users ask for? Prioritize the ones that come up most
Which screens does nobody visit? Remove or rethink them
Where does the flow get stuck? Improve the UX at the friction point
Does the business model work? Validate before scaling

FitPlan followed this path. It started with workouts and a student dashboard. Usage data showed that students dropped off in the first few weeks. That led to the inactivity notification system that reduced churn by 37%. That feature wasn’t in the original plan — it came from the data.

An MVP isn’t the end. It’s the starting point — and usage data shows you where to go next.