4-week MVP: shipping a SaaS prototype on a fixed price | Leval

Audience: AI startup CTOs, US/Europe Reading time: 15 minutes

Four weeks from kickoff to a deployed, working product. Not a prototype, not a proof of concept - a system that handles real users, sends real notifications, stores real data.

This is our standard delivery cycle for MVPs, and it's not magic. It works because of specific preconditions, a specific process, and specific scope decisions. This post explains all three, including the cases where four weeks is the wrong framing entirely.

Why Four Weeks Is Actually Enough

The first reaction from most startup CTOs: "That's impossible for what we're building." Usually, it isn't.

Most MVP scope creep comes from confusing "must have for launch" with "would be nice to have" and "things we might need eventually." A four-week constraint forces this distinction. You can't build everything in four weeks, so you have to decide what actually matters for validating the core assumption.

We've shipped 20+ MVPs in the 4-week cycle across different domains: B2B SaaS tools, AI-powered document processors, marketplace integrations, internal automation tools for enterprise clients. The patterns that make it work are consistent.

Week 1: Architecture and design, zero feature code. Data model, API contracts, auth approach, external integrations list. All key decisions documented and reviewed before anyone writes a single API endpoint. Changes at this stage take hours. Changes at week 3 take days.

Week 2-3: Core feature development. Backend API, business logic, integrations. Parallel work where possible. Daily async standup: what's done, what's blocked, what changed in scope.

Week 4: Integration, testing, deployment. Frontend connected to real backend, end-to-end testing of the critical path, staging environment, production deployment. Not polish - the minimum viable state where real users can use the thing.

The Three Preconditions

Four weeks works when three things are true going in. When any of these is missing, the cycle expands - or should expand. Trying to compress around missing preconditions is how projects go sideways.

Clear scope with defined acceptance criteria

"We want AI to analyze customer contracts and flag risky clauses" is a vision. It's not a scope.

Scope means: which contract types (NDA, service agreements, employment?), what counts as a risky clause (specific legal patterns, or AI-determined?), what format does the output take (flagged PDF, summary report, JSON API response?), what happens when AI confidence is below threshold (show to user, reject, escalate?).

Every undefined decision is a time bomb. It will surface at week 3 when one person assumes the answer is X and another assumed Y, and the code reflects both assumptions inconsistently.

Our discovery week (included before the 4-week clock starts) produces a one-pager per feature with acceptance criteria written before any code. Not a full spec - acceptance criteria. How will we know this feature is done?

Available stakeholder for daily decisions

Four-week delivery requires a decision-making partner who can answer questions within 24 hours. Not a committee. One person with authority to say "yes, that's good enough" or "no, do it this way instead."

When decisions wait 3-4 days for a response, the 4-week cycle becomes 6 weeks. This isn't a theoretical concern - it's the most common reason MVPs slip.

We ask this explicitly before starting: who is the technical decision-maker on your side? What's their response time commitment? If the answer is "we'll discuss it as a team," we talk about what that means for timeline.

Defined API contracts and data sources

If your MVP depends on an external API that isn't documented, an AI model that isn't yet selected, or data that isn't yet collected - week 1 becomes about those unknowns instead of about building.

This doesn't mean everything has to be finalized. It means we need to know what the question marks are on day 1, and we need a plan for each: mock the API with realistic test data, pick a model now and swap later, define what minimum data exists to start.

The Discovery Week: Why It's Not Skippable

Every project starts with a discovery week before the 4-week clock. This isn't scope creep - it's the reason the 4-week clock works.

A discovery week without code produces: a data model, an API contract document, a list of external integrations with their current status (documented, in progress, not started), a prioritized feature list with in/out decisions, and acceptance criteria for each in-scope feature.

What a data model is before discovery: "we'll have users, and they'll have orders, and each order has items." What it is after: a PostgreSQL schema with tables, fields, types, indexes, foreign keys, and explicit decisions about which fields are required and which are nullable. This seems like over-engineering for a discovery. It isn't.

The most expensive bug in a 4-week project is a data model mistake discovered at week 3. Fixing the schema means migrating data, updating every API endpoint that touches the table, updating every test, and retesting everything. A schema decision made in week 1 costs 2 hours to change. The same decision at week 3 costs 2 days.

Here's what a good discovery output looks like for a contract analysis tool:

``` Feature: Upload contract document

• Accepted formats: PDF only (MVP)
• Max size: 10 MB
• Storage: S3, path pattern: contracts/{org_id}/{doc_id}.pdf
• What happens if AI analysis fails: document stored, status = 'failed',

user gets email, manual review queue

Feature: View analysis results

• Output: flagged clauses with severity (high/medium/low) and explanation
• Confidence threshold: clauses below 0.6 confidence are hidden
• Export: JSON API only in MVP (no PDF export)
• Latency: analysis takes 30-90 seconds, async processing

```

This is not a specification. This is the minimum set of decisions that let developers write code without guessing.

What Goes Into a 4-Week MVP (and What Doesn't)

A common misconception: "4-week MVP" means cutting corners on quality. It means cutting scope, not quality. The code that ships is production code. The infrastructure is production infrastructure. But not everything you imagined is in scope.

What goes in: the critical user journey that validates the core assumption. If you're building an AI contract analyzer: upload contract, get flagged clauses, view details. That's the flow. If that works, you've validated the core.

What doesn't go in: bulk processing, audit logs, white-label branding, advanced filtering, team management, custom AI model training, integration with 7 external tools. These are real features that users will eventually want. They're not what validates the core.

The question we use in scope discussions: "If this feature isn't there at launch, does that prevent us from testing the core assumption?" If no - it's not in the MVP.

Typical MVP feature set for a B2B AI tool:

Core: the main AI-powered action (analyze, classify, generate) with one input format and one output format.

Auth: email + password, maybe Google OAuth. Not SSO, not SAML, not role-based admin panel.

User management: create account, delete account. Not team management, not permissions, not billing.

Billing: a single subscription tier if the MVP needs to charge, or none at all if validating value before price.

Admin: a simple read-only view of users and usage, or nothing. Not a full admin panel.

Infrastructure Decisions We Make on Day 1

The 4-week timeline means we can't revisit infrastructure choices mid-project. These get decided in week 1:

Cloud provider. We default to AWS for new projects. GCP if the client uses Google Workspace and wants tight integration. Azure if the client has existing Azure credits or enterprise agreement. We don't switch mid-project.

Deployment model. For MVPs: ECS Fargate for the application tier, RDS PostgreSQL for data, ElastiCache Redis if the feature set needs it. Not Kubernetes - that's for projects that have outgrown Fargate, which no MVP has. Kubernetes adds 2-3 days of configuration work with no benefit at MVP scale.

Authentication. JWT with short-lived access tokens and long-lived refresh tokens. If Google OAuth is in scope, we add it in week 2. Enterprise SSO is not in MVP scope.

Monitoring. CloudWatch for infrastructure metrics, structured JSON logging, one health check endpoint per service. Not full observability stack - that's for when you have users and real traffic patterns to monitor.

AI/LLM integration. If the project uses LLM, we pick the model and integration approach in week 1. Changing from OpenAI to Anthropic at week 3 is a week of rework. We evaluate the options in discovery and commit.

The common thread: we pick the boring, well-understood option for the MVP. Boring means we've done it before, we know the failure modes, and we can move fast. Novel infrastructure choices are risks that can be taken after the MVP validates the business.

When Four Weeks Is Wrong

In fairness - three scenarios where the 4-week framing doesn't work and shouldn't be forced.

Research-heavy or ML-pipeline projects

If your product involves training a custom model, significant data pipeline work, or novel technical territory where the right approach isn't clear - four weeks is unrealistic for anything beyond initial exploration.

You can't compress the time it takes to collect training data, label it, train an initial model, evaluate it, and iterate. These steps take the time they take. The right framing here is a research phase (4-8 weeks) followed by a product development phase (4-6 weeks).

We're honest about this upfront. If the technical foundation isn't established, we don't quote a 4-week MVP - we quote a research engagement that ends with a recommendation for next steps.

Heavily regulated domains

Healthcare, fintech in certain jurisdictions, anything requiring security certifications - the compliance work doesn't compress. A medical device software MVP that needs to go through FDA Class II review isn't shipping in four weeks no matter how good the development process is.

What can ship in four weeks: the functional core. What can't: the compliance wrapper. These are separate timelines and budgets.

Dependencies on third-party timelines

Your MVP requires an API integration with a partner who hasn't finished their API yet. Your MVP requires data migration from a legacy system that takes 6 weeks to extract. Your MVP requires a legal agreement with a vendor that's 3 weeks into negotiation.

These aren't development problems - they're project management problems. The four-week development cycle can be ready to go in four weeks, but it can't launch until the dependency resolves.

We map these dependencies in week 1 and make them visible. "The development will be done by November 15. The AWS Marketplace integration approval may take 4-6 additional weeks."

How This Connects to Fixed-Price Delivery

The 4-week cycle and fixed-price model reinforce each other. Fixed price requires defined scope. Defined scope enables a reliable 4-week estimate. Neither works without the other.

When someone asks "how long will this take?" without defined scope, the honest answer is "it depends on scope." The 4-week answer is the answer to the question "how long for this specific defined scope?"

Our typical engagement for a greenfield MVP:

• Discovery week (pre-project): Define scope, write acceptance criteria, map dependencies, agree on what's in and out. Included in the project price.
• 4-week development: Architecture, backend, frontend (if in scope), integrations, testing, deployment.
• 30-day support post-launch: Bug fixes (not new features), questions from your team, help onboarding initial users.

The fixed price covers all of this. Changes to scope after discovery week go through a change request process - impact on price and timeline assessed before any work starts.

Working With Leval on a 4-Week MVP

We work with a team of 3-4 people per project: lead engineer/architect, 1-2 developers, QA. One architect per project, not shared across concurrent projects. That person is available for questions, attends weekly calls, and owns the technical decisions.

Our base locations are Eastern Europe, which typically means UTC+2 to UTC+3. For US clients, this means mornings their time are afternoons ours - good overlap for synchronous communication if needed.

If you have a well-defined scope and want to talk through whether the 4-week cycle fits: describe what you're building. We'll be direct about fit, timeline, and price - before the project starts, not after.