Most advice about MVPs says "keep it minimal" and stops there, which isn't much help when you're staring at a blank page trying to decide what actually makes the cut. Here's a more useful way to think about it.
Start with the one thing, not the whole product
An MVP isn't a smaller version of your finished product. It's the smallest possible thing that lets a real person do the one core action your business depends on, end to end, with nothing simulated. If you're building a booking platform, that's a real person booking a real slot, not a polished homepage with a "coming soon" booking button.
Everything else, the account settings, the admin dashboard, the referral system, the seventeen integrations on your roadmap, comes after you've proven the one thing works and people actually want it.
What you genuinely need before you start
A decision on the one action. If you can't say in one sentence what a user does in your MVP, that's the first thing to resolve, before any design or development conversation.
Realistic scope discipline. The most common way MVPs fail isn't bad code, it's scope creep: "while we're at it, let's also add...". A good build partner will be honest, sometimes bluntly so, about what to leave out of version one.
A plan for the boring infrastructure. Authentication, payments, a basic admin view so you can actually see what's happening, these aren't optional extras, they're usually part of the minimum, even though they're not the exciting part of the product.
Clarity on what happens after launch. An MVP is the start of learning, not the end of building. Decide upfront how you'll actually watch what real users do with it, not just how many sign up.
What you can safely skip for version one
- Advanced customisation and settings most users will never touch in week one.
- A polished design system across every possible screen state.
- Every integration mentioned in early customer conversations. Build for the two or three that actually block someone from using the core feature.
- Scaling infrastructure for problems you don't have yet.
Fixed price versus hourly, and why it matters more than it sounds
An MVP scoped properly, with the boundaries agreed before work starts, should have a fixed price attached to it, not an open-ended hourly estimate. If a build partner can't tell you roughly what it'll cost and roughly how long it'll take once the scope is agreed, that's usually a sign the scope isn't actually agreed yet.
Who should own the code
This matters more than founders often realise early on: you should own the repository, the infrastructure and the IP from day one, on a mainstream, well-understood stack (not an obscure proprietary platform that locks you into one agency forever). That's what lets you bring development in-house later, switch partners, or hand it to a technical co-founder without starting from scratch.
The realistic timeline
A properly scoped MVP, built on a modern stack with the boring infrastructure (auth, payments, a basic admin view) already handled rather than reinvented, typically takes somewhere in the region of six to twelve weeks from a confirmed scope to real users on it. Anything promising "an app in a weekend" is usually promising a prototype, not something you'd put in front of paying customers.
The actual goal
The point of an MVP isn't to look impressive. It's to get the smallest true version of your idea in front of real users as fast as honestly possible, so you find out what's actually worth building next before you've spent a year building the wrong thing beautifully.
If you're at that stage, the startups page covers how WebAscend approaches MVP builds specifically, and the pricing page has the packages that tend to fit a first build.