Andrew Crossley

    How do you build an MVP?

    SHORT ANSWER

    Build an MVP by picking one job a specific user will pay to have done, designing the single shortest flow that completes it, and shipping only that. Validate demand before building — interviews plus a paid or committed signal. Build in four to six weeks with off-the-shelf infrastructure, launch to a narrow group, and measure whether they complete the job and come back.

    Answered by Andrew Crossley, Fractional Chief Product Officer · Updated 2026-08-01

    Why it matters

    Most first products fail on scope, not on code. Teams build six half-features instead of one that finishes a job.

    An MVP exists to produce evidence. If it cannot change your mind about the business, it is not an MVP — it is a version one.

    How it works in practice

    1. 1

      Write the one job

      One sentence: who, what outcome, in what situation. If it needs two sentences, the scope is already too wide.

    2. 2

      Validate before you build

      Ten to fifteen problem interviews plus a commitment signal — a deposit, a signed pilot, a waiting list with real intent.

    3. 3

      Design the single flow

      Map entry to outcome in the fewest steps. Every screen that does not sit on that path is out of scope for v1.

    4. 4

      Build with boring infrastructure

      Managed auth, managed database, hosted AI models. Custom infrastructure at MVP stage is capital spent on the wrong risk.

    5. 5

      Launch narrow and instrument

      Twenty to fifty users who match the profile exactly. Track activation, time-to-value and week-four return.

    6. 6

      Decide with the data

      Persevere, pivot the job, or stop. Set the thresholds before launch so the decision is not emotional.

    Common mistakes

    • Building for a broad audience so nobody feels it was made for them.
    • Adding accounts, billing, admin panels and settings before anyone has completed the core job once.
    • Skipping instrumentation, then arguing about anecdotes after launch.
    • Treating an MVP as a smaller version of the eventual product rather than an experiment.

    FROM EXPERIENCE

    Cutting an MVP down to one flow

    A typical first scope arrives with onboarding, dashboards, team accounts, notifications and reporting. Cutting to one flow — sign in, complete the job, see the result — usually removes 70% of the build and none of the learning.

    At Wocal the version that mattered was the one that did a single thing end to end. Everything on the roadmap around it could wait, and most of it never needed building.

    Frequently asked

    How long should an MVP take?

    Four to eight weeks for most software MVPs with modern tooling. Longer usually means the scope was never cut.

    Do I need a technical co-founder to build one?

    No. AI-assisted build tools and a fractional product partner can get a first version live without an in-house engineer.

    Should an MVP charge money?

    Where possible, yes. Payment is the cleanest validation signal there is.

    IN SHORT

    • One job, one flow, one user profile.
    • Validate with interviews plus a commitment signal before building.
    • Four to eight weeks, boring infrastructure, narrow launch, pre-set decision thresholds.

    Idea to MVP in six weeks

    A validated, instrumented first product in front of real users.

    Idea to MVP in six weeks

    THE FRAMEWORK

    The Crossley Method: idea to first revenue in seven stages

    See the full method
    1. STAGE 1DiscoverWeek 1
    2. STAGE 2ValidateWeek 2
    3. STAGE 3PrototypeWeek 3
    4. STAGE 4Build MVPWeeks 3-4
    5. STAGE 5LaunchWeek 5
    6. STAGE 6First RevenueWeek 6
    7. STAGE 7ScaleOngoing