MVP Scope Freeze: What We Cut, Keep and Do Manually
Every founder planning a first product reaches the same moment. The list that felt essential in week one has grown by week three, and someone says the build will start when the list stops growing. It never stops on its own. The MVPs we see stall late in the build rarely fail because the engineering went wrong. They fail because the list of yeses kept growing after development began.
Our countermeasure is an MVP scope freeze: one signed page, written before the first commit, that fixes the build at eight weeks. This article is that page: what we put on it, what we cut, and what we deliberately leave for a person to do by hand.
The MVP scope freeze lives on one signed page
A scope that lives in chat logs and slide decks does not hold. Ours is one page with four named lists, and it is not done until the person paying for the build has signed it.
| List | What goes on it | Example from our builds |
|---|---|---|
| The one action | The single job the product exists to do, written as one sentence | warasat.com.pk: a serious enquiry reaches the agent |
| The boring half | Sign-up, payment collection, the records nobody daydreams about | mtufaildiagnosticcenter.com: the booked-slot list |
| The manual pile | What the software will not do at launch, a name next to each line | The agent’s phone is the dispatch system |
| The parked list | Good ideas refused before kickoff, kept in writing so they stay refused | Saved searches and agent profiles, waiting |
The page also names the price of the freeze: eight weeks. We hold the dates on the calendar before development starts, the way a landlord holds an apartment. In Shape Up, Ryan Singer separates a fixed budget from a promise about results with the word appetite: “a time budget for a standard team size”. His contrast is the sharpest one-line version of why we freeze first: “An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design.” The design that fits eight weeks is what the four lists produce.
What survives the cut
Eric Ries defined the minimum viable product in 2009 as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” Most teams argue about the minimum part. The freeze argues about the least effort part, because that is where the cuts come from: every field, screen and notification on the list has to justify its effort against the one action.
Our real-estate site warasat.com.pk takes enquiries through a form with three fields: name, phone, and an optional message. An agent calls back. A visitor types one line and waits for a phone call. We could have built scheduling, agent profiles and saved searches. All of it would have slowed the one action: a serious enquiry reaching the agent.
At mtufaildiagnosticcenter.com, a diagnostic centre in Kasur, patients book an MRI slot through a form with eight fields and a dropdown of thirteen bookable times. Staff assign the scanner. That weight stays because a missing field produces a booking the front desk cannot act on, and a diagnostic centre cannot improvise around a missing imaging order. The form is heavy because the operation behind it is heavy.
Truckaxic.com, our US dispatch site, turns a quote into four steps; step one carries four fields: name, optional company, email, phone. Each step is one decision, so a dispatcher-to-be never faces a wall of boxes. If you are planning a build and want this kind of field-by-field pruning done against your real operations, that is our web development service in one line.
Three deletions cover most of the list
First, second roles. Most first-version products have two kinds of user: the customer and the operator. The freeze keeps the customer flow and lets a person operate. A separate admin dashboard, with its own login, permissions and audit trail, is a product in itself. It is not on the eight-week page.
Second, analytics. Our own MVP guide from 2025 told founders to ship “essential infrastructure: auth, payments, analytics” before launch. The freeze edits that line: auth and payments stay, analytics moves past launch. An MVP that is true to Ries’s definition is itself an experiment, and the instrument that measures the experiment does not have to ship inside it. The feedback that matters in week one arrives as phone calls and form submissions, and those you can count by hand. Dashboards can follow in week nine, once you know what a conversion even is.
Third, weight in forms. Every field is a place a visitor can quit. We counted this in how many fields a small-business contact form needs: three where an agent calls back, eight where the operation behind the form is heavier. The freeze asks it early, per field: does the visitor need to give us this, or does our side need to know it? Only the first kind earns its place before launch.
The manual pile
The manual pile is the list founders resist; it reads like admitting the product is unfinished. In practice it is the cheapest feature you will ever ship: a person.
Warasat runs on it: a visitor leaves a callback request, an agent calls back, and the dispatch screen is the agent’s phone. Mtufail runs on it too: the booking form collects the request, and a staff member assigns the actual scanner slot from a calendar the desk already keeps.
Steve Blank described the rhythm these builds follow in the Harvard Business Review in 2013: “New ventures rapidly assemble minimum viable products and immediately elicit customer feedback.” Rapidly is the operative word. A manual pile is what lets the software exist in week eight, not week twelve. The cost is honest: someone’s phone becomes the dispatch system, someone’s morning includes assigning slots. We count those hours; they are the evidence for what version two automates first.
When the plan moves
A freeze does not stop ideas from arriving. It stops them from entering the build. Week four arrives, a competitor launches something shiny, and the request lands: can we add this?
Every request gets one of two destinations, neither the current build. If the idea removes manual work from the pile, it goes on the pile as a candidate for version two. If it does not, it goes on the parked list. Both destinations are written down, which keeps the conversation short. Shape Up’s answer to a raw idea is the tone we aim for: “Interesting. Maybe some day.”
The rule underneath is Singer’s again: “Without a time limit, there’s always a better version.” Every feature is a better version of something. The freeze does not claim the parked list is wrong, only that this build ships in eight weeks and the next one starts from evidence.
The trade-off is real: some good ideas never come back; a parked feature can turn out to have been the whole product. That risk is smaller than the price of shipping late: a longer build, a bigger bill, competitors learning from customers while the perfect version sits in development.
Where the MVP scope freeze breaks
Two failure modes account for most of the times a freeze has not held.
The first is an untested one action. If the core loop has not been walked through with a real potential customer, the freeze locks in a guess. Ries warned about exactly this: “MVP, despite the name, is not about creating minimal products.” A freeze without a tested loop is minimality for its own sake. We treat the one-action line as unverified until someone outside the team has tried it, and we delay the signature, not the honesty.
The second is operational weight. The manual pile assumes a person can actually do the work. If the operation behind the product is heavy, the pile collapses. Our eight-field booking form works because the diagnostic centre already runs a desk that handles phone bookings all day. The same form pasted onto an operation with no desk would bury someone. The check is simple: name the person who does the manual work, and ask them honestly whether it fits their week. If nobody can be named, the feature is not in the manual pile. It is in the build, and something else must come out.
Write the freeze before the first commit
The instrument fits on one page. The one action in a sentence. The boring half that makes it usable. The manual pile with a name next to each line. The parked list of ideas you refused. The signature of whoever is paying, before the first commit. Then eight weeks, a demo every Friday, and a rule that sends week-four requests to the lists instead of the build.
If you are planning a first version and want a second pair of eyes on that page, talk to us about your build. Bring the four lists half-filled; we will argue about the rest before a single line of code exists.
FAQ
How many features should an MVP have?
Fewer than fit on the freeze page. Our builds land in the low tens of small items: one core action, a handful of supporting screens, the boring half (sign-up, payments, the records list). If the list needs a second page, that page is the roadmap for version two.
What happens when a stakeholder demands a feature in week four?
It goes on one of two lists, never into the build. If it removes manual work, it becomes a version-two candidate, ranked by the hours the pile is burning. If not, it goes on the parked list. Both lists are written and visible, turning most arguments into a line item, not a fight.
Why eight weeks and not six?
Six weeks fits a well-understood feature. A first product has to stand up sign-up, payments, data handling and the core loop together, and our builds have needed six to ten weeks for that. Eight sits in the middle: tight enough to force real cuts, wide enough to be a promise we keep. A product that cannot freeze at eight usually has an untested one action, not a scheduling problem.
What happens after week eight?
The Friday demo becomes the evidence meeting after launch: manual pile hours, form completion numbers and the parked list, looked at together. Version two is then a normal decision with data behind it. If the one action did not survive contact with customers, the honest outcome is a rework of the core loop, not more features on top of it.