While talking about tech projects, you might hear the acronym “MVP” thrown around, or minimum viable product.

Think of it as the absolute bare minimum that you can squeak by with and call something “done” within a given time period. Keeping the MVP in mind was important as I worked on Book Duets, my capstone project for Ada Developers Academy. The MVP served as a focal point that my sprint planning revolved around.

Applying lessons learned as a writer coming to web development

I’ve realized that my previous work as a freelance writer has helped me grapple with some of the MVP scoping challenges I face as a web developer. Here are some commonalities:

  • Deadlines: celebrated by editors, teachers, and product managers everywhere
  • Articles, like web apps, are often completed on a project-basis, rather than hourly. Ultimately, you gotta turn something in.
  • Breaking tasks down into smaller chunks (be like the squirrel, girl)

Promise a pebble, not the moon

You have so many grandiose ideas! How could you possibly limit yourself to the abridged version of your app?

I get it. It’s really hard to imagine seemingly major features as “nice to haves.” But having an achievable MVP will help you accomplish all those badass goals.

Channel your inner underachiever if you have to. And ask yourself these questions:

  • Does this project solve a problem? How can I solve it the laziest way possible?
  • Whats the “core” of my app idea, the part everything depends on?
  • What’s my input?
  • What’s the output? (don’t worry about “how?” yet)
  • What’s it look like? (Draw a mockup. I used Apple Pages. But anything works - MS Paint, paper, or sigils traced out with thread and blood and char)
  • Does “What’s it look like?” even matter? Does it stand between you and a functioning MVP?

Sum up your MVP in one sentence.

For Book Duets, my MVP was: Get a musician / author pairing, return a mashup of their work.

Here’s a mockup I did of Book Duets during the planning stage. I set my MVP at the start of my project and tried to let it guide me.

App mockup that describes Book Duets as “unique lyric-book mashups inspired by the connections between musicians and authors.”

After the mockup, I decided that a UI wasn’t necessary - an API could take two names and gimme back a mashup.

Book Duets wound up doing more than this, but the MVP paved the way for all the other features.

One for you … one for MVP

Get frugal with time and decide early on how long your MVP should take.

Imagine the following scenarios to induce a proper MVP panic / mindset:

  • Plans change: As fickle humans, we might decide to change course

  • The absolute worst case scenario: What if a curse makes any computer you touch switch off during 50% of your project time?

  • The gnarliest surprise could happen: The API you were so excited about blinks out of existence

    • Gnarly surprise #1: Realizing Book Duets would take a million years to load, unless I took some extra time to figure out Redis and cache.
    • Gnarly surprise #2: After reaching my MVP, I realized that my app needed a language filter option. Machines don’t understand context, so it would sometimes build incredibly offensive mashups.

I decided that 50% of my project time would go toward my MVP - “Take two names, spit out a text mashup.”

Fifty percent might sound a little steep. But the word MINIMAL comes in handy. Something’s minimal when you:

  • ignore all the bugs
  • ignore all the fires
  • ignore the hot mess of un-refactored code

And guess what, I made my deadline!

Commit message that reads “Suggested pairings are working.

MVP is Done, Now What?

Literally everything else in the world - you just did the MINIMUM, remember?

Now the extra hard stuff happens! If you’re not sure what to do, work on:

  • bug bashing
  • improving test coverage
  • adding sweet, expanded features
  • integrating other services
  • creating your project presentation / lightning talk

Looking back at my feature branches, they weren’t necessary for my MVP to function.

Git feature branches including “filter”, “caching-performance”, “auth tokens”, “suggested-pairings”, “learning-redis”

  • suggested-pairings: the MVP branch
  • learning-redis: Experimental branch for learning new tech
  • caching performance: Actually implementing a cache and dealing with Gnarly Surprise #1. Without this, my app would have still worked, but it would have been slow as hell.
  • filter: language filter that deals with Gnarly Surprise #2. Without this, my app would have worked, but it also had the potential to be incredibly offensive.
  • auth-tokens: token generator so that others could securely use the Book Duets API. Not necessary, but cool for building a community of users.

Hope this helps you imagine how you would scope your next MVP and additional features.