MVP Development UK: What a Sensible Six-to-Twelve-Week Scope Looks Like

Most founders underestimate how much they can strip back and still prove their core hypothesis. A proper MVP isn't a cut-down version of your dream product—it's the smallest thing you can put in front of real users to learn whether your fundamental assumption holds water. In the UK market in 2026, a sensible six-to-twelve-week MVP scope means making some hard choices about what stays and what goes.

The six-week sweet spot

Six weeks gives you roughly 30 working days. Subtract discovery, design, deployment, and testing, and you're looking at perhaps 18–20 days of actual build time. That's enough for one core workflow, done properly.

A sensible six-week scope typically includes:

• One primary user journey, end to end
• Basic authentication (often via a third-party provider like Auth0 or Clerk)
• A simple data model with three to five main entities
• One or two integrations if they're central to the value proposition
• Minimal admin functionality—often just direct database access for the team
• Responsive web interface or a single native platform, not both

What you're explicitly leaving out: onboarding flows, email notifications, user settings, team features, billing, analytics dashboards, and anything that starts with "it would be nice if".

The constraint is clarifying. If you're building a marketplace, you're choosing whether to focus on the buyer experience or the seller experience first, not both. If you're building a SaaS tool, you're proving that one workflow saves time or money, not that your product can handle every variation of the problem.

Stretching to twelve weeks

Twelve weeks isn't double the scope of six weeks—it's perhaps 50% more feature surface, because the overhead doesn't scale linearly. You're still building one product with one core workflow, but you can afford a bit more polish and one or two supporting features that make the main journey more credible.

In a twelve-week engagement, you might add:

• A second user type or role, if it's essential to proving the model
• Transactional emails for critical actions
• Basic payment processing, if revenue is the hypothesis you're testing
• A simple content management capability
• More sophisticated error handling and edge cases
• Light analytics—enough to see what users are actually doing

You're still not building a settings page with notification preferences. You're still not building a mobile app and a web app. You're still saying no to most things.

The extra time also gives you room to handle one or two technical decisions that matter for the long term. You might set up proper CI/CD pipelines, write a handful of integration tests for critical paths, or structure your database schema to avoid painful migrations later. These aren't features users see, but they're the difference between an MVP that can evolve and one that needs rebuilding at the first sign of traction.

What "done properly" means in 2026

The tooling available to UK development teams in 2026 has raised the bar for what "properly" means, even in an MVP. Users expect:

• Fast page loads and smooth interactions
• Sensible mobile behaviour, even if it's just a responsive web view
• Secure authentication without friction
• Data that persists reliably
• Interfaces that don't look like a developer built them

You can meet these expectations without gold-plating. Modern frameworks like Next.js, Remix, or SvelteKit give you performance by default. Component libraries like shadcn/ui or Radix provide accessible, good-looking interfaces without custom design work. Platforms like Vercel, Railway, or Fly.io handle deployment complexity.

The discipline is in choosing a stack that's productive for your team and then not deviating from it. Every custom solution, every "we'll just build our own" decision, eats into your feature budget.

This also means accepting that some technical choices are more pragmatic than perfect. Using Postgres instead of the theoretically optimal database for your use case. Storing files in S3 rather than evaluating five different storage providers. Reaching for established libraries instead of writing bespoke code. The goal is to ship and learn, not to architect for scale you don't have yet.

The features you're not building

It helps to be explicit about what a six-to-twelve-week MVP doesn't include:

• Multi-language support
• Comprehensive admin dashboards
• Audit logs and activity feeds
• Password reset flows (use magic links)
• User-uploaded avatars
• Real-time collaboration features
• Sophisticated permissions models
• API documentation
• Webhook systems
• CSV exports
• Dark mode

Some of these feel essential. None of them are. You can add them later if the core hypothesis proves out.

The test is simple: if removing a feature means you can't answer your core question, it stays. If it's about convenience, polish, or a future version of the product, it goes. A founder testing whether busy professionals will pay for curated research summaries doesn't need user avatars or dark mode. They need a way to deliver summaries, accept payment, and measure whether people come back.

How to stay in scope

The main threat to a sensible MVP scope is feature creep disguised as necessity. "We need to let users invite team members" becomes "we need teams, roles, permissions, and billing by seat". What you actually need is to manually add a second login for a beta customer's colleague.

Staying in scope means:

• Writing down the one question this MVP must answer
• Doing manually what you'd eventually automate
• Choosing boring, productive technology
• Designing one happy path, not every edge case
• Accepting that some things will feel unfinished

An MVP that ships in six weeks and gets used is worth more than a polished product that takes six months and launches to silence.

Manual processes are your friend in the early days. Customer signs up and needs onboarding? Send them a Calendly link. User wants to export their data? Run a SQL query and email them a CSV. Someone requests a feature? Add it to a Notion page, not your roadmap. You're buying time to learn whether the core product works before you automate the periphery.

The validation question

Every feature decision should trace back to your validation question. If you're testing whether accountants will use an AI tool to draft compliance documents, your MVP needs document generation, basic editing, and a way to measure accuracy and time saved. It doesn't need version history, collaborative editing, or template libraries.

If you're testing whether small retailers will pay for inventory forecasting, you need data import, a forecasting algorithm, and clear output they can act on. You don't need multi-location support, custom reporting, or integrations with every point-of-sale system.

The validation question keeps you honest. When someone suggests a feature, ask: does this help us answer the question, or does it feel like something the finished product should have? The latter can wait.

Where MTE fits

We run focused MVP builds for UK founders and product teams who need to move quickly without cutting corners on the fundamentals. Our typical engagement is eight to ten weeks—long enough to build something credible, short enough to maintain urgency. We'll help you draw the scope lines, choose a stack that won't trap you later, and ship something you can actually put in front of users. If you've got a hypothesis worth testing, we'll help you build the smallest thing that can test it properly.