The Art of Cutting Features for an MVP

The Feature List Hit 30

The most exciting moment of a new project is the planning phase. Ideas pour in. This feature would be great, that one seems essential too. The feature list passes 30 items.

Three months later, nothing is finished and the project fizzles out. I made this mistake three times. Didn't learn until the fourth.

I Wanted to Build a Todo App

Side project: a todo management app. The feature list I put together: add/delete tasks, categories, priorities, recurring schedules, calendar view, stats, sharing, notifications, dark mode, i18n.

Building all of this solo would take 6 months. And Todoist, Things, and TickTick already exist. An app shipping 6 months late has no reason to beat them.

Answer "Why Am I Building This?" First

To cut features, you first have to answer this. What value does it offer that existing apps don't? For me, the core was "task management integrated with development work." GitHub issue sync and automatic work time tracking.

I kept only features directly tied to this core value and cut everything else. Categories? Don't need 'em. Stats? Later. Dark mode? Later.

Task creation, GitHub issue integration, work time tracking. Three features left.

"Can You Use It Without This Feature?"

Filter the remaining list one more time. Automatic time tracking is nice to have, but you can just enter it manually. So cut it.

After this pass, the list shrinks to a shocking degree. "Add tasks" and "GitHub issue integration" -- just two. Buildable in 2 weeks.

(Honestly, cutting this much felt painful at first.)

If You Can Do It Manually, Don't Build It

I debated building notifications -- alerts when deadlines approach. But early on, there'd be fewer than 10 users. I could just send Slack messages myself.

Automation can wait until there's scale. Before 100 users, a lot of things can be done manually. Bank transfers instead of Stripe, hand-sent emails instead of automated ones, SQL queries instead of an admin panel.

Deployed in 2 Weeks

Shipped the MVP with just task creation and GitHub issue integration in 2 weeks. The UI was rough and features were sparse, but it worked. Showed it to 5 colleagues.

Feedback came: "The issue sync is nice, but I want to see completed issues at a glance." This was something I hadn't considered. Wasn't even in the original 30-item feature list.

That's the whole point of an MVP. Build the minimum, ship fast, let real user feedback decide what comes next.

Cut Half, Then Cut Half Again

Cutting features doesn't come naturally. Developers are builders -- the instinct is to always build more. My approach: write the feature list, cross out half. Then cross out half of what remains. Whatever survives is the real core.

An unfinished app with 30 features is infinitely worse than a finished app with 3.