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

You’ve got a product idea, a half-decent problem to solve, and maybe some early customers nodding along when you pitch. Now comes the hard part: deciding what goes into version one.

Most founders get this wrong. They either strip the product down so far it can’t demonstrate real value, or they build a feature roadmap that takes six months and costs three times the budget. The middle ground-the actual MVP-requires discipline and a clear framework.

At Amora, we ship MVPs live in 28 days. That’s not marketing speak. It’s the result of being ruthless about scope. Here’s how to think about it.

Start with the Job Your Customer Needs Done

An MVP isn’t a product with all the features. It’s the smallest thing that lets you test whether you’ve identified the real problem and whether your solution actually works.

Before you write a single spec, answer this: what is the core job your customer is trying to do? Not the nice-to-have. Not the workflow optimisation. The actual pain point they’d pay to solve.

If you’re building a scheduling tool for construction crews, the core job is “assign people to jobs without double-booking”. That’s it. Not team performance dashboards. Not mobile offline sync. Not invoice integration. Those are features that come later, if they matter.

The moment you try to build those secondary features into your first release, your timeline stretches and your MVP becomes a half-finished full product. You end up with something that doesn’t work well at anything.

The Three Categories: Must-Have, Nice-to-Have, and Never

Every feature request, spec item, and nice idea needs to land in one of three buckets. Be honest about which one.

• Must-have: The feature without which your customer can’t complete the core job. For a scheduling tool: a calendar view, the ability to add crew members, and a way to confirm assignments. That’s maybe 10-15 discrete pieces of functionality.
• Nice-to-have: Features that improve the experience but don’t block the core task. Mobile app, custom reporting, bulk-import from spreadsheet. These go on the backlog for v1.1.
• Never: Features that sound good in meetings but don’t serve your actual customers. Gamification badges. Dark mode (unless you’re selling to astronomers). Complex permission hierarchies when you have three users. Be honest: what are you building because you think it’s cool, not because it solves a problem?

Write this list down. Share it with your co-founders or your technical team. Make sure everyone agrees on what “must-have” means. This is where most founders stumble.

Architecture Debt vs. Feature Debt: Know the Difference

You can cut features without penalty. You can’t cut architecture without consequences.

Architecture debt is the stuff that, if you don’t get it right, makes everything harder later. Feature debt is just unfinished features-you add them when you’re ready.

For an MVP, here’s what that means in practice:

1. Build authentication properly from day one. User login, password reset, email verification. It takes two days. Don’t skip it just because you’re moving fast. Every hour you save here costs ten hours later.
2. Use a real database structure. Don’t store everything in a JSON blob to “move faster”. In a week you’ll regret it. Spend the time to design a basic schema that you can actually query and extend.
3. Plan your API from the perspective of v2. If you’re building a web app now and might need a mobile app or integrations later, design your backend API so that’s possible. You don’t need to build the mobile app. You need to build the backend so the mobile app could exist.
4. Don’t half-implement payment processing. Either integrate Stripe (or SPayPal) properly with webhook handling and idempotency, or don’t charge money. A broken payment flow kills a product faster than any missing feature.
5. Skip “nice-to-have” UI polish and third-party integrations. Your first customers will tolerate a plain interface. They won’t tolerate a system that doesn’t work reliably or crashes under load.

The rule: if skipping it means the foundation is weaker, it’s architecture debt. If it just means the product is less fun to use, it’s feature debt. Build defensively on architecture. Cut ruthlessly on features.

Real Trade-offs: What a 28-Day MVP Looks Like

Let’s be concrete. A fintech product we worked with needed to let users connect bank accounts, see transactions, and categorise spending. That’s the core job.

What they didn’t build in week four:

• Mobile app (they built responsive web; mobile app came in v1.1)
• Multiple currency support (they launched AUD-only)
• Scheduled rules and automation (users could categorise manually)
• Export functionality (they figured out if anyone actually wanted it first)
• Advanced filtering and search (basic filters worked for early users)
• Email notifications (in-app alerts were enough)

What they did build:

• Bank connection via Plaid (rock-solid, industry standard)
• Transaction display and history
• Manual categorisation with a clean UI
• User authentication and account management
• Basic analytics dashboard (spending summary)
• Error handling and transaction reconciliation

That MVP took four weeks. It wasn’t pretty in every pixel. But it worked. Early users could see their money, understand where it was going, and give feedback.

The product that shipped wasn’t a compromise vision of the dream product. It was the real core of the product, with the scaffolding removed.

How to Push Back on Scope Creep

As you’re building, people will want to add things. Your co-founder will ask for one more report. A potential customer will say “but we really need…”. Your designer will want to redesign a flow that’s already built.

Here’s the framework:

1. Write down the request.
2. Ask: “Does this prevent us from testing the core hypothesis?” If no, it waits.
3. If yes: “Can we test that hypothesis without this feature?” Usually the answer is yes.
4. Add it to the post-MVP backlog. Seriously, write it down so you don’t lose it. You probably will build it. Just not this week.

Speed matters. If you’re a bootstrapped founder or spending your own capital, every day of development is real money. But speed without direction just burns cash and builds the wrong thing faster.

The teams that win aren’t the ones that add the most features. They’re the ones that ship something real to actual users, learn what matters, and iterate. That cycle-ship, learn, iterate-only works if you have something to ship.

If you’re building a new platform, AI product, or growth play and want to talk through scope, talk to Amora about your build. We think about this problem every day, and we’ve learned what works.

The hardest part isn’t writing code. It’s deciding what not to build. Get that right, and everything else gets easier.