Building a prototype

It’s a bit funny when you compare the world of usual agencies and the most popular business literature.

On the literature site, you have a lot of focus on prototyping, minimum viable products and “innovation on the edge of the organization”. To do this you need a lot of experiments, a lot of failures and an acceptance that things simply don’t work out.

On the agency site, you will gladly help to make these prototypes. However, this is often very expensive. Very expensive. Now, we believe, this is not because the agencies are evil or just want to steal your money – every agency wants to deliver value for money. However, the setup to deliver prototypes is quite different than delivering a finished project.

That’s why we believe that when you start a project – either being a newly founded startup with few little cash – or a big corporation – then you need to define¬†what expectations do you have. Building a prototype can be done very quickly – but if done quickly (and cheap) – it does absolutely not scale, and if you need to develop it further, you need to start over.

Differences between a prototype and a “real product”

The type of prototype we talk about in this post actually works. If it is an app prototype, we’re still talking about an app you can find in the app store. It LOOKS like a real product, it has REAL use cases and solves REAL problems.

This is something that’s especially odd for business owners without a technical background. How can something that LOOKS good on your phone, be a prototype you can basically change afterward?

We usually explain this best by the metaphor of a foundation of a house:
When you build a big house, you make a very deep foundation. This foundation allows you to, later on, make a very beautiful house with a lot of details. However, go to the other side of the world and see the foundation for a very simple wooden house. Here you will often see that is actually NO foundation. To then build a very nice beautiful house – that’s simply not possible.

This is the same when you talk about software. When you build a beautiful product with a lot of details (think a big beautiful house with a lot of details), you also need to think about the architecture of the product (the software equivalent of a foundation).

The typical challenges with prototypes are:

  • You can build version 1, but whenever you make changes, it becomes exceptionally difficult – and sometimes impossible
  • Whenever you make changes, many other features and parts of the program break
  • If you get a lot of users, things just implode
  • You cannot get new developers on it, because it’s difficult to understand what on earth is going on

Now, many – especially developers – HATE bad code and prototypes, but we think that’s a very wrong approach. Bad code is completely OK – you just need to understand WHEN you use it. Building a prototype will easily be 10x cheaper than building a real product (or even 20x!) – so it’s a much bigger investment to build the real product. And in many cases, new products simply fail – and it’s not very nice to start out with a huge investment in an expensive product when you could’ve started with a prototype.