How to Build an MVP in 2 Weeks (Step by Step)
Most founders spend months building features nobody asked for. A two-week sprint to build an MVP forces a different discipline: you can only ship what solves the single most painful problem your target user has right now. That constraint is the point.
This guide walks through the exact process Seven Hills uses with founders who come to us with an idea and a deadline. It works whether you are building a B2B SaaS tool, a consumer app, or an internal workflow product. The steps are the same; only the stack changes.
Day 1 to 2: Lock the Scope Before Writing a Line of Code
Write down the one user action that delivers the core value. Not five actions, one. If your idea is a scheduling tool, the core action is probably "book a time slot and get a confirmation." Everything else is a nice-to-have. Put it in a one-page brief: who the user is, what they do today without your product, and what they will do with it.
During these two days you should also settle on your tech stack. Picking familiar tools beats picking trendy ones. A React frontend with a Node or Python backend and a managed database like Supabase or Neon will handle almost any MVP scope and lets a small team move fast. Save the microservices conversation for version two.
Day 3 to 5: Build the Data Model and Core API
Start with the database schema. Draw it out on paper or in a tool like dbdiagram.io before touching a keyboard. A clear schema on day three prevents painful migrations on day twelve. For most MVPs you need three to six tables. If you are designing more than eight, the scope is too wide.
Wire up the backend endpoints that power the core user action you defined on day one. Write happy-path logic first. Skip error handling for edge cases you have not seen in real use. You can add guards once real users hit the product. At this stage, working beats hardened.
Day 6 to 9: Build the UI and Connect It to the API
Use a component library (shadcn/ui, Chakra UI, or Tailwind UI) so you are not designing from scratch. Pick the three to five screens the user must see to complete the core action. Wireframe them in Figma or even on paper, then build them. Resist the urge to polish anything at this stage.
Connect each screen to the API endpoints you built in the previous phase. Test every form submission and every data fetch manually as you go. Waiting until everything is wired to test is the fastest way to hit a wall on day eleven with no time to fix it.
Want this built, not just planned?
Our MVP Sprint ships a live product in 15 days for $3,500.
Day 10 to 12: Add Auth, Deploy, and Smoke-Test
Authentication is non-negotiable even for an MVP. Use a managed auth provider like Clerk, Auth0, or Supabase Auth. Do not roll your own. A working login and a protected route takes half a day with these tools and saves you from security headaches in the first week of real users.
Deploy to a real URL on day ten or eleven, not the last hour of day fourteen. Vercel or Fly.io handle most MVP deployments in under thirty minutes. Once it is live, go through every user flow yourself on a mobile device and on a desktop browser. Fix what breaks. Document what is intentionally left out.
Day 13 to 14: Onboard Five Real Users and Record Feedback
Do not launch publicly. Instead, invite five people who match your target user. Walk two of them through the product on a video call so you can watch where they get confused. Ask the others to complete the core action on their own and report back. Both approaches give you different signal.
Take notes on every point of confusion and every question they ask. You are not fixing bugs this week unless something is completely broken. You are writing down what to build in week three. The MVP is done when you have shipped the core action and collected that first round of real feedback.
Key takeaways
- Define one core user action before writing any code and protect that scope for the full two weeks.
- Use managed tools for auth, database, and deployment so you are not building infrastructure instead of product.
- Deploy to a real URL by day eleven so you have time to fix issues before user testing.
- Invite five real users for testing, not friends or family who will be too polite to tell you what is broken.
Frequently asked questions
Yes, if the scope is tight. The two-week constraint works when you define one core user action and ignore everything else. Most founders who fail to hit this deadline are building three or four features simultaneously instead of one.
The best stack is the one your team already knows. If you need a default recommendation: Next.js on the frontend, a Node or Python API, Supabase or Neon for the database, and Vercel for deployment. All four have free tiers and deploy in minutes.
One core feature, fully working. You can add secondary features after you have validated that the core feature solves a real problem. Shipping one thing well beats shipping five things halfway.
No-code tools like Bubble or Webflow work well for certain MVPs, especially marketplaces and content sites. For custom logic or API-heavy products, a developer will move faster. The tradeoff is cost versus flexibility.
You collect feedback from your first users, prioritize the top three problems they reported, and plan a follow-up sprint. The MVP is not the product. It is the first question in a longer conversation with the market.
Tell us what you are building
Get a plan and a fixed estimate at no cost. A real engineer, not a sales rep, replies within one business day.
Prefer to talk first? Book a 30-minute call or connect on LinkedIn.