MVP for startups: what to build first, what to skip
Your first MVP shouldn't be the final product. It should prove a commercial hypothesis. Practical guidelines to not waste your first 6 months.
Gianmarco Pacetti
The most common mistake I see in first-time founders is building too much. Six months, €50k, and an MVP that does everything well except what it was meant to: prove someone will pay. It's an expensive mistake, avoidable, and recurring — even among experienced founders who should know better.
In this article I'll lay out what an MVP should contain in 2026 and what it must not contain. This is material I've refined accompanying a dozen startups from phase 0 to first paying customers.
What an MVP really is
“
An MVP is the smallest, simplest version of your product that lets you prove the riskiest hypothesis in your business model.
Note the words: smallest, simplest, riskiest hypothesis. Not "pretty", not "scalable", not "technologically perfect".
The riskiest hypothesis is usually one of these:
Is there anyone willing to pay for this?
Is the problem I solve big enough that they actively look for a solution?
Does my solution work better than the current alternative (even if that's "do nothing")?
If your MVP doesn't answer any of these, it's not an MVP — it's a demo.
The 4 MVP categories (and when to use which)
1. Landing page MVP (demand test)
The smallest thing you can do: a landing page with clear copy, fake product screenshot, and "Sign up for the beta" button. Measure signups.
Blog
Keep reading
Tell us what you want to build
Whether it’s a website, a management tool, an automation or a new platform, we help you find the right solution.
2. Concierge MVP (manual service, digital product)
The final product will be automated, but at the start you do everything manually behind the scenes. The customer sees an interface, behind it there's a person (you) doing the work.
Example: an SEO optimization app. MVP version: customer fills a form, you personally generate the report in Notion in 2 hours, email it back. Works? You can automate. Doesn't work? You saved 6 months of code.
When: when value is clear but you want to validate people actually use the flow.
Build time: 2-4 weeks
Cost: €3-10k
Measures: real usage + willingness to pay
3. Single-feature MVP (one thing, done well)
Build one feature, but the real one: the most important for customer value. No social login, no dashboard, no elegant admin panel. Just the thing the customer pays to do.
Example: building a contract generation tool, the MVP is "upload a PDF template, fill the fields, export". Stop. No contract history, no collaboration, no e-signature. Just the thing.
When: when you've validated the problem and need to validate the technical solution.
Build time: 6-12 weeks
Cost: €15-35k
Measures: technical feasibility + retention
4. Closed-beta MVP (10 users, very high-touch manual support)
Complete version but closed to max 10-20 users, hand-picked. WhatsApp support 24/7. The goal isn't scaling, it's learning.
When: when you need fast iteration with deep qualitative feedback.
Build time: 8-16 weeks
Cost: €25-60k
Measures: retention + qualitative product/market fit
What an MVP must NOT have
Blacklist of features I see added "because otherwise it's not serious":
❌ Payment system if you haven't proven willingness to pay yet (use manual Stripe Payment Links)
Payments: Stripe Checkout (don't integrate direct API, too much work)
Transactional email: Resend (better DX than SendGrid)
Hosting: Vercel (zero ops, auto-scaling)
Analytics: PostHog or Plausible
Zero-cost stack for the first months, scales well to the first 10k MAU without rearchitecting.
The decision framework I use with clients
When a founder reaches out for an MVP, I ask 4 questions:
What's the riskiest thing you don't know for sure in your model?
What's the smallest thing you can build to find out?
How many users do you need to be convinced of the answer?
How much time do you have before you need to prove it?
From these 4 answers, the right MVP type always emerges (landing, concierge, single-feature, closed-beta), along with a realistic time + budget estimate.
If you're starting out and want to figure out the minimum version that makes sense, reach out. I also run 2-3 hour workshops for founders who want to validate before spending — they cost less than a day of development and often avoid months of work in the wrong direction.
