What some do is go for cheaper, outsource it, find a junior or student. Perhaps the DIY route.

But the old adage, “you get what you pay for” applies here. Problems tend to come along more often than not, communication problems, time zone issues, quality issues. The number of times I’ve had to turn down a client because they’ve realized this too late, but the funds are spent now.

Is there another way? Yes, we have some great options.

A regular mockup can show you what the UI will look like. It’s a good way to start envisioning what the product will look like. But it’s limited. A step up from a mockup is an interactive mockup. There’s no functionality here, you can’t sign up, you can’t buy a product, you can’t send a form. But what you can do is test the flow of the website or app.

The interactive mockup can be the best way to get the idea out without the production costs of actually making the thing. This is great for showing investors.

With an interactive mockup, you can click buttons and menus to walk through your product.

You can click a callout button, that takes you to a submit page that takes you to a success page.

I had a client come to me with an app he had outsourced. Unfortunately, the code was a mess and it was an expensive job to put right. But the project was just to show investors. The project was way over schedule and the investors were losing interest.

As the project was rushed, the UI looked bad, it didn’t really show an investor what the end project was going to be like.

They had focused on showing the investor functionality rather than inspiring them with a clean looking UI and letting the investor click through the product and see how it would look without needing to actually build it.

With an interactive mockup, they would have had a product they could have shown the investor in a matter of weeks not months. The look of the UI would have been impressive.

Functionality is expensive, a design is much cheaper. Thusly, the risk would have been far lower.

When it came to building the real thing, it would have been so well planned that money would have been saved on the real build.

Always consider whether starting with an interactive mockup is right for your business venture.

What the previous example client was trying to produce, was a prototype. Where the mockup is about the UX, the prototype is about the functionality. The best thing about the prototype is it allows you to prove the concept from a code angle. It’s like the first draft of a book, you would never publish it, it’s more about getting the idea down.

A prototype doesn’t concern itself with best practices, with security or even bugs because it will never reach the publish. These things push up the price of production. It also only concerns itself with only the vital components, only that which is core and vital to the product. It has this in common with the MPV.

A prototype can be done before or after a mockup, or without one.

The minimal viable product is designed to go public. What differs it from regular development is it’s minimalist in its approach. It picks out only that which is truly necessary for the success of the product and not with the “nice to have”. All those “great ideas” of “wouldn’t it be cool if it did x”. None of those ideas make it into an MVP, only those core features.

A minimal viable product is about proving a concept before investing heavily in it. Unlike the prototype, it’s not about proving from a code perspective, it’s about proving from a customers perspective. Does your product solve the problem as intended? Does it work?

Very often, a business will go all out in the feature set with the belief of “more is always better” but you can spread resources too thin and have lots of features that were expensive to produce that you thought would be important but when taken to market, you find out actually, nobody used.

It reduces risk by reducing the initial investment and making sure that the features you do produce are done right.

It also gives you a base on which to build and experiment. Once you’ve taken your product to market, you can do some research on your users to find out what features they want, not what you think they want. Resources can be directed to things that are actually wanted by your users and not wasted in building a product no one asked for and no one wants.