An MVP Is A Decision About What Must Work
A website MVP is not the answer to which features do we want? It is the answer to what is the smallest behaviour the first version must support?
Every extra function is a door. Each door needs a key, a lock, a destination, and someone responsible when it breaks. Do not add doors unless the first version truly needs them.
This low-level guide expands the Building Functional Scope step in Prepare Website Inputs. Use it after Defining the Website Type, and before the build moves into Build the Website.
Steps
Guide
Name The One Thing Visitors Must Do
Do not begin with features. Begin with what the visitor must successfully do.
- Should the visitor contact you?
- Should they understand a service?
- Should they compare options?
- Should they read articles?
- Should they request a demo?
- Should they download something?
- Should they use a small tool?
The first version should have one primary action. Secondary actions can exist, but they should not compete with it.
If the action is unclear, the builder or AI coding agent will fill the gap with layout guesses.
Sort Ideas Before They Become Work
Sort every idea into four buckets before anyone starts building:
- must have
- should have
- could have
- not now
A must-have is something the first version fails without. A should-have is useful, but not launch-breaking. A could-have is a later improvement. Not now is deliberately out of scope.
This is a decision step, not admin. It stops every small idea from becoming a new door with its own rules, errors, owner, and maintenance.
Write Functions In Plain Language
For every must-have function, write what it does in normal words. Avoid technical labels on their own.
Weak: contact form.
Better: visitor can send name, email, company, message, and consent; the form validates required fields; the message goes to the business inbox; the user sees a success state.
The better version is not a technical spec. It names the visitor action, destination, success state, and owner.
Use plain language because it is harder for the builder or AI agent to hide invention behind jargon.
Choose The Smallest Door
Most website scope problems happen when a simple action turns into a custom system.
Examples:
- contact form MVP: send a validated message to an inbox. Not first version: full CRM automation, lead scoring, routed notifications, and nurture journeys.
- booking MVP: link to Calendly, SavvyCal, or an existing booking page. Not first version: custom calendar, availability engine, reminders, and admin panel.
- payment MVP: collect a request and send a manual invoice, or link to a confirmed Stripe checkout. Not first version: custom cart, tax logic, accounts, refunds, and payment dashboard.
Mini-case from vague request to scoped first version:
Bad input:
* We need a website with contact, booking, payments, CRM, blog, login, analytics.
Good MVP decision:
* First version: service landing page + validated contact form to inbox + existing Calendly link + basic analytics if consent text is approved. No login, CRM automation, or payments.Choose the smallest door that supports the first version. Bigger doors can wait.
Confirm Integration Certainty
Integrations are not tiny details. A form needs a destination. Booking needs a tool. Payment needs rules. Analytics needs consent and ownership.
Before the build starts, mark each integration as one of these:
- confirmed
- optional
- unknown
- blocked
If an integration is unknown, do not let the builder invent it. Use a placeholder path: mailto link, static CTA, normal contact form, existing booking link, or manual request flow.
Define Done Before Build Starts
A good MVP website is the smallest version that can be reviewed honestly.
Each must-have function needs a simple acceptance check:
- the contact form shows validation before submission
- the CTA leads to the correct destination
- the page works on mobile and desktop
- the navigation exposes the important pages
- search engines can understand the important content
- the page loads without obvious performance problems
- missing legal or tracking decisions are not hidden
Acceptance checks protect the first build from polished nonsense. They tell the builder what done means.
- 7
Write The Build Decision
Read GuideEnd with one compact decision, not a long wish list.
The decision should say:
- main action
- must-have functions
- should/could/not-now functions
- confirmed integrations
- unknown or blocked integrations
- acceptance checks
Now the first build has a shape. The builder knows what to build, what to avoid, and when to stop and ask.
Scope Decisions To Watch
Everything becomes must-have.
Ask whether the first useful version fails without it. If not, move it to should-have, could-have, or not-now.
The website type and functionality do not match.
Return to the website type decision. A blog, landing page, portfolio, campaign page, and product site need different functionality.
Integrations are vague.
Mark them as unknown or blocked. Use a simple placeholder path until the destination, credentials, owner, and rules are confirmed.
The AI coding agent adds polished extras.
Give the agent the not-now list and acceptance checks. Tell it to stop before adding unrequested functionality.
Return to the Main Guide?
Main guide
Prepare Website Inputs
MVP Functionality Decision
Copy / paste
Use this decision brief to define the MVP website functionality before build work starts.
#### Website Basics
* Website type:
* Example: landing page, product site, portfolio, SEO blog, campaign page, subdomain page
* Main user action:
* Example: contact us, request demo, read articles, compare options, subscribe, book, download
* First version goal:
* Example: publish a useful first version that explains the offer and captures qualified enquiries
#### Priority Buckets
* Must have:
* The website fails without this
* Should have:
* Useful, but not launch-breaking
* Could have:
* Nice later improvement
* Not now:
* Deliberately excluded from the first version
#### Must-Have Functions
For each must-have function, fill this in:
* Function name:
* Visitor action:
* Smallest acceptable version:
* Destination or owner:
* Success state:
* Failure or empty state:
* Acceptance check:
#### Smallest Door Examples
* Contact:
* MVP option: validated form to inbox
* Not now: CRM automation unless confirmed
* Booking:
* MVP option: existing booking link
* Not now: custom booking system unless confirmed
* Payment:
* MVP option: request flow, invoice, or confirmed Stripe checkout
* Not now: custom payment dashboard unless confirmed
#### Before / After Scope Example
Bad input:
* We need a website with contact, booking, payments, CRM, blog, login, analytics.
Good MVP decision:
* First version: service landing page + validated contact form to inbox + existing Calendly link + basic analytics if consent text is approved. No login, CRM automation, or payments.
#### Integrations
For each integration, mark one status: confirmed, optional, unknown, or blocked.
* Forms:
* Email destination:
* Newsletter:
* Booking:
* Payment:
* Analytics:
* Consent:
* Search:
* Login or account area:
* CRM or automation:
#### Unknowns And Blockers
* Unknown business decisions:
* Unknown legal decisions:
* Unknown technical decisions:
* Missing credentials:
* Missing content:
* Missing approvals:
#### Builder Instruction
Build only the must-have functions for the first version. Do not add should-have, could-have, or not-now items unless they are explicitly approved. If a required integration, destination, credential, legal text, or owner is unknown, stop and ask instead of inventing functionality.