The MVP feature list you should cut before you build it
Most first versions are trying to prove too many things at once.
Every MVP feature list has a few entries that exist because they feel necessary, not because they're required to answer the one question the MVP actually needs to answer: does anyone want this. Settings pages, admin dashboards, notification preferences, a second user role — all real, all deferrable.
The one-question test
The test worth applying to every line item: if this feature didn't exist, would the MVP fail to prove or disprove the core hypothesis? If the answer is no, it belongs in version two, not version one, no matter how reasonable it feels to include.
Manual can stand in for automated, at first
A lot of 'necessary' MVP features are really automation of something a human could do manually for the first handful of users — onboarding, support, even some personalization. Doing it manually at small scale is often faster to validate the underlying need than building the automated version speculatively.
Smaller scope, faster answer
Cutting scope isn't about building something worse. It's about reaching the answer — validated or invalidated — faster, with less wasted engineering on features that would've been rebuilt anyway once real usage revealed what actually mattered.
- Every feature should earn its place by testing the core hypothesis, not just feeling necessary.
- Settings, admin tooling and secondary roles are usually deferrable.
- Smaller scope means reaching a validated answer faster, not building something worse.
What investors actually check under the hood
HAVE A PRODUCT IN MIND?
Tell us what you're building and where you need engineering support.