When Your Startup’s MVP Hack Becomes Technical Debt

If an application lives long enough, that is, if it succeeds, its biggest problem will become that of dealing with change.
–Sandi Metz, Practical Object-Oriented Design in Ruby

I advise entrepreneurs to do both learn how to program, and to hack MVP solutions in the interest of achieving Discovery over product quality.

This past weekend I spoke at Barcamp Beijing about this topic.   A few people objected to my ideas, claiming I was “just encouraging people to take on technical debt”. The quote above from Sandi Metz – whose new book I’m enjoying immensely – is a great warning to everyone who follows my advice. Indeed, if you hack you also risk of taking on technical debt.

But like all advice, what matters is context.

For we entrepreneurs building MVPs to test the viability of our startup ideas, the most critical phrase of the quote above is “if it succeeds”. The odds of any particular component of our MVP “succeeding” are pretty low. Almost everything I’ve ever built didn’t solve a problem important enough for people to pay me for the solution.

Hacks and MVPs that don’t succeed NEVER become technical debt – they become memories. You’ll have an easier time unloading them (both literally and emotionally) if you don’t invest a lot of energy making a beautiful design.

If you’re like me and you enjoy refactoring code and making a more maintainable, elegant design is a creative exercise then go for it. But don’t let anyone scare you with the “tech debt” boogeyman – your real risks are Problem, Revenue, and Channel.

Do not feel compelled to make design decisions prematurely. Resist, even if you fear your code would dismay the design gurus…The future is uncertain and you will never know less than you know right now.
–Sandi Metz

Like her whole book, most elegantly said.  Your MVP hack only becomes technical debt “if it succeeds”.

About the Photo

If you work in software you probably already get the photo – “spaghetti code” is a form of technical debt.  I usually hear the phrase when someone inherits code from others.

Photo by monteregina.

One Comment

  1. Alex Turnbull September 3, 2013 at 8:39 am #

    Great post, Kevin. I think those objections miss the point of hacking an MVP entirely…if you spend months perfecting code before releasing it, your product goes beyond minimally viable, and you’ve wasted valuable validation time in favor of building cleaner code that you may never use again!

I read EVERY comment and want to hear from you