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:
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.
Here’s the deal, there are no set standards of app development for startups. Typically, there are three ways to build an app:
Lets have a look at these options
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:
While in future we can expect to have reliable app builders, but right now, they are poor choice to build a dating app.
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.
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?
Apple will crack down on such rip-off’s, sooner or later!
There are other downsides to the approach as well:
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.
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.
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:
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:
The goal here should be to create features for usability, performance and security.
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:
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.
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:
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.
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:
Or, you can have all of them serving different purposes within your app. For a MVP, that’ll be an overkill.
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.
It’s extremely easy to decompile your app. Once your code has been decompiled, attackers can:
To make attacker’s work a bit more difficult, you need to:
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.
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:
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:
Each has it’s own merit and demerit. The last one is mainly used if there’s a budget constraint.
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:
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:
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.
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:
By observation, testing and iterations you can easily come up with a mathematical formula that can provide upto 90% accuracy for your MVP.
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.
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.
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.
Upon receiving the flags, an admin can manually moderate and take justified actions.
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.
Create your free account to unlock your custom reading experience.