Andrew Crossley
    6 WEEKS · £12K-£25K

    Build an MVP

    An MVP is the smallest version of your product that lets a real customer complete one valuable journey end to end, well enough that you can measure whether they come back. It is not a prototype, not a pitch deck feature, and not 'version one of the full vision' — it's a single journey, built properly, shipped in weeks not months. Done well, a focused MVP takes six weeks and £12,000 to £25,000 with a fractional CPO working alongside AI-assisted engineering; done badly, it takes six months and never ships at all.

    WHO THIS IS FOR

    Signs you're ready to build, or about to build the wrong thing

    • You have a spec document that's grown to 40 pages before a single line of code has been written.
    • Your 'MVP' includes three user roles, a billing system and an admin dashboard before you've had one real customer use it.
    • You've been quoted £80,000+ and four months by an agency for something you suspect should take six weeks.
    • You've tried a no-code tool but hit a wall the moment the logic got slightly non-standard.
    • You know the one journey that matters but keep getting pulled into building the journeys around it instead.
    • You have engineers or a no-code budget but no one deciding what to leave out, so everything stays in.

    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

    WHAT THE WORK COVERS

    What has to be true before you start building

    Most MVPs that fail, fail before the first line of code — the scope was wrong, not the execution. These four checks take a day to run and save weeks of rework.

    One journey, named

    You can state the single user journey your MVP proves in one sentence: 'a driver posts a carpool trip and a rider books a seat', not 'a platform for community transport'. If you can't say it in one sentence, you're not ready to scope the build.

    One metric, agreed

    You know exactly what number tells you the MVP worked — completed bookings, activated accounts, repeat usage within 7 days. Agree it before you build, not after, or you'll retrofit a metric that flatters whatever shipped.

    The build vs buy line drawn

    Auth, payments, email, file storage — decide upfront which of these you're buying off the shelf (Clerk, Stripe, Resend, S3) rather than building. Every one you build yourself instead of buying is a week you don't get back.

    A cut list, written down

    Before week one starts, write down the ten features you are deliberately not building yet, and why. This is the document that stops scope creep in week three when someone remembers a 'quick addition'.

    HOW IT RUNS

    The six-week plan, week by week

    1. Week 1

      Scope and skeleton

      Lock the one journey, the one metric and the cut list. Stand up the technical skeleton: hosting, auth, database schema for the core objects only, CI/CD from day one so every later week ships to a real URL.

    2. Week 2

      The core journey, ugly

      Build the single journey end to end with no styling and no edge cases handled. The goal is proving the data flows correctly, not that it looks good. If you can't click through it by Friday, the scope was still too big.

    3. Week 3

      Make it usable

      Add the error states, empty states and the two or three edge cases that will actually occur (what happens when there's no data yet, what happens when the action fails). Basic styling using an existing component library, not custom design.

    4. Week 4

      Instrumentation and payments

      Wire up analytics events against the one metric you agreed in week one. If the MVP charges money, integrate Stripe now, not later — pricing friction is part of what you're testing, not an afterthought.

    5. Week 5

      Closed beta

      Ship to 10-20 real users, not friends and family. Watch session recordings, run 3-5 follow-up interviews on where they got stuck. Fix only what blocks the core journey; log everything else.

    6. Week 6

      Launch checklist and public release

      Run the launch checklist (below), fix anything that fails it, and open access publicly or to your waiting list. Instrumentation dashboard live from day one of public launch so you're reading data, not guessing.

    PRICING

    MVP build cost bands

    Costs below are for a focused, single-journey MVP built by a fractional product leader working directly with AI-assisted engineering — not a full agency team building a broad spec. Scope, not hours, is what drives the range.

    Discovery sprint first

    £4,000

    Two weeks to validate the journey and metric before committing build budget — recommended if you're not yet certain which journey matters most.

    Core MVP build

    £12,000-£18,000

    One journey, standard integrations (auth, payments, email), instrumented, shipped to a closed beta within six weeks.

    MVP with a second surface

    £18,000-£25,000

    Core journey plus a genuinely necessary second surface — an admin view, a second user role, a native mobile wrapper — scoped tightly and still shipped inside six to eight weeks.

    Building rather than hiring? Get a number in 60 seconds with the MVP cost calculator.

    COMPARISON

    DIY with AI tools vs fractional-led build vs agency

    All three can produce a working MVP. They differ in what they're good at protecting: your cash, your time, or your certainty about what to build.

    FactorFractional-led buildDIY (no-code/AI tools) & agency
    Typical cost£12,000-£25,000, fixed scopeDIY: near-£0 tool cost but 100+ founder hours. Agency: £40,000-£100,000+
    Typical timeline6 weeks to closed betaDIY: 2-6 months, often stalling. Agency: 3-6 months including sign-off cycles
    Scope disciplineOne journey enforced by someone whose job is saying no to additionsDIY: scope creeps because nobody's pushing back. Agency: scope creeps because more scope means more billable hours
    Who decides what to cutA product leader who has shipped MVPs before and owns the outcomeDIY: the founder, without the pattern-matching from prior builds. Agency: a project manager optimising for the contract, not your metric
    Technical ceilingProduction-grade code, can hand to permanent engineers laterDIY: hits a wall on custom logic or scale. Agency: high ceiling but slow to adapt mid-build
    Best forFounders who know roughly what to build and need it built right, fastDIY: testing an idea for near-zero cost before any spend. Agency: well-funded teams building a broad, defined spec

    PROOF

    MVPs I've actually shipped

    Wocal — from zero to 300+ venues

    As founder and CPO (2020-2025) I scoped and shipped the original hospitality SaaS MVP around one journey — a venue owner running their front-of-house from a single screen — before adding a single extra feature. It grew to 300+ venues and a £2.7M pre-money valuation.

    Co-Ride — six-week build in progress

    As founder and CPO since November 2025, Co-Ride's MVP is being built on exactly this plan: one journey (post a trip, book a seat), off-the-shelf auth and payments, and a closed beta before public release.

    Just Eat, 2021-2025

    At marketplace scale, the discipline of shipping the smallest working version of a two-sided flow and instrumenting it properly is the same discipline that makes a seed-stage MVP succeed — the stakes are lower but the mechanics don't change.

    Sage and Echo-U

    Enterprise SaaS and contact-centre work is where I learned that an MVP without proper instrumentation from week one is just an expensive guess — you find out it failed weeks later than you needed to.

    What actually counts as an MVP

    An MVP is the smallest version of your product that lets a real customer complete one genuinely valuable journey, well enough that you can measure whether they come back and do it again. The operative word is 'one'. Not the core three journeys you eventually need — one. The discipline of an MVP is entirely in what you leave out, not what you include.

    It is not a prototype. A prototype (a Figma click-through, a no-code mockup) tests whether people understand the concept. An MVP is real, running software that a customer actually uses to get something done, with real data and real consequences if it breaks. If nobody can lose or gain anything real by using it, it's a prototype, not an MVP, and you should call it that.

    It is also not a stripped-down version of your five-year vision. Founders frequently build an MVP that includes three user roles, an admin panel and a billing system because 'we'll need all of it eventually'. Eventually is not now. The test for whether something belongs in the MVP is not 'will we need this' — you will need almost everything eventually — it's 'does the single journey break without it'. If the journey works without it, cut it.

    Choosing the one journey: the exercise that saves six weeks

    Write down every journey your product could plausibly support. For a carpooling app that's: post a trip, book a seat, message a co-rider, rate a trip, manage recurring trips, handle payments, report an issue, and more. Most founders try to build six of these in the first release. Pick one.

    The right one is usually the journey that, if it worked perfectly and nothing else existed, would still make someone use the product again next week. For a marketplace it's almost always the core match — one side posting, the other side booking or buying — not the surrounding features like ratings or messaging, which matter enormously later but don't test whether the core exchange has value.

    A useful forcing test: if you had to launch tomorrow with only one screen, which one would it be? Whatever you answer is the journey. Everything else — settings, profile editing, notifications preferences, admin tooling — gets a line in the cut list, dated, so it can be revisited once the core journey is proven, not before.

    No-code vs AI-assisted code vs agency: choosing the right build route

    • No-code (Bubble, Softr, Glide) suits founders testing a concept for near-zero cost with simple, mostly-standard logic — a form, a list, basic workflows. It breaks down fast once you need custom business logic, non-trivial permissions, or anything that needs to scale past a few hundred users; migrating off it later is expensive and often means a full rebuild.
    • AI-assisted code (a fractional product lead or senior engineer working with tools like Cursor, Claude Code or similar) is the middle path: production-grade code from day one, at a fraction of traditional build time because the tooling handles boilerplate, and someone experienced is still making the judgement calls about what to build. This is the route that produces a real six-week, £12k-£25k MVP.
    • Agencies suit a well-funded team with a broad, already-validated spec and no internal technical leadership — you're buying a team and a process, not just code. The cost is usually 3-5x an AI-assisted fractional build and the timeline is 3-6 months including the sign-off cycles agencies build in to manage their own risk, which is often more process than a single-journey MVP actually needs.
    • The wrong choice in either direction is common: using no-code for something with genuinely custom logic wastes months hitting walls, and hiring a full agency for a single-journey MVP means paying for a process built for much bigger scope than you have.

    What to instrument before you launch, not after

    • The one activation event that proves the core journey completed — a trip posted, a booking confirmed, an account upgraded. Wire this up in week 4, not as a retrofit once you notice you have no data.
    • A 7-day and 30-day return metric tied to a specific user, not just aggregate traffic. Vanity metrics like page views tell you nothing about whether the MVP is working; return usage tells you almost everything.
    • Drop-off points inside the core journey itself — where in the flow people abandon, not just whether they finished. A funnel with three steps and the drop-off at each is worth more than a single conversion percentage.
    • Session recordings (Hotjar, PostHog or similar) for at least the first 50 users, watched personally, not just reviewed as aggregate heatmaps. The specific moment someone hesitates tells you more than any dashboard number.
    • A simple feedback capture inside the product itself — one question, asked at the moment of use, not a separate survey emailed a week later when the context is gone.

    The launch checklist

    • The core journey has been completed successfully by at least ten people outside your immediate team and network.
    • Every error state in the core journey shows a message a real user could understand and act on — no raw error codes or blank screens.
    • Payments, if applicable, have been tested with a real card in production, not just Stripe test mode.
    • The activation event and at least one retention event are firing correctly and visible on a dashboard you can check without asking an engineer.
    • There's a way for a user to report a problem that reaches a human within a working day.
    • You have a rollback plan — you can disable or fix a broken core journey within the hour, not the week.
    • You know the one number you're checking every day for the first two weeks post-launch, and who's checking it.

    What an MVP costs, and why the range is so wide

    A focused, single-journey MVP built with a fractional product lead working alongside AI-assisted engineering typically costs £12,000 to £25,000, delivered inside six to eight weeks. The variation within that range is driven almost entirely by scope discipline, not by team seniority or tooling — a tightly scoped single journey with off-the-shelf auth and payments sits at the bottom; a second necessary surface (an admin view, a second role, a native wrapper) moves it toward the top.

    The comparison points matter. DIY with no-code tools costs close to nothing in cash but consumes 100+ hours of founder time and frequently stalls on custom logic, meaning the true cost is time and a real risk of never shipping. An agency quote for the equivalent single-journey MVP typically runs £40,000-£100,000+, because agency pricing is built around a team structure and process designed for much larger scopes, and includes sign-off cycles that a six-week build doesn't need.

    The number that should worry you more than the build cost is the cost of building the wrong thing. A £15,000 MVP that tests the right journey and tells you clearly it doesn't work has done its job. A £15,000 MVP built without a discovery step first, that turns out to solve a problem nobody has, has cost you the build fee plus the six weeks you can't get back — which is why a discovery sprint before the build, at £4,000, is often the cheapest insurance available.

    FREQUENTLY ASKED

    Build an MVP questions

    What is an MVP?
    An MVP is the smallest version of a product that lets a real customer complete one valuable journey end to end, built well enough that you can measure whether they use it again. It's real running software, not a prototype, and it deliberately excludes everything that isn't the core journey.
    How long does it take to build an MVP?
    A focused, single-journey MVP typically takes six weeks from locked scope to closed beta, using a fractional product lead working with AI-assisted engineering. Broader scopes or agency-led builds commonly take three to six months.
    How much does it cost to build an MVP?
    A single-journey MVP built with a fractional product lead and AI-assisted engineering typically costs £12,000 to £25,000. Agencies quoting the equivalent scope commonly charge £40,000 to £100,000 or more due to team structure and process overhead.
    Should I use no-code or write custom code for my MVP?
    No-code suits simple, mostly-standard logic and near-zero budget testing but breaks down once you need custom business logic or scale. AI-assisted custom code delivers production-grade software at a similar speed for a modest cost premium and doesn't hit the same ceiling later.
    How do I choose which feature to build first for an MVP?
    Pick the single journey that, on its own, would make a customer use the product again next week even if nothing else existed. Ask yourself which one screen you'd launch with if you had to launch tomorrow — that's the journey to build first.
    What should I track once my MVP is live?
    At minimum: an activation event that proves the core journey completed, a 7-day and 30-day return metric per user, and drop-off points within the journey itself. Wire these up before launch, not after, or you'll be guessing why usage is flat.
    Is an agency or a fractional product lead better for building an MVP?
    A fractional product lead working with AI-assisted engineering is usually faster and cheaper for a single-journey MVP, at roughly a third to a fifth of typical agency cost, because agencies are structured for broader scopes with heavier process. Agencies suit well-funded teams with an already-validated, wider spec.
    What comes after the MVP launches?
    Instrument and watch the one metric you agreed before building for two to four weeks, run follow-up interviews with early users, and only then decide the next journey to build — resisting the urge to add features based on requests rather than evidence of the core journey working.

    GET IN TOUCH

    Tell me about the MVP you need built

    A short note about the journey you want to prove and your timeline is enough. I reply within 48 hours.

    Your details are used only to reply to you and are never sold or shared. See the privacy policy.