MVP in four weeks: our proven development process

Building a minimum viable product sounds straightforward until you’re six weeks in, the scope has tripled, and the original deadline is a distant memory. Most MVPs don’t fail because of bad ideas—they fail because the process around them is loose. No fixed scope, no weekly checkpoints, no clear definition of “done.” The timeline slips, the budget follows, and by the time something ships, the market has moved.

This article walks through how a four-week MVP actually works: what the phases look like, what’s realistic to build in that window, what it costs in the US market, and how we run it at Pazl.

---

Why Four Weeks Is the Right Target (and When It Isn’t)

Four weeks is not a magic number. It’s the shortest window that allows for a real development cycle with weekly demos, a proper handoff, and enough functionality to test a core assumption with real users.

Two weeks is usually a prototype, not an MVP. Eight weeks is often a small product. Four weeks sits in the middle: long enough to build something testable, short enough to force scope discipline.

That window works when:

• The core user flow is one to three screens or steps
• Integrations are limited to one or two external APIs
• Design is functional rather than polished
• The team has done this type of build before

It does not work when the client wants a marketplace, a multi-role platform, or real-time features that require significant infrastructure. Those are legitimate products—they just need a different timeline.

---

The Four-Week Process, Phase by Phase

Week 1: Scope Lock and Technical Foundation

The first week is not about writing code. It’s about making sure everyone agrees on exactly what will be built—and what won’t.

This means a written technical specification (not a slide deck), a defined user flow, and a decision on the tech stack. Any ambiguity here costs double later. We’ve seen projects where the client described “a booking system” and the developer heard something completely different. A spec document with wireframes closes that gap.

By the end of week one:

• Scope is locked in writing
• Tech stack is chosen
• Development environment is set up
• The first weekly demo is scheduled

Week 2: Core Functionality

This is the heaviest development week. The goal is to have the primary user flow working—not beautifully, but functionally. A user can complete the main action the product is designed for.

For a B2B order management tool, that means a user can log in, create an order, and see it in a dashboard. For a loyalty app, it means a user can register, earn points, and check their balance. The feature set is narrow by design.

Week 3: Integrations and Edge Cases

Week three connects the core to the outside world: payment processors (Stripe, Braintree), authentication (Auth0, Firebase), third-party APIs, or whatever the product requires. It also handles the edge cases that week two left unresolved—error states, empty states, basic validation.

This is also when QA begins in parallel with development rather than after it. Waiting until week four to test is how projects miss their deadline.

Week 4: Polish, Testing, and Handoff

The final week is not for adding features. It’s for making what exists reliable. Performance testing, security review, fixing bugs surfaced in QA, and preparing the handoff documentation.

By the end of week four, the client has a working product they can put in front of real users, along with the source code, deployment instructions, and credentials.

---

What Realistically Fits in Four Weeks

The scope column matters as much as the timeline. “Four-week MVP” means something specific—it doesn’t mean a four-week version of a product that would normally take six months.

---

What Does an MVP Cost in the US Market?

Pricing varies significantly depending on whether you work with a freelancer, a US-based agency, or an offshore team with Western-facing project management (which is increasingly the norm for fixed-price engagements).

A few things worth knowing about these ranges:

Hourly vs. fixed price. Hourly billing means the client carries the risk of scope creep. If the project takes longer, the invoice grows. Fixed-price contracts transfer that risk to the studio—which is why fixed-price studios scope more carefully upfront.

What “MVP” means to the vendor. Some agencies use “MVP” to mean a stripped-down version of a full product, priced accordingly. Others mean a true first-test build. Ask for a written scope before comparing quotes.

Post-launch costs. Hosting on AWS or Google Cloud for a small MVP typically runs $50–$200/month. App Store developer accounts cost $99/year (Apple) and $25 one-time (Google). These are always the client’s responsibility—no legitimate studio bundles them into project fees.

---

How We Run It at Pazl

We work on a fixed-price model. The price and timeline go into the contract after the technical specification is approved—not before. This protects both sides: the client knows exactly what they’re paying, and we know exactly what we’re building.

Our standard process:

1. Discovery call — we understand the product idea, the core assumption being tested, and any existing constraints (existing codebase, required integrations, target platform)
2. Proposal — fixed price, fixed timeline, written scope
3. Contract + spec — the technical specification is an appendix to the contract; anything outside it is a change order
4. Development with weekly demos — every week, the client sees what’s been built and can give feedback before the next sprint starts
5. Handoff — source code, deployment documentation, credentials, and a 6-month warranty on everything we built

The warranty matters. If something breaks because of our code in the six months after launch, we fix it at no charge. Server costs, domain renewals, and third-party API fees are always the client’s direct expense—we don’t mark those up.

Our entry point for custom web app and MVP development starts at €3,000 (≈$3,260). More complex builds—multi-role platforms, mobile apps with backend, AI integrations—land in the €8,000–€25,000 (≈$8,700–$27,200) range depending on scope. The exact number comes after we’ve reviewed the requirements, not before.

A representative example of what we’ve built: We developed an AI agent for a service business that handled inbound client communication across text, voice, photo, and video—integrated with Trello for task management, with automatic escalation to a human when the conversation required it. The agent ran 24/7, handled the routine intake that was consuming the team’s time, and allowed the business to handle more volume without adding headcount. That kind of build—a working AI agent with CRM integration—is the type of project that fits a four-to-six week window when the scope is defined tightly.

We’ve also built B2B ordering systems with direct ERP integration, loyalty apps with point-of-sale connections, and automation tools that replaced manual workflows. The common thread: a defined scope, weekly demos, and a handoff the client can actually use.

---

The Most Common Reasons Four-Week MVPs Fail

Scope added mid-sprint. Every new feature request that arrives during development either pushes the deadline or displaces something already planned. The spec document exists to make this visible—“yes, we can add that, here’s what it replaces or here’s the cost to add it.”

No decision-maker available. Weekly demos only work if someone with authority to approve or redirect shows up. If feedback has to travel through three layers of internal approval, the project stalls.

Third-party API surprises. Integrating with a payment processor, a healthcare data system, or a logistics API often takes longer than expected—especially if the API documentation is poor or the sandbox environment behaves differently from production. We scope integrations conservatively and flag this risk early.

Design decisions deferred too long. Waiting until week three to decide on navigation structure or user flow means rebuilding work that’s already done. Design decisions need to happen in week one.

Treating the MVP as the final product. An MVP is a test, not a launch. The goal is to learn something about the market, not to build everything the product will eventually need. Teams that treat week four as a product launch tend to over-scope and under-deliver.

---

Compliance and Data Considerations for US MVPs

If your MVP collects personal data from California residents, CCPA/CPRA applies from day one—not after you reach a certain user count. That means a privacy policy, a mechanism for users to request deletion of their data, and clarity on what you’re collecting and why.

For healthcare-adjacent products, HIPAA applies if you’re handling protected health information. The FTC also has enforcement authority over deceptive data practices regardless of state. These aren’t reasons to delay building—but they are reasons to make sure your spec includes the right data handling from the start rather than retrofitting it later.

Tools like Termly or Iubenda can generate compliant privacy policies for a small annual fee. For anything involving payment data, using Stripe or Braintree means PCI DSS compliance is largely handled at the processor level rather than yours—which is the right architecture for an MVP.

---

How to Evaluate a Studio Before You Sign

A few questions worth asking any vendor before committing to a fixed-price MVP engagement:

• Can I see the technical specification from a past project? A studio that can’t show you what a spec looks like probably doesn’t write them.
• Who owns the code at the end? The answer should be: you do, after full payment. Source code should be delivered, not hosted on the vendor’s infrastructure indefinitely.
• What happens if something breaks after launch? A warranty period with defined terms is standard. “We’ll look at it” is not.
• How are out-of-scope requests handled? Change orders, in writing, with a price and timeline impact. Verbal agreements about “small additions” are how projects go over budget.
• Do you have examples of similar builds? Not case studies with vague outcomes—actual products you can look at or test.

---

Wrapping Up

A four-week MVP is achievable, but it requires discipline on both sides. The studio needs to scope tightly, demo weekly, and deliver what was agreed. The client needs to make decisions quickly, stay available, and resist the urge to expand scope mid-build.

The fixed-price model exists to align those incentives. When the price is set and the scope is written, both sides have a reason to stay focused.

If you’re planning an MVP and want to talk through what’s realistic for your idea, reach out at hello@pazl.ai or visit pazl.ai. We’ll tell you honestly what fits in four weeks and what doesn’t—before any contract is signed.