Don’t Make A Pretty MVP

It’s not framework X of flat design that makes a startup succeed. So be wary of accoutrements.

You’re totally pounding out your MVP on the MEAN stack because Ruby on Rails is so last decade, right?

Just kidding! Of course you’re doing ObjectiveC and Java now, and thank God we’re not web dweebs (anymore)!

And you’re going totes flat UI on everything, because it’s always better, right?

My MVP sucks better than yours.

You can ask me those questions, the startup brogrammer trifecta: “Are you using the latest sexiest tech? Mobile-only? Flat design?” I could give you the sexy answers. We would then stand up straighter while sucking in our guts under our cool startup T-shirts, and stroke our steampunk facial hair as we sip our microbrews. And I would, probably, because I sure do enjoy that silly game too.

But actually, with the assistance of my co-founder Nate Ragolia, here’s what I’m doing with Onceupon, our storytelling treasure-hunt app:

1. I’m launching my mobile app’s MVP using an out-of-the-box Drupal distribution, running on shared hosting.
2. I’m trying to get by on no custom code whatsoever, just using third-party modules and mashing up libraries.
3. I’m using system fonts, CC photos from flickr and drop shadows everywhere. My design approach in one word: Skeuomorphic! Yes, in 2014!

Why suck?

1. We’re not custom-building our product because we’re not yet a product company. Right now we’re a research lab. Before we build Onceupon the right way, as a set of native mobile apps, I need to know what to build, and how. And that entirely depends on the needs of our customers. So we need to serve our customers for a while, before we can build a product they’ll buy.
2. I’m not building our product well, or fine-tuning the details of the processes, the feel of forms, the usability of each interaction. Yet I’m one of the most anal-retentive UX old-timers you’ll find around. Why don’t I care? Actually I do, and it’s gut-wrenching. But I need to deal with the big issues first: Who are my users, what do they really need, what approach motivates, what language prompts, what hurdles interrupt. I can’t let myself optimize until I know enough to prioritize.
3. I’m going mostly against the grain of fashionable design practices, because my audience is not twenty-something app designers. Much too often, designers focus more on impressing their peers than on solving the problem at hand. My problem at hand involves an audience that is self-selectively hyper-creative, predominantly female, and where middle-aged and older people are well represented. They’re all sorts, but what they have in common is the pursuit of visceral,intellectual, real-life experiences. They’d rather I err on the side of leather, parchment and ink.
4. It’s the right tech for the job. Building with Drupal, whatever my use case, I can get 90% of the way there using open-source, third-party modules. That’s what you need when you’re trying to reach product-market fit. As I go along, I also start to get a feel for just how many details and moving parts my final product will have to handle. It’s always more than you think, and I’d be wasting a lot of cycles on such ancillary bits of tech if I had to build them from scratch.

Build it to throw it away.

It’s always very hard to throw away working code. But I’ll be happier rebuilding a well-understood app the right way, than trying to teach Frankenstein to pirouette. I’m not going to encapsulate a Drupal site and call it a mobile app, so I know that everything I build will get canned eventually. Soon, if all goes well.

To reduce the pain of having to eventually redo it well, here’s the approach:

Don’t do it well.

Get it functional, fix the big problems, then go show it to customers. All the niceties will come in later.

Don’t fall into the trap of making yourself proud of temporary work. And until you have traction, everything is temporary.