Striking a Balance: Great Work and the Minimum Viable Product

Most of us are familiar with the constant battle between shipping and perfectionism. We all want to get our products out-the-door and into the hands of the public. We also want our products to be pixel-perfect and beautifully coded. None of us want to postpone a launch forever, but none of us want to ship ugly work.

Where’s the healthy medium between Minimum Viable Product and the “Glorious Ideal?”

Great Work vs. Minimum Viable Product

Love, Betrayal, and RESTful API Client Authentication*

*contains one of the above

I spent most of the past week with my head buried in the OAuth 2.0 spec, trying to figure out how to lock down an API that I hope will someday prove useful to lots of people. Compared to front-end design, building an API is tedious work, especially where security and scalability are concerned. There are other, faster routes I could take to finish this project. I keep asking myself: why is it worth it?

The project I’m working on would function just as well without OAuth. I could temporarily secure the API with a more primitive mechanism, with the intention of coming back later to make it more extensible. At the moment, I have no reason to believe anyone besides me will ever need to interact with our database. But I’m nagged by the feeling that, if I don’t start off on the right foot, getting there later will be a gargantuan task.

Every project has at least two competing obligations. On one hand, we must produce the best work that we can, for ourselves and for our constituents. On the other hand, we’re obligated to meet deadlines, budgets, design criteria, and other real-world constraints. It’s up to us to find the appropriate balance for our particular situation.

Determining the balance is more difficult on self-directed projects. My OAuth project, for instance, doesn’t have a strict deadline or budget; it can be launched whenever I deem it finished. The only way for me to avoid the trap of perfectionism is to set my own deadline and have a friend hold me accountable to it. Sometimes, imposing artificial constraints is the only way we can force ourselves out of decision paralysis.

In the end, I’ll likely finish the minimum functionality needed to launch the API, and leave the rest for after the launch. I know what direction the project will go in (or I think I do, anyway), and so I can lay the groundwork for future functionality without spending the time to build it completely. While it’s not a compromise that my perfectionist side will enjoy, it will get the project launched soon.


Launched is better than perfect; great work is better than lousy work. Here are some thoughts on navigating between the two competing interests:

This is an ongoing discussion without an agreed-upon answer. Please, add your thoughts to the conversation in the comments below:

Understand Your Compensation

Designer Monoculture

The State of Design Leadership

The Science of Product Design

Interview with Michael Flarup: Co-Founder and Lead Designer at Robocat

The Importance of Design Conventions

Interview with Aaron Quint: CTO-turned-Cookbook Author