--- title: What a 6-Week MVP Build Looks Like url: https://varstatt.com/jurij/p/what-a-6-week-mvp-build-looks-like author: Jurij Tokarski date: 2026-04-03 description: MVP development for startups, structured as a 6-week retainer. From idea to working SaaS — auth, core features, payments, production deploy. section: Blog (https://varstatt.com/jurij/archive) tags: retainer-shapes (https://varstatt.com/jurij/c/retainer-shapes) --- Most MVP development services follow the same broken pattern: collect requirements, estimate hours, build in isolation for months, then deliver something late that doesn't quite fit. By the time you see it, the assumptions are stale. Six weeks is enough to build an MVP that's actually live. But only if every week produces working, deployable software — not a document, not a staging build that "just needs polish," but something that can go live. ## MVP = v1. Anything Faster Is a Prototype. The market sells "MVP in 2 weeks," "MVP in 6 days," "weekend MVP." All of it is the same trick: take a prototype, call it an MVP, charge MVP money for prototype work. Then the founder gets their first paying customer, asks for a feature, and every developer who looks at the code says it needs to be rebuilt. I've written about [exactly that situation](/jurij/p/if-you-throw-away-your-mvp-code-it). An MVP is the first version of the real product. It's v1 in everything but name. The "minimum" doesn't mean fast — it means the smallest scope that still delivers real value. A SaaS MVP that takes weekend-build shortcuts will need a rebuild before its third paying customer; one built to last six weeks won't. Frank Robinson, who coined the term in 2001, defined it as "a working product with just enough features to satisfy early customers and provide feedback." [The fourth evolution of MVP](/jurij/p/the-fourth-evolution-of-mvp) traces how the term got watered down until it could mean almost anything. The original definition holds up best. Six weeks is the honest number for the smallest shape that's still a real product: auth that works, a database schema you can extend, payments that don't get rebuilt at the first feature request, deploy infrastructure that handles real users, error handling that doesn't lose data. If your appetite is two weeks, that's a [proof of concept](/jurij/p/what-a-2-week-poc-looks-like) — a different shape with a different job. Two months is a v2 with extra features. Six is where the smallest-real-product fits. ## The Shape $997/week, six weeks, one agreed outcome. Not a fixed-price project — no upfront estimate, no hourly billing, just the same weekly retainer with an agreed duration. Scope is shaped by [appetite, not estimates](/principles/discovery/appetite-not-estimates): when something turns out harder than expected, features simplify, edge cases defer. The timeline doesn't. ## What Each Week Looks Like Week one is infrastructure: auth, database schema, deployment pipeline. By the end of week one, there's a live staging environment you can log into. Weeks two through five are core features, one at a time. Each is reviewed, refined, and deployed before the next starts. Payments, email, and third-party APIs wire in when the core flow needs them — not upfront as a defensive move. Week six is production hardening: error handling, edge cases, final deploys. You end week six with something you can hand to real users. ## Why a Single Senior Developer Most MVP development companies put a project manager between you and the person writing code, then hand the work to a rotating mix of mid-level developers and offshore contractors. This is the opposite: one senior developer who owns the architecture, makes the calls, and is accountable for the result. The stack is React, Next.js, Firebase — the [default stack](/principles/delivery/default-stack) I know well enough to move fast without creating debt. The code you launch with is the code you continue building on. ## Who This Is For Founders validating a SaaS idea who need real software, not a prototype. Domain experts replacing manual processes who know the workflow but need the build. Teams that outgrew Bubble or Webflow and now need real infrastructure. The most common question from non-technical founders: "How do I know this is scoped right?" The answer is we [find the core](/principles/discovery/find-the-core) together before week one starts. If the scope doesn't fit six weeks, it's not MVP scope — it's a wish list. If you're looking to build an MVP in six weeks, the [build cost plan](/discovery/build-cost-plan) and [feature prioritization](/discovery/feature-prioritization) tools are a good place to start scoping. When you're ready to talk, [submit a project brief](/brief).