Building an MVP in 8 Weeks: What We Cut, and What We Never Cut

Every MVP timeline starts the same way: a founder says "8 weeks" and a list of 40 features. By week two, it's obvious both can't survive together. The skill isn't writing code fast — it's knowing exactly what to cut so the thing you ship in 8 weeks still tells you something true about whether your idea works.

Start from the question, not the feature list

Before scoping anything, we ask one question: what does this MVP need to prove? Not "what would be nice to have" — what specific belief about the business does this version need to test? A logistics platform's first MVP might only need to prove that dispatchers will actually use a digital booking flow instead of calling it in. Everything that doesn't serve that question is a distraction, no matter how reasonable it sounds in a planning meeting.

What we almost always cut

• Configurability. Admin settings, custom roles, tenant-level customization — all of it can wait. Hard-code the one configuration your first users need.
• Edge-case handling for volume you don't have yet. Pagination for 10,000 records when you have 12 users is premature. Build for the scale you'll actually hit in month one.
• A second platform. If the core workflow is desk-based, the mobile app can be phase two — even if it's on the roadmap, it doesn't need to be in the MVP.
• Anything "nice for investors" that isn't "necessary for users." Polished onboarding flows and marketing pages matter eventually. They rarely need to exist for your first 20 real users.

What we never cut, even under pressure

• Authentication and basic access control. Cutting this to save a week almost always costs more than a week later, and it's a trust problem, not just a technical one.
• The one core workflow, end to end. A booking flow that only works for the happy path but goes all the way from "start" to "done" is worth more than five half-built features.
• Whatever generates the data you need to make the next decision. If the whole point of the MVP is learning whether people will actually use it, you need to be able to see that they did — or didn't.
• Basic error handling on the paths users will hit. Not full test coverage — just enough that the app doesn't quietly break the first time someone does something slightly unexpected.

The goal of an MVP isn't "small." It's "true." A small build that doesn't reflect how the product will actually be used teaches you nothing you can act on.

How an 8-week timeline actually breaks down

Roughly, we've found this split holds up across most MVPs we've built:

• Week 1: Scope lock, technical architecture, environment and CI/CD setup.
• Weeks 2–6: Build the core workflow end to end, in vertical slices — not "backend first, frontend after," but one full feature at a time.
• Week 7: Internal QA, fixing the rough edges that only show up once the whole flow is connected.
• Week 8: Real users. Even five people using it for real teaches you more than another week of internal polish.

The trap to watch for

The most common way MVP timelines blow up isn't scope creep from the client — it's scope creep from the team, trying to build something they'd be proud to show off rather than something that answers the actual question. A rough MVP that proves or disproves the core hypothesis in 8 weeks is a win. A polished one that takes 16 weeks to answer the same question is a loss, even if it looks better in the demo.