Deciding Technology Stack of Ador

How Ador has built an advanced recommendation tech while taking decisions backed with standard approach and methodology

Approach behind Technology Decisions at Ador

Even before roadmapping MVP, Ador in its most conceptual format required taking series of decisions

The core proposition of connecting individuals based on similar interests can be validated using various ways. Some of these ways include:

1. Forming a Google Form or Type form -> Sending it to a bunch of individuals to enable their seamless connections

2. Getting Individuals connect on Airtable -> Sending list of Email id and Contact Details of community members on Airtable and connecting based on various filters

3. Building a website with login / signup feature

4. Building a mobile app -> IOS / Android

5. Using zoom meets / google meets to connect individuals on one-to-one sessions

The major factors important for consideration while taking the first decision were:

1. Enabling seamless flow of connections and building profiles

2. Having least human intervention

3. Ensuring privacy and confidentiality of individuals is ensured

4. Having events based tracking to measure core performance

5. High level way of connecting individuals based on interests and personality

All these factors led to considering point 4 ->

Building a mobile application as the best suited option

While builiding a mobile application requires its own set of decisions, the primary requirement comprised of testing the core proposition.

Before deciding high level features, the major step included deciding user-personas

The core factors of user-personas included commonalities:

1. Two age-groups from 18-24 years and 25-32 years

2. Pursuing or looking to pursue any interest and hobby

3. Having smartphone with high speed internet connections

4. Digital savvy and having understanding of different mobile apps

5. Looking for affordable but having aspirational option in terms of core product

6. Core geography for connecting with each other -> India

In India, there are 90% Android Users.

It comprises of young audience who is pursuing education or recently joined workforce.

Most of them are price conscious and uniformly present across

Metro, Tier 1, Tier 2 and Tier 3 cities of India.

While 10% smartphone users in India are on IOS, there is a limited scope of building a mass market product. A chunk of them have travel plans out of India and have very short visit in home country.

For mass-market considerations looking for affordable options, Android came out to be the first priority for implementation.

The second stage comprised of implementing Native vs Hybrid technology.

Hybrid type of methodology is implemented when there is mobile application deployed in both platforms - IOS and Android.

It simplifies code handling and code editing. While it also increases load time and hence mobile app speed, the scalablity factors are also important to be considered.

On the other hand, Native is methodology of deploying mobile application in one platform.

It has lesser load time and good mobile app functioning.

The code handling and code editing for both the platforms is maintained separately.

While it increases workforce requirement, the app functioning is seamless ensuring good user experience. It also caters to scalability factors as the number of users grow.

While the core focus for deployment was for Indian users looking for aspirational appeal with affordable options, Android came out to be the topmost priority.

Since Android was priority for time-being and the core proposition was to be evaluated while providing a user-friendly experience - Native was selected by default.

The step-wise flow of decision making included :

Mobile / Smartphones -> Android -> Native

Next stage included deciding technology stack for mobile application.

It comprised of the following aspects:

Selecting Front End, Back End, Database and Cloud Hosting

Connections platform require higher response rate and there are multiple connections, messages, activities happening in the same time-frame.

Node JS ( Run Time envrionment of javascript ) provides these capabilities to handle number of events at the same time. It is the best suited option for Connections Platform.

Since MVP required preliminary database requirements with capacity to handle data across various variables, MySQL which provides free way of managing database came out as core selection. This was later shifted to Mongo DB as number of users increased and higher connections were required to be made.

Cloud Hosting was done on AWS - Amazon Web services. AWS provides affordibility, rekognition technology, database management and suite of offerings best suited for ensuring scaling, privacy and efficient cloud hosting.

Finally, Android Studio came out as primary way to build front end of Mobile App. The inbuilt libraries provide way to track user-location, manage

All events conducted by users can be tracked on Google Fire-base. Event tracking was one of the important factors since it validates the core hypothesis and value proposition.

The prototype/ wireframe was built on Figma - the various UI/UX considerations were hypothized on FIGMA app.

The step-wise flow of decision making included :

Front End -> Android Studio

Database -> MySQL which was later shifted to MongoDB

Backend -> Node JS

UI/UX and wire-framing -> FIGMA

Event Tracking -> Google Fire-base

Cloud Hosting -> Amazon Web Services

Backend -> Node JS