The Prototype Paradox for Experienced Developers

The prototype paradox goes like this: The more you know how to program an app, the harder it is to program a prototype app instead.

If you are a developer and you are asked to build a prototype, here are some tips you can follow to do so successfully.

For a non-tech person, programming an app is as easy as hiring a bunch of developers to do the job. Throw some time and money at it, and *poof* the app is ready to reach the market and make lots of money. At least, that’s the fantasy.

On the other hand, when you build an app, it is a completely different story. There are just too many variables to take into account, languages, frameworks, architecture, conventions, servers, testing, concurrency, scaling, and on and on. And an experienced developer like you has to know about all of these and come up with the most efficient solution.

Heading Goes Here

Then we have prototype apps. Not apps, but prototype apps.

Building a functional prototype app is the hardest thing you can do as an experienced developer.

You know a lot about what you can do with the technology and the temptation is to do it all. You also have a very good sense of “what’s required.” It’s your job!

And you’re right, if you’re talking about a fully functional app. But a prototype is different.

The main goal of a prototype app is to use minimal resources in order to figure out if you should move on and build the real thing. The prototype should prove the proposal of your solution. It is going to be used by a few people, no the unwashed hordes. In the end you want to learn if an idea is mature enough to invest in it later.

Here are a few tips from my own experience building apps and prototypes.

Fix the Scope

It is very important to clearly define the scope of the project at the very beginning. It’s particularly important to call out the things that it is not going to include.

What sole problem are you aiming to solve? Pick one and be sure it’s the one that’s causing the most pain.

Keep It Simple (KISS)

Avoid nice-to-have features. Focus on the real pain your solution is solving.

Of course, it would be nice to have augmented reality and Apple Pay built-in, but remember that you are building a prototype. Those nice-to-haves probably are out of scope.

Every time you think of a feature that would be totally awesome to include in your app, stop right there. “Could this feature wait to be added in the next version?” If your answer is “yes,” schedule it for a later iteration. Then keep working on your prototype.

Frameworks Are Your Friend

You surely used or at least heard of boilerplate frameworks, libraries, and tools. Many experienced developers think, and speak, of these as evil and/or exclusive for n00bs. But don’t take that as fact.

These frameworks can save you a lot of time and effort.

They exist for situations in which you don’t want to deal with trivial tasks and instead want to focus on solving things the hard problems, quickly.

For example, don’t be afraid to use Twitter Bootstrap.

Do you accept payments? Use Stripe.

For markup and style, consider starting with a template.

Do you have to deal with authentication, databases and validations? Use something like Parse or Firebase.

Making It Work!

First make it work.

Then make it right.

And finally make it fast.

If you are used to playing in the major leagues, think of making a prototype as the minor leagues.

You don’t have a big budget. You don’t have a big team. And, most importantly, you don’t have the time. At least not yet, and that’s just fine.

Launch. Launch Early. Even Earlier.

You have not accomplished anything until your product is out and in the hands of at least one other person.

Launch!

Don’t be afraid to launch it as soon as your prototype is minimally functional.

It is way more valuable to have an “incomplete” app available, than to wait much longer. You want to have people try it out in real situations.

Remember, software is never complete.

In particular, don’t wait until you run out of time or money. The earlier you launch, the more time you have to learn from your users. In most cases, your app will change a lot after your first launch, so why work on perfecting something that may not last long?

Measure Everything

Feedback and analytics are crucial.

The feedback from your users might show that everything is perfect. But likely, you will be struggling to find out why people stopped using your app.
Users won’t tell you but analytics will.

Measure from Day One

Measure early and often.

Data will tell you from the very beginning in what direction you should move your project.

Let your data guide you to what features will be added in the next version. Believe in your analytics over whatever users might tell you.

A Confession and a Hope

My first “prototype” ended up being more like a fully functional app. If I had to do it all over again, it would be very different. I would have shipped much earlier, and not waste time on I-thought-it-was-really-cool-but-nobody-cared-for-it features. I would have spent more time up front figuring out what the right metrics should be instead of wasting time with details that users ended up not caring about.

I wish I had been given similar tips when I started.

I hope this will be helpful to you.

Prototype Post

Did you notice the “Heading Goes Here” heading above? Well, this post, too, is a prototype of sorts. Rather than fretting over what the perfect heading should be, I “launched” it as is.

If this helps you, then it was worth launching it now. Even without the perfect heading.

Let me know.


Original post by Javo Rosas on Nearsoft Inc’s Blog.


One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.