How to build a dating application?

Spoiler: This is the most extensive guide to build a dating app on the concept, building MVP, optimization, backend stability, application security, real time chat implementation, tinder matching algorithm and content moderation.

Want to build an app similar to Tinder for the dating niche?

You probably have heard a lot about dating apps being saturated and competitive, but..

That’s completely subjective, and timely disruptions often validates unsaturation! Even more so, niche dating is heavily unsaturated.

In the words of Sean Rad, Tinder Co-Founder..

It’s not just about swiping left or right, it’s about the underlying philosophy.

Too good to be true? Let’s see!

Some niche dating apps that have seen massive success recently:

• Twindog got nearly 100k users within 2 months after launch
• Bristlr, an app for Women seeking bearded men
• The League, a dating app for people that are too popular
• Dating for the blind, developed at the RLSB

Now, your crazy dating app idea doesn’t seem to be that crazy, right?

Notably, such apps evolve out of self-passion, so, it’s safe to assume that you are already familiar with some attributes of your niche. You can quickly put together some of your ideas, discuss and test to see if you have a market for that.

NOTE: If in case you are planning to develop a clone, you should understand that your market validation has already been done.

What will you learn:

• Different ways to build a dating app?
• Building a dating app MVP
• Optimising your app for usability, performance and security

How to create a dating app?

Here’s the deal, there are no set standards of app development for startups. Typically, there are three ways to build an app:

1. Use an app builder
2. Develop a custom app
3. Customize a Clone script

Lets have a look at these options

Dating app builders

There are many dating app builders that allows you to drag and drop to create user interface, tweak backends and play around a little bit.

The best part about using these app builders is the ease they bring in:

Most of these WYSIWYG builders charge a monthly fees for the app to function, they host and keep your backend. They provide UI elements that you can use to make your application.

To assist you in creating apps, most of these app builders provide documentation. They also provide on call support if things get complicated. But they suffer from some serious issues:

• They are limited in terms of customization, innovative features (for Tinder it was swipe)
• In some cases, the code that powers the app cannot be exported and becomes inaccessible once you stop the monthly payments
• Almost impossible to optimize user experience; a core of such dating apps
• Limited in terms of what they offer for the rapid changes in technology

While in future we can expect to have reliable app builders, but right now, they are poor choice to build a dating app.

Develop custom dating apps

Custom apps can either be native or cross platform.

They require a database to store their data, and a backend to function. When built natively these apps run more efficiently. Here’s a comparative study of native vs cross platform development we wrote a while ago.

Developing apps this way also favors iterative product development. You can actually pivot your entire product if required. But…

Custom app development brings additional costs to the table. Other than that, there are no drawbacks to have your app developed in this way. If you really believe in your idea, head over to How to make a dating app using custom development.

Dating (Tinder) app clone script

Basically, clone scripts are source code replica of existing popular apps available on online marketplaces. With this option, you look up on the internet for an already existing code available on the dating app you want.

You end up finding a dozen Tinder clone scripts out there. After buying a clone script, you will hire a freelancer to customize and help you upload the app to relevant app stores.

These scripts usually cost between $100–700 and customization costs that a developer might charge. So far so good, right?

Not really! Apple will crack down on such rip-off’s, sooner or later!

There are other downsides to the approach as well:

• First of all, extremely minor customizations can be done by any developer with ease. But, in case of even a little bit of complexity, the cost of customization goes up drastically.
• At worst, the developer may fail or refuse to work on the code at all.
• Experienced developers usually straightaway refuse to customize such codes. And recommend writing the code from the scratch.
• More chances are that the code won’t have a proper documentation, comments in place to help your developer

What about scalability?

Scalability is something that has killed many startups that topped App store rankings in the past. Often, such codes are poorly written and won’t scale at all.

Given that there is a market for your app, you still need to innovate at least by 10% with your product. A clone script just isn’t something that helps you doing that.

It is worth knowing here that a majority of people who use such clone scripts are essentially blackhat marketers. Most blackhat marketers are not driven by the desire to serve users. They rather intend to spam, and monetize quickly. User retention is pretty low in such cases.

Finally, whether you use a Dating app source code, app builders or custom development to build your app, you need to immerse yourself in the process to build a successful dating app.

It may seems overwhelming. Don’t worry…

In the section below we will show you a possible approach to build MVP and optimize application features. Not only that, you’ll also be able to properly understand ins-and-outs of critical app features.

How to make a dating app — MVP

Creating such an app MVP would require you to have iOS, Android and backend development skills. iOS development is mainly done using Swift and Objective C, while for Android you need someone with a Java experience.

For backend, you can have Javascript, PHP or any other language that you prefer. The choice is completely subjective. The best way to move forward is by following a minimum viable product approach. You should be very careful on how you decide your minimum success.

Tinder co-founder, Sean Rad admitted this during his talk at Google I/O 2014:

We drastically underestimated what MVP was…everything was just going to collapse down for 24 hours because this architecture has its bottleneck and it won’t go past that.

This happened when Tinder was about to move from 20k users to 500k users overnight. And it was extremely stressful for Sean. So, it’s really important to come up with a properly defined MVP.

An approach to MVP has been illustrated by Arum Kang of Coffee meets Bagel in the video below:

The following should be noted very carefully from her talk:

1. You can actually build your MVP without a technical co-founder
2. It becomes easier to find a technical co-founder once you build a MVP

Now that you’ve properly defined your minimum success (MVP), you are ready to move on the next section.

Most commonly, we have seen the following features within dating apps:

• Swipe gestures
• Matching users
• Content Moderation
• Real time chatting
• Geo location

The goal here should be to create features for usability, performance and security.

Optimize your dating app

Building Swipe Gestures

Building swipe gestures isn’t very difficult, and any good developer can do that. Though, care needs to be taken while implementing the swipe gestures. Chances are your implementation may not be optimized for the target audience.

The following drastically affects user friendliness of your swipe transitions:

• Distance from the middle required for an action to take place
• How much the card will squeeze upon swipe, how much it should rotate
• How much the card should shrink upon swipe
• The angle of rotation and it’s strength

The animation below nicely illustrate how the minor changes influence the experience of these swipe transitions.

Find out what works best for your target audience and optimize swipe gestures.

Build backend for scalability

Many often ask for the easiest way to have a scalable app, and we often repeat — Easiest is often not the best way to build a scalable application.

For a MVP, a MySQL + MongoDB database along with Node.js works best for such applications.

Some recommend standalone MongoDB for such apps, which is not the best way. Most such recommendations arise from myths surrounding MongoDB, checkout the video below to learn about myths surrounding MongoDB.

Tinder itself used MongoDB and ran into many issues. It got to a point where they were eventually forced to move their focus from product to scaling the service.

Designing a database on MongoDB is a bit tricky. It requires you to plan in advance on what features you wish to implement, and what information you would need to extract.

To sum up, all the non-structured data of your app should go to MongoDB and the structured one will be stored on MySQL database.

Node.js and static serving

Node.js is great for variable tasks…but It doesn’t works well when it comes to static content. Using a caching mechanism eliminates the problem. You’ll read more about that later in the blog post.

Let’s get back to scalability.

Technology scalability should be at the center stage on your immediate product roadmap.

Chris Lalonde, (who scaled Ebay to millions of users) spoke the following in context of scalability for startups:

I know a dozen startups that failed from their own success. These problems are only going to be bigger.

The graph below well illustrates importance of scalability from an ROI perspective.

The green line in this graph seems way too fancy to be true; more often than not, it isn’t.

For most startups, the actual path looks something like shown in the graph below:

Let’s take scalability even a step further, and optimize the server queue. Server queue is basically a model of how your app will handle and process requests.

So, while building server model for a dating app, we recommend rather than going for a N servers + N queues or single server + single queue, we prefer Single queue + N servers.

This ’N’ would depend on your incoming traffic, a part of system design.

Now, you can sit down with your product and development team to identify:

• What’s immediately going to happen after you release your app(frequency of messages, number of requests, etc)?
• What model can handle the least requirements?
• What are the risks involved?
• And most importantly, How can you move to a different arrangement if required?

Before proceeding, talk to your developers if the single server + N queue actually solves all of your concerns.

In next section, will help you optimize your dating app for a much better performance when it comes to node.js serving static files.

API Caching to make node.js faster

As we told you earlier, node.js isn’t the most efficient framework for serving static content(e.g images). A caching method would bring huge performance boost to node.js. Any request with caching appears to have been processed instantaneously to a user.

For the sake of simplicity, think about Caching as something that stores information temporarily so that it is easily retrievable when a user requests it again.

Take the image below as a reference, without Caching (in this case Nginx), your app would keep more than required socket connections opened up for no reasons. The blue lines indicate HTTP requests, the red lines indicates socket connections.

Caching drastically reduces the number of calls that your app needs to make to your primary database. With their own ups and downs, there are three ways to implement caching in your app:

• Direct connect cache
• An API caching layer
• Local cache

Or, you can have all of them serving different purposes within your app. For a MVP, that’ll be an overkill.

Making a safe dating application

Dating apps are often vulnerable. And, there are simple tactics by which an individual’s private information can be extracted to induce harm.

While building a MVP, the inability of a startup to spend hundreds of thousands of dollars is understandable. That being said, you should take care of the common easy to fix exploits.

A common well know exploit is Trilalteration.

How Trilalteration works?

Dating apps often share location information within the user’s app.

However, the user on gets to see ‘3 miles away’ or ‘5 miles away’ in his app’s UI:

But, if you play a little bit with the backend, you would find user distances in the form of ‘3.01156’ or ‘5.223254’.

In order to get an accurate location of a user, all you need here is to just create three different profiles, with 3 arbitrary locations in these accounts.

You will then get 3 distances, let’s say ‘3.01156’, ‘3.10022’ and ‘3.00011’. Anyone can then proceed with Trilateration to get a good approximate location of the target user.

While Tinder used to provide this information, they don’t anymore. But, we see many apps are still doing that, compromising user security. Most of the time, entrepreneurs behind such apps don’t even know that it is so easy to get the exact location.

Exposing user’s information in such way could be fatal for your app’s users. Grindr, a gay dating app also shared information the same way as Tinder. Egyptian authorities exploited this information to get exact location of gay people and executed them.

To avoid this, simply don’t provide accurate location information to your mobile UI.

Another way to hackers get access to user’s data is via Decompiling your app.

Decompling a dating app

It’s extremely easy to decompile your app. Once your code has been decompiled, attackers can:

• Source out any hard coded 3rd party backend’s ID’s and login credential.Which they can use to gain access to app’s server.
• See debug messages if they are not turned off by the app developers.This allows attackers to access potential stream of sensitive information.

To make attacker’s work a bit more difficult, you need to:

• Obfuscate the source code. It shouldn’t be in plain text.
• Make sure no login credentials are not hard key coded within the source code.

Encryption and cryptographic hashes

Each communication your app makes with the server should be encrypted. A PGP based cryptographic encryption will suffice here.

We don’t recommend cryptographic hashes, since it’s very easy to buy or download a list of hashes for all phone numbers.

The security measures listed here are extremely easy and cost effective to implement, making the best security tech for a dating app MVP.

Real time chat Implementation

When your users match, they’ll exchange messages before meeting each other.

Now, you should know that there’s a huge difference between a simple chat and a real time chat implementation. The former requires users to refresh the app to get new messages, while in the later, the chat gets updates automatically.

A simple(HTTP) based chat app would:

• Waste unnecessary resources
• Provide poor performance and user experience
• No assurance that messages will be delivered timely
• Won’t scale properly, and ultimately fail

Real time chat is present in each famous chat app that we’ve seen so far.

How to implement real time chat in your dating application?

Well, you can do that by:

• Socket programming
• XMPP server integration
• Using 3rd party SDKs like WeChat

Each has it’s own merit and demerit. The last one is mainly used if there’s a budget constraint.

Socket programming?

Implementing a chat functionality from scratch isn’t the most preferred solution for startups. It just takes too much time and effort to build it.

There’s a reason why Layer charges $1,500 per month. A better way is to either go with Firebase or OpenFire. They both provide XMPP protocols for chat functionality. Both are good options and often deliver equal results.

However, there are a few differences:

• Firebase is paid; and will take care of high speed and scalability
• Openfire on the other hand is free, but you will be responsible for speed and scalability

If there are no budget constraints, you should go for Firebase, otherwise you can stick with Openfire.

MYTH: Many claim that the maximum number of simultaneous users Openfire can handle is 4,000. Actually…

Unix like systems limits the number open requests Openfire can have. It usually is set as a default to 4,000. You can customize and increase it easily.

This setup can easily handle up to 50,000 users active at the same time. Some other benefits of using XMPP:

• More resistant towards censorship
• Muti-device experience, synchronization of messages

Layer is another good option to build chat functionality within your app.

It utilizes pre-packaged building blocks for chat infrastructure as opposed to custom chat solutions. This drastically reduces the time required to build chat functionality:

Layer is extremely expensive, and only a small percentage of startups could afford using it. They claim it to be one stop solution for chat in dating apps, and provide everything from GIFs, stickers, music or any other rich media.

But often we’ve seen unique use cases where Layer falls short. Take for example, there’s no predefined “Last seen” feature in Layer, and requires a developer to customize the Layer implementation to implement it.

Another interesting part of a developing a Tinder like dating app is the matching algorithm.

How does Tinder algorithm works?

On a depressing note, nobody except a few knows what exactly goes behind Tinder’s algorithm. But, at the macro scale, it’s a combination of machine learning inspired by real world system dynamics to provide most contextual profiles to it’s users.

This has proven extremely effective when it comes to matching users accurately. But creating a proper Machine learning algorithm means overhead costs for startups. It often increases the total cost of ownership by 4–5 times.

So, what should a startup do?

Well, if you don’t have a Machine learning guy in your team, you can always observe your niche and find out how they interact and how relationships foster. Here are some general attributes that you should try to map:

• Degrees of connection — How degrees of connection (1st, 2nd and 3rd) affect matchmaking success. Note that, there could be two different types when it comes to degrees of connection: 1. From your dating ecosystem 2. From Facebook.
• Influence of similarity/dissimilarity — Here you would mainly evaluate how to add weights to similar or dissimilar interests to make the match making process more effective.
• Profile completion — An incomplete dating profile tells a lot about a user. You can look at various fields inside the user’s dating profile to tune your algorithm.For example, you can add weight to the dating equation if the user has a Profile picture, has added work details, the number characters used to describe himself/herself, or whether he/she has added personal details or not, etc
• Are Push notifications enabled? — Social apps have a iOS push notification opt-in rate of 30–45 %. This bias of time sensitive value propositions serves as an important parameter in the dating algorithm.A user that opts-in might intuitively understand that the push notifications will play an important role in the functionality of the dating app.Which could also be translated to high seriousness towards the dating ecosystem.
• Niche related parameters — These are parameters that are extremely specific to your niche. For example, if you are building a professional dating you may wish to add some weight to number of professional degree a person has obtained.

By observation, testing and iterations you can easily come up with a mathematical formula that can provide upto 90% accuracy for your MVP.

Tinder matching algorithm: The love equation

The formula to rank a user on a scale of 100 could look something like this:

Points = H1(min(1st degree, x1)/x1) + H2(Degree on Facebook) + H3 + H4(min(2nd degree, x4)/x4) + … + Hn(yn)

Hi is the coefficient of independent variables xi and yi.

As the app matures and acquires more users the diversity and complexity of interactions makes it difficult to match users using an exact mathematical formula. When that happens, it’ll be the right time to migrate towards Machine learning to matching users.

Improving user quality

A lot of dating apps suffer from fake profiles, which often devalues the dating ecosystem and drive users away. The problem is so serious that there are many guides on the internet to detect fake dating profiles.

At the very basic level, you could ask users to sign up on Facebook and get their identity verified from Facebook’s data. Now, how long do you think it will take for you to create a fake Facebook profile?

Probably a minute (even less!).

An easy fix: You can fetch user’s data from Facebook, put a threshold on the number of users, profile information, likes, etc that a valid user must have.

This threshold can easily reduce fake profiles from your Facebook. Another good way to improve user quality comes from content moderation.

Content Moderation in Dating apps

Dating apps are often flooded with all kinds of spam and inappropriate content that you might imagine.

On top of that, often instances of bullying and harassment surfaces in such apps. And, it shouldn’t be dealt with casually.

You can:

• Provide users with a way to report inappropriate content or harassment of any sort.
• You can add a threshold, e.g. a threshold (number of times a content/profile has been reported) after which the content/profile gets deleted/suspendedOr
• Do Both

Upon receiving the flags, an admin can manually moderate and take justified actions.

Processing Payments

Purchases made on dating apps generally fall under the category of digital goods. Hence, the use of any Payment Gateway is prohibited.

To process in-app purchases within your app, you need to integrate Apple and Google’s wallet within your app.

Why to build a dating app this way?

Dating apps rarely do sufficient upfront monetization for the developers to survive in the early days. And the moment number of users start to increase, it increases the need for a reliable app infrastructure as well as the operational costs to run it.

And, there comes a time when it no longer is feasible, and startups often have to look for fundings. Your future investors won’t entertain apps built on top of app builders and clone scripts, they might take it as a not-so-serious venture.

After all, if you believe that they should invest in your startup, why wouldn’t you invest in it? Right.