Scoping an MVP: What to Build First and What to Cut

Most founders spend six months planning a product only to realise halfway through build that they’ve included features nobody asked for. The cost of that mistake isn’t just wasted time-it’s momentum lost, cash burned, and market timing blown. An MVP isn’t a miniature version of your final product. It’s a focused bet on a specific problem for a specific group of people.

Getting scoping right means being ruthless about trade-offs. This is where most projects fail.

Start with the core job, not the vision

Your product exists to solve one job for one type of user. Not five jobs. Not “eventually for everyone.” One.

A fintech we worked with wanted to build a spending analytics platform. Their initial scope included investment advice, tax optimisation, budgeting, savings goals, and peer comparison. That’s five separate problems. The MVP question was simple: what’s the smallest version that lets someone answer a question they care about?

The answer: show me where my money actually goes. That’s it. No forecasting, no comparisons, no optimisation tips. Just transparent categorisation of transactions and a clear picture of spend by category.

That clarity matters because:

• You can validate whether the core job is something people will actually use (not just say they’ll use).
• You reduce build complexity by 60-70% because you’re not engineering for edge cases that don’t exist yet.
• You ship faster and start learning from real users instead of hypothetical ones.
• You have a foundation to add features to, not a bloated platform that needs three rewrites before it’s coherent.

Define your core job in one sentence. If you need more than that, you haven’t narrowed it down enough.

Who’s your actual user, and what’s their constraint?

Not “SaaS founders” or “small businesses.” Be specific. You’re building for the operations manager at a 10-50 person tech startup who spends 8 hours a week in spreadsheets, not the CFO of a Fortune 500 who has a dedicated accounting team.

That specificity changes everything about what you build.

If your user is time-constrained, you optimise for speed. If they’re cost-constrained, you build around affordability. If they’re technically unsophisticated, you strip out advanced options and focus on clarity. If they’re managing complexity, you build scaffolding that helps them organise information.

A SaaS product we scoped recently was targeting agencies. The team’s first instinct was to build a full-featured project management system: timesheets, resource allocation, budgeting, client billing, custom workflows, integrations with 20+ tools. Six-month build. The actual constraint their target user had? They were managing projects across three or four tools (email, Slack, a spreadsheet, and Asana) and wasting two hours daily finding context. The MVP: a single dashboard that pulls project data from their existing tools, shows what’s due today, and tells them where they should focus. Three weeks to build. Same value delivered, fraction of the scope.

Ask yourself:

1. Who are we building this for? (Title, industry, company size.)
2. What’s the specific problem they’re solving today, probably badly?
3. What’s the constraint that makes them hate their current approach? (Time, cost, accuracy, mental load.)
4. What’s the smallest thing we could show them that proves we understand that constraint?

Cut ruthlessly: the features you think you need but don’t

Most founders include features for three reasons: they’re standard in competitors’ products, they think they might be useful later, or they’re technically interesting to build. None of these are good reasons for an MVP.

Here’s what almost always ends up in scope and almost always should be cut:

• Integrations with third-party tools. Yes, your users probably use Zapier or Slack or Salesforce. But you can send them an email or CSV first. Build the integration after you’ve validated the core product. It’s tempting because it seems impressive. It’s usually not what stops someone using your MVP.
• User roles and permissions. You think you need multiple user levels (admin, editor, viewer). Your MVP has five total users. Ship without it. Add it when you have 100 users asking for it.
• Advanced analytics and reporting. Dashboards that look impressive in a demo but that users never check. Start with the data your user needs to answer one specific question. Extra reports come later.
• Customisation and white-labelling. Do not build this for an MVP. It’s a distraction. Your MVP users want a product that works out of the box, not one they have to configure.
• Mobile apps. Your MVP lives on the web first. If 80% of your users are on mobile, build a responsive web app. Don’t ship a native app. The overhead of maintaining iOS and Android versions is real, and it won’t meaningfully change your learning speed.

A useful exercise: list every feature you think you need. Then ask “if we shipped without this, would the user have something valuable?” If the answer is “no,” it’s core. If the answer is “yes, but it would be better with this,” it’s a nice-to-have. Cut the nice-to-haves.

Architecture and data: what actually has to be solid

Cheap tech choices in an MVP can hurt, but expensive ones can kill you. The balance matters.

You don’t need to over-engineer. You don’t need a microservices architecture or a real-time event streaming pipeline or a machine learning model training on 100 million data points. Most MVPs are overbuilt on the infrastructure side.

But you do need solid foundations in a few places:

• Data integrity. If your product’s job is to give someone an accurate picture of something (their spend, their projects, their customers), the data has to be right. This means proper validation, audit trails, and testing. You can ship with a simple database and a straightforward API. You can’t ship with data you’re unsure about.
• Authentication and security. Use a battle-tested auth provider (Auth0, Firebase Auth, AWS Cognito). Don’t roll your own. This is one area where “good enough” gets people hurt.
• API design. Your MVP API doesn’t need to be beautiful, but it needs to be consistent. Build it as if you might integrate with it later or someone else will maintain it. It takes maybe 10% longer and saves you rework.
• Observability. Logging and error tracking (Sentry, LogRocket, simple CloudWatch dashboards). Not because you need fancy analytics, but because you need to know when your product is broken before your users tell you.

Everything else can be simple. One database. Monolithic code. Dumb hosting. It doesn’t matter. What matters is that the foundations don’t crumble when you’re learning.

The shipping timeline: how long should this actually take?

A properly scoped MVP takes 4-12 weeks depending on complexity. If your scope is genuinely tight, it should take 4-6. If you’re building something with real-time functionality or complex calculations, maybe 8-12. If it’s taking longer, you’ve either under-scoped your estimate or over-scoped your feature list.

The timeline matters because every week you’re not shipping is a week you’re not learning. And learning from real users is why you’re building an MVP in the first place.

If you’re stuck between building it yourself (slower, cheaper, you learn a lot) or hiring a team to build it (faster, more expensive, you’re dependent on someone else’s understanding), there’s a middle ground. Working with a team like Amora, who can talk to you about your build, gives you speed and allows you to stay involved. You get a shipped product in weeks, not months, with the team that built it still available to understand how it works and what to change next.

Whatever path you choose, the scoping discipline is non-negotiable. Pick one job, one user, one constraint. Build the minimum that proves you can solve it. Ship it. Learn from what happens next. That’s how you build something real.