A focused MVP takes 2 to 4 weeks when the scope is one core routine, one or two types of user and almost no integrations. Most published estimates say two to four months. They aren't wrong. They describe a bigger product. The difference doesn't come from typing faster. It comes from what you agree, in writing, to leave out before anyone gives you a date.
How long does it take to build an MVP, really?
The market answer is "months". Netguru says an MVP typically takes three to four months. 7L International puts most MVPs at 8 to 16 weeks from kickoff to a release users can try. Look closer, though, and the range narrows fast with scope. Forcoda says a lean MVP with one core workflow, one user type and minimal integrations can take 4–8 weeks. Crework Labs says most MVPs built by experienced teams in 2026 take three to eight weeks. Technijian goes further: past 16 weeks, the MVP is almost certainly overscoped.
Our own record sits at the short end. One app went live two days after we started. That isn't a promise we make to everyone. It's what happens when the scope is one daily routine for two users and nothing else.
Why does speed matter this much? Because the biggest risk isn't a bug. A summary of CB Insights research found that 42% of failed startups failed because there was no market need. Every extra month of building is another month before you find out whether anyone wants the thing.
What fits in a 2–4 week first version
We like Soonlay's definition: the MVP is the shortest path from opening the product to getting the outcome, plus the minimum admin tooling to run it. In practice, a 2–4 week first version includes:
- One core workflow, start to finish. Not three half-workflows.
- One or two user roles. Usually your users and you, as admin.
- Login, and the data you'll need to learn from.
- The admin screens you need to run it day to day. Plain screens, not pretty ones.
- A live deployment on your real domain, so real people can use it from day one.
Web app or native app?
For a first version, we default to a web app that people can install on their home screen. No app store review, and every update reaches users the moment we ship it. There are trade-offs, and we plan around them. In our experience on iPhone, the home-screen icon and splash screen tend to stay as they were at install, and users who installed early can keep the old ones until they reinstall. So we lock branding before launch, not during it. And when staff scan QR codes every day on an iPhone, we've seen Safari ask for camera permission again on later days unless the site is set to "Allow". We add a one-time how-to right inside the scanner screen. Small things, but they decide whether the team likes the tool in week one.
What waits for version two, and what waiting costs you
The list of what waits matters as much as the list of what ships. For each item, we write down what postponing it costs you, so you choose with open eyes.
Third-party integrations become a manual step. On a charity running campaign, the plan included a Strava sync to track each runner's progress. When we got to it, our review of Strava's developer access and terms made it a poor fit: the access added cost, and showing runners' data on a public campaign page looked hard to square with the conditions as we read them. So we replaced the sync with a manual tick in the admin, and progress is calculated from there. It shipped right away. The cost of waiting: someone ticks a box a few times a week.
Payments become a payment link or an invoice. Sprout says products with billing, several user roles or complex integrations realistically need eight weeks or more. The cost of waiting: you chase a handful of payments by hand while you learn whether people pay at all.
Roles and permissions shrink to one admin. The cost: you run the back office yourself for a while. That's no bad thing. You'll see exactly what your future team needs.
Dashboards, multiple languages, referrals and loyalty wait. The cost: a spreadsheet export once a week.
Scraped data feeds wait. Building a scraper is quick. Keeping it alive isn't. Sites change, block bots and break the feed, often without an error. The real cost is the maintenance line, and it never ends.
Some things simply don't fit. Regulated products in healthcare or fintech need around 6–12 months because of compliance. Late copy and images alone can add 1–2 weeks. We say so up front instead of pretending.
How we scope and run an MVP build with you
At Pillet Grenié Bureau, the decision that shapes everything is this: we confirm dates only once the scope, risks included, is agreed. A date given before that is a number you can hold us to and we can't honour.
The safeguard is reading the brief for what's missing. Specs that arrive "ready to scope" often have the risks and the timeline taken out to make them easier to read. When we spot that, we ask in writing for the full version. If it doesn't exist, we say so plainly and build the risk list with you as the first step. That way the gap becomes a piece of work, not a hidden tax on the estimate.
At kick-off, we also check what you've already bought. In our experience, founders who register a domain themselves sometimes end up with web hosting and add-ons pre-ticked at checkout. Our stack doesn't use them, and they renew every year. We flag them before the second year gets charged.
From you, we need four things: one person who decides, content by an agreed date, access to your domain, and a short weekly review where we check the "later" list together.
The result: a date you can plan a launch around, a first version in your users' hands within 2 to 4 weeks, and a version-two list where every item already has a reason and a cost. If you have an idea that fits one routine, start with our MVP build and we'll draw that line with you.
