Get best of the week

MVP by a single developer

With the enormous competition of digital products and the high speed of launching new ones, it is necessary to quickly and cheaply test the viability of product ideas. In this article I will talk about the experience of creating MVP in-house, i.e. in fact, by one iOS developer. About how I looked for balance when creating MVP, about tools, difficulties and their solution. If you plan to implement the first projects in mobile development or want to add a new branch of functionality to an existing product, then this article is for you.

image

Let's first remember what MVP is.

MVP ( minimum viable product) is a product that has minimal but sufficient features to satisfy first consumers.

The main task of MVP is to obtain feedback in order to formulate hypotheses for further development and, on the whole, evaluate its appropriateness. Those. it should be as cheap as possible in the event of failure and at the same time viable in a positive scenario. Therefore, the main task can be reduced to the notorious search for balance at each stage of development.

Application functionality




So, I needed to make a mobile application with the following set of basic functions:

  • authorization;
  • voice conferences;
  • admin panel and small server side;
  • content loading by users;
  • synchronized viewing of content;
  • basic analytics.

Time and Human Resources


The minimum resources for this project are one iOS developer and 2 months for development and testing. More like a challenge. But no panic! Of course, I used ready-made developments. MVP is definitely not worth developing your own libraries. So, we lay a few days on the selection of ready-made solutions and the necessary open source projects.

Design


One of the less obvious things from the minimum set for MVP is design. It seems that for him it is enough to list the names of the screens and what they are responsible for. But in reality, a carefully designed interface significantly speeds up the process, allowing the developer to get rid of many uncertainties in the work. The development of the design in the early stages gives a clearer understanding of user flow, allows you to remove unnecessary and concentrate on minimally sufficient functionality for the first implementation of the project.

Of course, the focus should not shift towards complex animations, but the first impression can be made only once! Therefore, a simple but pleasant interface and an intuitive tutorial are what we need.

In my case, the final design of the application was almost ready to start development.

Architecture


It is probably easy to guess that I was working on an iOS client, and this is the part that needed to be saved and developed further in this project. Therefore, we lay down a solid architecture and select in the modules those very minimally viable parts that will be replaced at the next stages of development.

Based on these requirements, it is also clear that the application needs not only the client, but also the basic logic on the backend. Those. you need authorization, the logic of joining and exiting them, the formation and management of content, sending push notifications.

Search for a solution


One of the necessary tools is a cloud database. For this, I compared several of the most popular options.



From the table above it is clear that Firebase is an excellent integrated solution from Google, able to cover most of the needs of the developed application. 

Such solutions allow you to keep all controls in one place: user accounts, a list of rooms and their settings, analytics and information about crashes. And in this case, you can also manage the rooms and their content through the Firebase admin panel - it’s very convenient. At some point, you might even think that this is an advertisement, but I really liked it and, most importantly, this set of tools helped.

In addition, the service is free (subject to limits), and for MVP they should be enough with a margin. Good documentation, there are already a bunch of articles and tutorials on all services, up to your own video tutorials on YouTube - they simply leave no chance to not be sorted out.

As a result, from Firebase I took:

  • authorization 'Firebase / Auth';
  • Cloud database 'Firebase / Firestore';
  • backend 'Firebase / Functions';
  • 'Firebase / Storage' storage
  • analytics 'Firebase / Analytics';
  • Crashlytics Crash Report.

This is what authorization looks like:



For the assigned tasks, anonymous authorization was rather simplified, when the user is assigned only a unique ID.

This is how push-notification settings on the client look:



It will take only a few lines. You need to subscribe to a specific Topic, which, in turn, sends pushbacks from the back.

This is how sending to TypeScript (JavaScript) via the Firebase SDK looks like:



All that was left was to find a cheap solution for voice conferences, but everything turned out to be not so obvious. Firebase, unfortunately, cannot cover this functionality. 

The main requirements are cross-platform and easy integration. Here is a small selection of similar tools.

Attention attracted Jitsi- This is an open source project with support for iOS / Android, audio and video chats on WebRTC. To start, their free hosting is enough, and in the future you can move. Also, the conferences themselves can be tested directly in the web version, which greatly simplified the debugging of calls.



Jitsi has a very simple integration and launch of the conference itself. But after the start of the call, the conference is managed directly through Webview, you can only end the conversation programmatically. At the stage of selecting this tool, there was no thought that using the methods available from the code, for example, it is impossible to make mute / unmute. Therefore, I had to refine and add these methods to the library, as well as to configure interaction with controls. I also had to tweak some parameters for myself. Of course, it took a little more time - it took an extra week, but it is still several times less than it would take to write your decision. 

Summary


After a month and a half, the application was ready, we added the necessary analytics to measure the product indicators of interest. Two weeks were needed for testing and subsequent improvements. Thus, the development took 2 months, as planned. I note that even on small projects it seems that you can still fix something, try to find a better solution. These desires lead away from the main task of MVP.

Unfortunately, the company did not receive the necessary metrics, and this meant the closure of the project. But this is one of the results: we tested the hypothesis, and most importantly - quickly and cheaply.

And once again, I’ll remind you of the main points to keep in mind when developing an MVP application for iOS:

  • save on everything, but not on quality;
  • the finished design will greatly accelerate the process;
  • MVP ;
  • .

More articles:


All Articles