Why build an interactive prototype when you can build a real app, instead?

The start-up entrepreneurial path is always tough, and I have to admit, it is easy to get tempted and jump onto the next brilliant idea. But undoubtedly, this path is very dynamic, and it is the fast lane to master new skills — you will learn from making wrong decisions. Entrepreneurs can fail because of many various reasons — not finding a good partner, not having enough capital, failing to raise money, wrong product-market fit — you name it. The point is not to dissuade you — my aim is to point out that a great product can be built through collecting solid data. However, this information comes after asking the right questions and giving specific context to your early users when getting feedback from them. So, you can make all that less blurry by building your prototype, Proof of Concept, and MVP — while the first one mimics your product idea and helps you get feedback, the Proof of Concept and MVP show you whether there is real value in what you are working on.

One of the first steps every start-up initiate is creating a prototype of the future product concept, usually by designing an image prototype based on application screen designs. The main purpose of the prototype is to give an idea about how early users would interact with the software, measuring the user experience at a very early stage of the product or before releasing a new feature. However, the prototype can be used in qualitative research for gathering early users’ first impressions, getting feedback, and generating potential leads.

Another must-have is the minimum viable product (MVP) which by the definition given by Productplan.com “is a product with enough features to attract early-adopter customers and validate a product idea early in the product development cycle”. Another purpose of the MVP is to bring some value to its users by representing a small fraction of the product value. If that tiny piece of the software helps users resolve some of its everyday challenges or pains, it is assumed that developing the whole product feature set would bring significant value. However, it is not always expected that an MVP will represent part of the software, it is much more important to validate whether it actually gives value to the users — for instance, if you are building a project management tool, a possible MVP is offering users an automated excel file with sheets for the roadmap, sprint, milestones planning. Needless to say, the best validation comes after getting paid for your MVP or getting prepaid for the next software version. That’s the first moment of real success.

As you can see, even though an MVP and a prototype may overlap, they are meant to be used for different goals.
Here comes the next question — is it possible to present your product and at the same time give value to customers, so you can attract early users? Giving actual value through an image-based prototype is very hard, mainly because it is based on static Sketch/Figma/XD files. It does not produce anything for the customer, because its main purpose is to showcase the future idea, while the MVP may not represent the complete product idea, but it adds value. The key is in bridging the gap between designing a prototype and value bringing MVP. In the case of software product development, that can be accomplished through building an initial software version (serving both as an MVP and interactable prototype) by using a design-to-code tool — which lets users create an app quickly using a visual builder and producing a working code.

In case you are not familiar with the idea, let me reveal more about what a design-to-code tool actually is. It is a web visual builder, similar to the popular UX design tools, but much more powerful — it is expected to generate an app code, support advanced and flexible layouts options (such as CSS Flexbox layout), offer data source binding options, and much more. However, I am sure that you don’t want to spend a lot of time using a particular design-to-code tool and finally turns out that besides the visual pleasing interface and building blocks, but you are stuck because of the hundred missing features, such as lack of proper data binding or the major issue that the code quality is very poor or the components have significant visual issues in some of their interaction states.

So, the design-to-code tool is actually expected to produce a working web application vs a vector design for an application which is the actual outcome of using a static design tool. When using a powerful tool like Indigo.Design App Builder means that designers should not have to prepare separate designs for each screen size (because of the absolute layout limitations in the design-only tools) thanks to the Flexbox layout in the App Builder. But it also means that the hands-off process that is usually full of issues due to miscommunication between Product designers and Front-end developers, is skipped. It’s also important to note that the preview displays interactable screen parts where users can fill in inputs, select from combos and dropdowns, or switch tabs, so they can play with the application. And I saved the best for last — in Indigo.Design App Builder, the code of the designed app is generated with a single button click and easily generated in VScode with just several commands. When I say code, I mean a clean code that your company dev team will love. However, if you think that the learning Indigo.Design App Builder as new software is challenging, better check its interface yourself — it is very similar to the mainstream UI/UX tools that a product designer uses every day, but, of course, in a web environment (which is great!). Even if you do not have a designer’s background, Indigo.Design App Builder offers an easy-to-learn environment to visually create a real working app. The main difference comes from the use of the Flexbox layout instead of Absolute, but as I mentioned above — that is an advantage. In case you are not familiar with Flexbox, I would recommend getting familiar with it after a quick game of Flexbox Froggy Game and reading this Guide to Flexbox.

In terms of business value, using a powerful low code tool, such as Indigo.Design App Builder, to build your MVP helps you in several crucial aspects:

• Iteration — build a real software fast, test, move on!
• Better workflow and speeding up the process — working in the unified product development platform of Indigo.Design App Builder lets all stakeholders simultaneously work in one platform without the need to switch between tools which speed up the whole process enormously. Already got a Sketch file with your app design? Sure, just parse it in the App Builder and continue your real app there. All in all, speeding the development and reducing errors saves time and money.
• Fewer people involved — since the app code is generated, the result is fewer hours spent on the UI and styling, more time for the business logic, and minimizing the production costs.
• Raise money with a real product, not an image-based prototype — presenting a real software product that can actually be changed fast? Yes, the Indigo.Design App Builder supports this and VCs will definitely notice this progress.
• Reduce time to market — the sooner the product is shipped to the market, the quicker the realist feedback and actual results come. Or even get paid for your real product!

The intention behind this article is not directed to leave off the current design tool used in one department, startup, or firm. But if you are seeking a productive and bringing high-value approach to build your next product or feature, then you should consider radical changes in the development processes. And all these process changes can be easily adopted by using the Indigo.Design App Builder — a single productivity tool meant to be used by several key stakeholders involved in a product creation process. Faster development, quicker iterations, fewer errors — all that results in building a successful product at a lower price, which is the aim of every startup.