A focused web MVP takes about six weeks: week 1 is discovery, week 2 is design, weeks 3 to 5 are the build, and week 6 is launch. You get a written scope, then a clickable design, then a working product with real accounts and payments, then a live product. Mobile apps, heavier integrations or scope changes make it take longer.
When you pay for a build, the hardest part is often not the price. It is not knowing what is happening, or when you will see something real. This article walks through how we take a focused web MVP from the start of the project to launch in about six weeks, week by week. It follows the four steps of the process behind our MVP sprint for founders: discovery, design, build, then launch and improve.
One honest note first. The exact split between the steps depends on your product. What follows is the usual shape for a focused web MVP. The real timeline for your project is agreed up front, before work starts, and we keep to it.
Before week 1: what is agreed up front
Before the six weeks begin, two things are clear: the timeline and the price. We quote a fixed price for the scope, not an hourly rate, so you know the cost before any work starts. If you want to compare that with other options, our guide to what an MVP costs in 2026 gives the market ranges.
If you arrive with a prototype built in an AI tool or a no-code tool, it becomes the brief. We keep what works and build the production version around it. If the prototype is messy, we start with a rescue audit to find the fastest safe route. We explain why a prototype is not yet a product in from AI prototype to real product on this blog.
Week 1: discovery
What we do. We pin down the problem, the users and the core flow: the one path through your product that has to work well. We agree what waits until version two. Then we lock the smallest scope that proves the idea.
What you do. Answer a lot of questions, and make decisions. The most useful thing you can do this week is say "not yet" to good ideas that are not needed on day one.
What you have at the end. A clear, written scope. Everyone knows what is being built, and what is not.
Week 2: design
What we do. We design the key screens and flows, and make them clickable before a line of code is written. You click through them, we refine, and we repeat until it feels right.
What you do. Click through everything, as if you were a new user. Show it to a few people from your target group if you can. Changing a screen now takes minutes. Changing it after it is built takes days.
What you have at the end. A clickable design of your product that you can already show to others.
Weeks 3 to 5: build
What we do. We build in short cycles on Next.js, Vercel and Supabase, with working versions for you to try along the way. This is where the parts that prototypes skip get done properly:
- Secure accounts. Logins, roles, and each user's data kept separate, checked before launch.
- A data model that grows. Built for ten thousand users, not only the first ten.
- Payments, end to end. Checkout, subscriptions, failed charges and receipts handled properly.
- Fast on real devices. Tested on real phones and slow connections, not only on a laptop.
AI-assisted development is a big part of why this fits in weeks. We use it as a tool, not a shortcut: everything that goes live is tested and built on a stack we know well.
What you do. Try each working version and give feedback quickly. Prepare what only you can provide: the texts, the prices, the legal pages. It also helps to have your own accounts ready for things like payments and your domain, because the code, the accounts and the data are yours from the first day.
What you have at the end. A working product that does the core job, with real accounts, real data and real payments.
Week 6: launch
What we do. We make the product ready for real people. Your domain, analytics, transactional emails (sign-up confirmations, receipts, password resets) and error monitoring are in place before your first user signs up. Then we ship it to real users.
What you do. Invite your first users. Tell them what the product is for, and ask them to use it for real.
What you have at the end. A live product, and error monitoring that tells us about problems before your users have to write in.
An MVP is small in scope, not in quality. Six weeks is possible because the scope is small, not because steps are skipped.
After week 6: launch and improve
Launch is the start of learning, not the end of the project. We watch how people use the product and improve it from what we learn. After launch, a care plan keeps the product healthy, and a product partnership keeps it improving as users tell you what they need. When the idea is proven, iOS and Android apps can come from the same codebase and go to the App Store and Google Play.
What can make it take longer
- Mobile apps from the start. Native iOS and Android apps add time. That is why we usually start with web: it is the fastest way to reach users and learn.
- Heavier integrations. Connecting to many outside systems adds work, and it is planned into the timeline up front.
- Changing the scope after it is locked. New features in the middle of the build push everything back. Write them down for version two instead.
- Slow feedback or missing content. If a working version waits a week for your review, the launch waits a week too.
How to get ready
- Write down the one job your product must do. One sentence is enough.
- Know your first users. Who will try it in week 6, and how will you reach them?
- Keep time free for decisions. Quick answers keep the six weeks on track.
- Bring what you have. Notes, sketches, a prototype. Even a messy prototype is a clear brief.
The bottom line
Six weeks is not magic. It is a small scope, a fixed plan, and something you can see and click at every step. If you want to know what that would look like for your idea, read how our MVP sprint works and tell us where you are. We will agree a timeline and a fixed price before any work begins.
