How to get a whole product from MVP and not drive away current users during development

When a developer gets someone else's product, especially if it is not completed or poorly developed, he or she usually tends to recode everything. It is dangerous enough from the business point of view: while we are recode, current users will leave, new ones won’t come, and competitors will release a similar product. Option one - to improve the current product, keeping it on the track.

Here's how to create a full-fledged portal from a lending. A real life story.

One of our clients, let’s call him Dan, came up with the idea of creating an apartment finding service.

Focus on the main points

Dan’s original site was cooked up by his friend Paul, who didn’t know that much about development. To make it fast, he chose Ruby on Rails. There are many ready-made solutions: registration forms,user accounts, search filters - you can use them all and create an MVP in just a couple of days.

The original version had a New York City apartments base with an option to filter by address and cost, and a registration form.

To find accommodation you just needed to specify dates, budget, gender and age. Just some basic features are needed

Gather feedback

The main functions turned out to be enough to attract a couple of thousand users. Dan planned to attract even more, so he began to look for what his offspring was lacking. It turned out that without adaptive layout, he weeded out mobile devices users. Also users wanted to check the future building owner or tenant before moving in. Dan reached out to us, because Paul didn’t have enough knowledge and time to make a full-fledged product alone.

Improve!

Service development began.
Dan travels a lot, so it was important to make an adaptive layout faster. So he can see the progress of his service in any place and at any time.

The next issue concerned the safety of tenants and landlords. To solve it we have integrated the RRD service which checks information on users’ solvency, criminal liability, previous places of residence by social security number. It is a fee-based service, so we also integrated card payment and Stripe.

Having finished with RRD, we set out to filtering. Originally an apartment could only be found by the address and cost. We went further and expanded the search settings:

1. Date of arrival;
2. Approximate length of stay;
3. District;
4. Proximity of subway stations.

Then we added Google Maps so that users could sel ect the desired district right on the map.

  It is easier to find a convenient district on the map and filter out the accommodation options in the desired location

Gather feedback again

The number of users grew. Boston and Los Angeles were added to New York. The previous app architecture couldn’t take the load closer to 10 000 users: the pages loading took 10 seconds, filtered data were shown with errors. In order not to lose users we created a new list of improvements and set to work.

Gradually, we added new cities

Improve #2

The search worked slowly. We found out that users and apartments data were stored in CSV text files. When the number of users increased drastically, this data format stopped working. We implemented caching and began to store data in Redis, which helped to speed up the search time from 10 to 2 seconds.

Then we returned to the filters. Dan had the idea of ​​differentiating the service - not just looking for housing, but finding a roommate. Therefore, we revised the registration form and added roommate filters to the housing filters. The main frame was ready, so adding the second one was a matter of 2-3 days.

We got a four-step registration form:

1 step: name, type of housing, age, gender, budget, marital status, attitude to pets;

2 step: the city and the surrounding area;

3 step: lifestyle: working hours, attitudes toward alcohol, drugs, parties and late guests, introvert or extrovert, eating habits, housekeeping;

4 step: selecting a roommate and assistance with the move.

At the last step we integrated our portal with freight and insurance services.

Thanks to the new filter, we were able to get into the expectations of users more accurately: a user with a dog easily found an animal lover roommate, and the introvert did not get into one apartment with a party head.

A new four-step filter helps to select a roommate more accurately, by considering the interests of both parties

Results of the year of work

In the following steps, we added personal user ratings, reviews, mutual likes and chats. When a user finds a suitable mutual, he likes his profile. If the potential roommate responds with mutual like, they discuss the moving conditions in the chat room.

Over the year, we added 13 US cities, now the system can withstand 50,000 users. In the near future, Dan does not plan any drastic changes, but the developed functions are enough to meet the users needs.

All the changes went smoothly due to the fact that we have completed the framework of the service simultaneously with the new functions development - so the portal did not stop working.

Conclusion

You can always start with something simple and then finish it. The main thing is to clearly understand your goals and the needs of the audience.

Here is a simple reminder of how to start:


• Identify the main functions that the user will come to use;
• Release the basic version of the product;
• Gather feedback and correct mistakes;
• Make the list of features for the next stage;
• Repeat the list starting fr om step 3;
• Repeat until the product runs and develops..