Skip to main content
Start a conversation

Urgent delivery tool

Seven-day MVP eligibility checklist

A rapid MVP is not a smaller promise about a large programme. It is a decision to prove one useful workflow under explicit conditions.

When to use this

Use this before asking a team to quote or commit to a one-week MVP. It is designed to reveal the missing condition early, not to force every brief into the same timetable.

  1. 01

    One user, one decisive workflow

    Name the user group, trigger, action, output and decision that the MVP must prove. If the brief has several audiences or unrelated workflows, separate the first release.

  2. 02

    Explicit exclusions

    List what is not in the release: roles, integrations, historic data, channels, reports, automation decisions and non-essential polish. An exclusion is a delivery control, not a weakness.

  3. 03

    Authorised access on day one

    Confirm code, environment, API, representative data, supplier contacts and necessary approvals. If access is pending, make the first phase an assessment or safe demonstrator rather than imply a production integration.

  4. 04

    A named decision-maker

    Identify who can resolve scope, risk and acceptance questions during the build. A delivery team cannot recover time lost to an unavailable approval path.

  5. 05

    A testable acceptance condition

    Write the result that will be checked: a user completes a workflow, an integration returns an agreed response, or a reviewer assesses an evaluation threshold and exception path.

  6. 06

    A credible next decision

    Agree who reviews the evidence at the end of the window and whether the next step is a pilot, iteration, wider delivery plan or a stop decision.

Applied guidance

Use the tool as a decision record, not a box-ticking exercise.

01

Turn urgency into a single decision

A seven-day window is useful only when it is attached to one question that a sponsor can answer at the end of it. For example: can a coordinator complete an intake, see the information needed to prioritise it, and create a reviewable next action? That differs from asking whether an entire operational department can be transformed in a week. Write the decisive moment in plain language, identify the user who owns it, and state what would count as a useful outcome. This gives engineers a stable target when ideas, requests and stakeholder concerns begin to arrive during the build.

02

Distinguish a demonstrator from an MVP

A demonstrator may show an interaction with prepared inputs. An MVP should let a defined user complete an agreed workflow with real or authorised representative conditions and known limitations. The distinction matters because it changes the questions about access, exception handling, data quality, support and acceptance. A team can begin with a demonstrator if access is not ready, but should label it accurately. Calling it an MVP before it has the necessary operating boundary creates false expectations and makes later work look like delay rather than the planned step from an example to a usable product.

03

Protect the critical path

The critical path usually includes more than engineering: a person must provide access, answer a policy or data question, confirm an acceptance condition, and make a timely decision when a trade-off appears. List those dependencies at the start, with a named owner and the date by which each is needed. Where a dependency cannot be resolved, use a deliberate fallback such as mocked data, a narrower workflow, a technical assessment or a demonstrator. Do not quietly substitute assumptions for access. That preserves the credibility of the work and makes the sponsor’s role in a rapid timetable explicit.

04

Choose evidence that a sponsor can inspect

The end-of-week review should not depend only on a polished walkthrough. Agree in advance what will be shown: a user completing the bounded task, a record of how invalid input is handled, an integration response under agreed test conditions, or an AI evaluation with the relevant exception route. Capture known exclusions alongside the evidence. A small evidence record makes it easier for a sponsor to choose the next step and prevents a successful happy-path demonstration from being interpreted as proof that every edge case, system or user group has been covered.

05

Leave a usable next-step record

A rapid MVP should produce more than software. It should leave a short record of the workflow proved, configuration or release reference, data and supplier dependencies, unresolved questions, user feedback, and the decision required next. That record may support a 30-day controlled pilot, an iteration, a wider estimate or a stop decision. It is especially important when an urgent project uses provisional data or temporary access. The team can then explain clearly what must be strengthened before people rely on the product more widely, rather than treating the first delivery as a permanent endpoint.

06

Agree the delivery language

Before a rapid build starts, sponsors and delivery teams should agree the terms used in the conversation. ‘MVP’, ‘pilot’, ‘production’, ‘launch’, ‘integrated’ and ‘secure’ can mean very different things to different people. The brief should state what the chosen term means in this engagement, which conditions are still outstanding, and what will be demonstrated at the review. This small discipline protects both the customer and the team: it prevents an early workflow proof from being mistaken for an unrestricted deployment, and it gives commercial, technical and operational stakeholders one shared basis for approving the next step.

Working prompts to adapt

Workflow to prove

For [user], when [trigger] occurs, the MVP helps them [action] so that [decision/outcome] can be assessed.

Acceptance

The release is ready to review when [observable test] is complete, including [known exception or human review].

Conditions

Before work begins we have [access], [owner], [data/input], [budget/capacity] and [approval route].

Related routes

Continue the delivery decision

01AI MVP development0230-day AI pilot entry criteria03Product engineering capability

Primary guidance