Building Consumer Social Apps | Quantum Certainty

I recently recorded a lecture at Toronto Metropolitan University on building consumer social apps, you can watch it here.

This is a seriously dense video containing nearly everything I know about building great consumer social apps distilled into about an hour. We go over the psychology of consumer apps, philosophy of building the apps, components involved, handling feedback, scaling, and so much more.

Most of this lecture was based on firsthand experience and personal anecdotes I've learned over the course of my nearly two decades in software so far, but I need to extend a big appreciation to Nikita Bier. Many decisions I've made as a social app founder in the past is thanks to his great guidance and even better tweets. I highly suggest you follow him for more consumer social app advice, he's the best.

And, of course, thank you Zuck for inspiring a generation.

To supplement the video, I'm including the original slides and my lecture notes for the video below. Enjoy!

Slide Deck

Download the slide deck here.

Lecture Notes

Understanding why consumer apps are a bad idea

How popular Facebook was, how revolutionary it was

When it launched in February of 2004, within 24h it had 650 users signed up (in a time when the internet was not as pervasive as it is now)
Within two weeks it grew to about 4300 users
By March it had already gotten it's 10,000th user once it expanded to include Columbia, Stanford and Yale. (The Crimson)
By the end of 2004 it had 1 million active users, and 6 million the following year (Yahoo)
You have to understand that during Facebook's uprising, it was a sought after product. It was exclusive to a few universities to start with in 2004 and 2005, and other universities were literally begging for it to be introduced at their school

Understanding what they saw when they realized they had a hit

There was rapid growth - Within it's first month, over half of the undergraduate population at Harvard had an account on Facebook
Other universities were trying to get access to Facebook, and once they finally did it spread like wildfire there too, very high user growth
People lived on Facebook - there was very high engagement, it was some people's one and only destination when they accessed the internet
It was different enough form the competition to stand out, there was an emphasis on real genuine identities unlike MySpace and Friendster, and putting that at the forefront of the website (MySpace hid it, Friendster allowed for usernames) (Wikipedia)
So there it is:

Rapid growth
High demand
High engagement
And actual differences that made them stand apart from competitors at the time

Understanding metrics to see if you're on the right track

KPIs like growth metrics, how many people does one person bring with them (every 1 person brings 5 people thru invites)

User growth rate, this has to be like wildfire, especially now that everyone is glued to their phones and computers. This stems from the network effect, and in this case, you should be aiming to onboard 5 new users for each signup you create. If you are not hitting that, you probably don't have a hit (yet)
User engagement, this should be very high, as soon as it starts to slip you begin losing the foothold you have on your user base. If the app feels empty and boring it will be empty and boring. It's a self fulfilling prophecy.
Needless to say, but your retention rate should be extremely high, especially in the beginning. If your app is too boring to keep people on it in the first couple of days, how will you keep them a month from now?
How many friends does each user have on the app? You have to understand that we are creatures of tribalism, deep down we don't want to stand out and we want to do what the crowd is doing. So maximize how many friends a user has on the platform
DAU/MAU are good metrics too, but they are the result of the other indicators I described above

Understanding your target audience, demographic, geographic location

Why do people download apps? The three reasons

To find a partner or love interest
To make/save money
To forget the world exists

It is really difficult to get adults onto new apps, most of them are already stuck in their own habits

Their friend groups are distant, they don't talk to each other as much (reduces network effect)
They have their apps that they use consistently

This is why younger audiences, like high school and university aged people are targeted most by social app founders

They are far easier to build with, are more willing to try things, more susceptible to psychological tricks social apps take advantage of, they have more time to spare, don't want to be left out, and they talk to their friend. Their friends are their entire life.

So you have to understand your target audience and demographic. Who they are, what do they want, what of the three categories do they fall into, why, and how can you use psychology to appeal to their desires
Think about geography. It's far easier to saturate smaller markets than larger ones

Think about Facebook, if they launched to all of the US, it would probably be pretty hard for users to find friends, stalk their crushes (finding a love interest), and brag to their Facebook friends online about how great their lives are (also in the pursuit of finding a love interest)
The reason it worked so well was because they launched in tight communities, communities where people talked to each other, users knew each other either very well or enough to recognize a profile in front of them as the cute guy or girl they passed by in the hall on the way to a lecture.
You need to find small target markets and saturate those. Once you saturate one, you can expand out, like Facebook, and keep going.
This is how most consumer apps start in general, but especially social consumer apps. Some target markets are physical places like towns, cities, schools, others are collectives online or in person. The easier to meaningfully saturate, the better.

Gas, tbh (high schools)
Facebook (universities)
MySpace (music communities)
PayPal (sellers on eBay)

With that in mind, let's design the idea of an app

Messaging dominant? Posting dominant? Consumption dominant? Another type?
How involved do we want the user?

Do we want them having to produce content in order for it to work?
Are they mostly consuming content? Where does this content come from?
Are they responding to their friends? Are they having to do something consistently?

Medium (short form video, long form video, text, images)?
Can we take advantage of psychology? (Mystery, habits)

Psychology is a very powerful tool to engage people
The mystery of whether or not someone likes you is a powerful one and plays into one of those three key factors

Tbh and gas both had this effect

Habits are also a powerful tool. Dating apps and TikTok use swiping (which is why so few differ from that pattern), BeReal uses a notification like Pavlov's Bell, Snapchat uses streaks
Can we show people how much they are liked? How important they are? (Likes, views)
Can we give people the opportunity to live vicariously through others? Develop bonds with people over the internet? (Tiktok, YouTube)
Can we make people feel like they are missing out socially if they don't engage with our app? (Tiktok, snapchat)

There should be one central action the user does to engage with your app. Define it and make it as simple as possible.

Tiktok, swipe
Tinder, swipe
Snapchat, take a photo
Gas, answer polls

How are we creating a network effect?

Sync contacts? Share on other platforms? Word of mouth?

Syncing contacts is an absolute. This is how you find who knows who, build out social graphs, connect people at schools, send out invites, and get to know the user's network better than they do themselves
Sharing onto other platforms is also key, especially now that the world is dominated by a few big players. They should be easy to share, be something a user actually wants to share (appeals to them, makes them seem important, is funny), and should be an implicit call to action to download your app (or at least inquire about it). Do not make it an advertisement, that's lame and nobody will post it.
Will word of mouth work? If you are taking advantage of some psychological traits it could, but more often than not you should rely on actual measurable methods of getting people onto your app. You can measure how many invites you send out and how many invites are answered to by having those phone numbers join your app.

Be aggressive

It is important to be aggressive about it. Don't be annoying.
You would be surprised how little kids care about small things like syncing their contacts. It's not a thought that crosses their mind, it's a quick "allow" click and they move on.
You can entice people to invite others. Do it in a way that is complimentary to the user, takes advantage of some psychology, but you can directly ask them occasionally and they will probably answer positively (by fulfilling your request).

Let's understand how to design the app itself, what to keep in mind

User experience (like crack, easy to use, simple to figure out, easy to understand)

Users are dumb. Maybe when you think of a specific user in a vacuum you don't realize that, but it's true. Always design your app to be as simple and easy to understand as humanly possible. Confusion will lead to less use.
Design apps like casinos. Make it like crack. You can add colour, emojis, animations, stuff that makes it look interesting and visually appealing to look at. Keep them wanting to come back.
You can gamify the app. Create ways of people advancing, earning something for their app usage, rewards that mean something to their motivations on the app. If you are there to find a love interest, and your app revolves around anonymous polls, maybe once you have enough points from completing polls you can get a hint about who called you cute. That's the key too, it's a hint. "Someone in grade 11 called you cute" is a lot more powerful psychologically than "John called you cute". It keeps them thinking, guessing, and coming back for more hints.
The flow should be super simple and feel like they're already on it. Lean into exclusivity, remove annoyances like confirming passwords (or passwords all together).
Use services they are used to and already have setup. If you're building a mobile app, which if you're making a consumer social app today I highly suggest that be how you do it, make everything revolve around that phone. Payment details needed? Apple Pay. Signing up for an account? Use one-time-passcodes sent to the phone and let the simple and clickable passcode button above the keyboard take care of that. Learn the device they are using and leverage that hardware and software that they're already used to as much as you possibly can. Anything new is another point of friction that could turn someone away from using your app.

User interface (smooth, slick, animations, clean, uncluttered)

You should design your user interface like a casino. Make it smooth, slick, clean, and uncluttered.
Lean into tasteful animations, make it seem snappy and quick.
Leverage the device you're on; if you're building for iPhones, match the iOS look.
Make everything simple, clear, and concise. Instructions should be short and to the point. Direct them through any complicated steps with small tutorials or guided tours.
Push them to complete the one action you defined for them. Make it easy to do and psychologically appealing to do it. Guide them through it the first time, then make it front and centre in the future.

Philosophy of building out the app

Make everything a component, frontend and backend

If you are able to build each part independently, swap them out, and reuse them as you need to, it makes building iterations on your social app a lot easier (because odds are the first app you release is not going to be the slam dunk hit you think it will be)
Design everything as it's own subsystem which contributes to the greater system. In some ways this is seen as a micro services architecture, but it doesn't have to be. Ease of maintenance and reducing points of failure is key, so if you can build these components as parts of only one or two services, that's ideal. Monolithic doesn't always make sense, but in the beginning it can. If you can build it as a monolith in the beginning but the services easily divisible to scale out individually if the time comes, that's ideal.
Do not tie your frontend and backend together. All-in-one frameworks are great for some projects, but when fast iterations are needed, it's not ideal. This is going to give you a lot of flexibility to change frameworks, hosting providers, platforms, you name it, as you need it.
Build with simple tools. Use industry standard frameworks and tools. Do not build your social media app using Rust, or Go, or another complicated backend. It might seem cool on paper and maybe the requests per second you can handle is far higher than python, but if you're spending 10x the amount of time developing features, does it really matter? Keep it simple stupid.
Do everything in house. Do not hire outside help. Try to make sure either your founders or engineers with vested interest in the app's success are familiar with the entire technology stack. If something goes wrong you need to be able to fix it right away.
Each part should be easy to toy with and change. Experiments should be easy to do and undo. The parts should not massively influence each other, if you change your timeline algorithm in your recommendation system, it should not affect your frontend or the gateway serving that content. Everything should be compartmentalized in a way that encourages experimentation.
When your app fails, and it probably will the first few times, you want it to be easy to pickup what didn't work and iterate on it. You should be able to say "You know what, my friend graph didn't work. I need to work on that", and it should be very easy to do so.

Try for native experiences, predominately people in your demographic use what devices (RU Mine was 74% iPhone users)

Focus on the devices where your demographic is most likely to use your social app.
In most cases, especially amongst high school and university aged audiences, it's iPhones
74% of users on RU Mine used iPhones
It is hard to build for both Android and iPhone at the same time; so don't
There are frameworks, like React Native, which even I've used, that allow you to develop once for both apps, but you will just never get the same feel of a native app which is so crucial with social
Just build for iPhone
If you can perfect the native experience and you know vast majority of your audience uses iPhone, forget about the other 20% and focus on perfecting that 80%

Have multiple providers for everything, try not to have single points of failure (they will try to squeeze you for every dollar you have)

Once providers notice your success, they may start to squeeze you for more money
This is why it's a good idea to always have a backup plan, a second provider ready to go (or actively being used)
If providers start taking advantage, you can pit them against each other to see who offers you a better deal.
Even if your providers aren't trying to take advantage, if your app begins to explode, it's going to get costly
Having two competition providers offering you the same service means you can negotiate better terms and not feel locked into a contact with one company
Even from a technological standpoint, this is going to reduce your single points of failure. If one provider has an outage, at least you have a second one you can fallback to immediately in most cases (if it's an AWS regional outage, you might be out of luck)

Things should not break, it's a bad look. Build safety nets in as much as you can

It's inevitable that things are going to break, but you should try to prevent it from happening as much as possible
A user interaction failed? Try to recover it
Try not to display warning messages to the user unless it's absolutely crucial. It makes your app look sloppy.
One of your backend technologies break? Build a safety net, something that collects pending requests while it's being recovered
Have load balancers, make sure your service is as distributed as it can be without becoming more of a hassle than it's worth (load balancing within an AWS zone is relatively easy, load balancing and keeping databases up to date across datacenter regions is far more difficult)

Build with the ability to scale in mind, but do not build FOR scale at the start (very important!)

Understand what parts of your technology stack is not going to scale well, and prepare backup plans for it. Try to pick technologies that can scale if needed.
Do not optimize before it's needed. It's an engineering fallacy to build for 1M users when you have 10, do not fall victim to it. Save your money and your time. Build with technologies that have potential to scale, but operate small and lean for as long as you can.
Auto-load balancing and auto-scaling can be helpful tools, make sure your technologies work with it and will properly take advantage of it when the time comes (if your backend scales to handle the requests but you're still stuck with a single database node, you're going to be read/write saturated. Make sure you understand database replication, in this case, and how it's going to work when the time comes. Do not set it up until it's needed, unless it's very very cheap!)

Components of social apps, deciding what is important, complications with each step

Friend/social graphs

This is how you determine who knows who, what connections you can suggest, who you can invite, who may like one user more than another, who has more influence over a user versus another
This is an integral part in your app, this is where you will dump notable interactions like messages, friend requests and connections, contacts
Almost every app requires this and it plays a big roll in many other systems
An emphasis on clean data here will be the most important thing since the data in this system flows into the other subsystems downstream

Recommender systems

This is the system that will recommend friends, posts, messages, content, gamification steps, whatever comes next for the user
This should be highly tuneable, easy to change, and use data from your social graph to influence it's decisions
This means any changes you make in the social graph should directly influence the results of your recommender system
It's important to tune this for both accuracy and speed -- Your users do not want to wait 4s for your timeline to load with recommended posts, nor do they want posts about cats when they only care about dogs
You should use analytical metrics like engagement, time spent on individual posts, interactions, and how long they spend on their recommendations as heuristics for tuning this
It is great if this is based on machine learning, but it doesn't have to be. Do not over engineer it just because you can. Many engineers were able to do exactly this before machine learning became as widespread as it is now, so why are you any different?

Messaging

This is the system that allows users on your own app to talk to one another
Maybe its real time private messages between just two individuals, maybe it's real time group chats, or maybe it's asynchronous picture messaging like Snapchat
It's important to understand what type of messaging you need, if any. Sometimes it's in your best interest to promote messaging outside of the app (it could mean the word spreads more). You could also miss out on important analytics that you can further use to tune your recommender system, though (if a user shares a post with another user, that tells you they really like it)
Messaging can be a large undertaking, especially if you're doing fancy features like encryption, group chats, or real time messaging. These add complexity and other systems you have to tend to, so make sure your app requires it before you start adding it.

Timelines (either you write to all timelines at post time so that they're reads to reduce table joins, or you read on user request)

This is the system that delivers the main user generated content to each user of your app
This could be based on the recommender system, or totally separate and just display posts chronologically (For you versus Following tabs on Twitter/X)
You need to understand the complications with timelines; are user timelines generated on read or on write? What I mean by that is, when user A makes a post and user B follows user A, are we writing user A's post to a data structure or database table representing user B's timeline? Or are we waiting for when user B loads their timeline to check all the users they follow for new content.
Both are fundamentally different philosophies and have drawbacks to one another. Creating a timeline on write means you are paying more for storage, but when the user loads the app they get all their content immediately since it's ready to go. On read means you're saving on storage, but now your timeline call requires joins on tables and could take longer to load.
It doesn't seem like a big issue, especially when you're a small app, but you need to think about the implications on scale and weigh them with the complications they introduce in the short term. Is it worth it?
This is something Facebook and Twitter/X dealt with in a major way years ago and still work on today

Searching

This is how your users can find one another or content
This system involves creating an index of all your users and their relation to one another based on your social graph, content of posts, maybe their geolocation or community, and presenting the results to your user when they search for "Carly" or "Funny dogs"
There's a small recommendation system in here, it doesn't have to be crazy but it certainly can be, that decides who is the most relevant Carly to show to your user, or the best "funny dogs" post to present to your user based on similar likes
Of course, this adds a lot of complexity and now involves a whole search service, which is a lot more data to manage and indexes to build

This is probably one of your most important areas to focus on
This is how the user initially signs up for your app
This is where you really should lean into simplicity and the services that already exist on your user's phone
Reduce the amount of screens, keep authentication simple, I suggest OTP, and make a lot of it as automated as you possibly can (if your new potential user is coming from an invitation to your app, automatically fill in their school details)
You can apply some extra social proofing by show the name and image of the person that sent an invite to your potential user, tiktok does a great job of this with the banner above all their share links if you visit them in browsers instead of the app. It's one more reminder for your potential user to join the crowd, and become one with every else.

Posting (posting into groups hides content, makes the app feel dead, how can you make it feel alive?)

This can be your content and how it's managed
How do you deal with posting? Is it into groups and group chats?
One of the easiest and biggest mistakes you can make, which I made too in my first apps, was encouraging people to post into private groups. Why? When a new user joins the app and isn't in a group, what do they see?
This is an issue Discord and other community-driven apps fall into. If the user base isn't already there for your community, you're presented with a blank screen that makes the app feel dead. That's bad. You need it to feel alive, active, and a place that ignites that fear of missing out
So ask yourself, how can I make it feel alive? How can I encourage people to post publicly?
Maybe that's adding interactions, animations, or public profiles. Find something that works and double down on it.

Real-time syncing, web sockets, making the app literally feel alive

This is a good way of making the app feel alive at the cost of complexity
You can add real-time syncing, or web-sockets, to give real time updates to posts in a user's timeline. You can constantly be updating the amount of likes/comments, maybe even showing an animation. That makes it feel like there are people using the app right now.
Of course, a downside, besides the complexity, is that if your app is dead, it really feels dead.
You also now have to handle a lot of requests hitting your backend at the same time, which could greatly influence how well you can scale out (especially if for every user you're fetching live updates for even three posts; you've now introduce a 3x required scale on your databases just to handle those reads at some consistent and frequent interval)

Live streaming video or audio

This is another big one, one that you see a lot of big apps do
If you've noticed, most of them introduce it later into the app's lifecycle, and that's for a good reason
Live streaming is very expensive. There is a reason why Twitch still hasn't returned a profit.
The bandwidth cost of streaming audio or video live to many concurrent viewers at once is immense
It can be a very cool way to make your app feel alive, present, and active, it may even be a novel way to interact with others, but understand sending video packets is far more expensive that sending bytes of textual data
This can be a massive money sink, as well as a lot of complexity, make sure it's worth it

Posting and hosting photo and videos

Similarly, hosting photos and videos comes with a complexity and bandwidth cost too
You are dealing with three factors now, storing the photos and videos, serving the photos and videos, and bandwidth cost
Storing the photos and videos is self explanatory, you are going to be buying a lot of storage, but there's a catch besides just volume of storage
To serve photos and videos effectively, you need fast storage. You need SSDs and RAM caches. Your cost per GB just went up a lot.
Then, on top of that, you are still streaming video or image packets to your clients. This becomes a big cost sink as well; it's cheaper than live streaming, but a cost you should understand before deciding your app is going to have photo and video hosting.

Analytics

This is a crucial part of any app, this is how you collect your KPIs, service and performance metrics, and other heuristics you use for your recommendation systems.
You need to nail this down, this should be a very resilient part of your technological stack
There will be points in time where the data from this app will be the sole determining factor for decisions you make, whether that's new UIs, switching schools, or switching social media ideas altogether
Build this once, build it right; or pay a service to do it properly for you.
Just know that this is one of those areas where service providers are going to squeeze dollars out of you. Probably should keep an eye on who you're working with and find backup plans

Reporting, safety, banning, content moderation (required by ToS on AppStores)

This is another important system in the stack since it's required to be allowed onto app stores
You have to have a content moderation plan if you're allowing for user generated content on your platform. It doesn't have to be crazy, it can be a human manually looking at them at the start, but you need to know how to scale it and that it must exist.
Reporting and banning users is also a requirement of app stores. You should build this into your recommender systems and social graphs.

Launching the app

In specific geographical area
Keep your eye on the metrics
Understanding when to shut it down and try again
Identifying what is working and what is not working, iterate

Scaling

Make sure you actually have to scale

What metrics are you looking at that tell you it's time to scale?
Is there another reason why those metrics could be returning that?
Is there a simpler change you can make than scaling your tech stack?

Understand what parts need to scale and why (is it bad code? Do you need to build indexes? Do you need to swap out libraries/frameworks? Is it worth it?)

Does your database have to scale? Or do you have to optimize your SQL queries? Do you need to create indexes?
Can you not handle enough requests per second because you're hitting the limit of your machine? Or do you have to optimize your code? Do you have to swap libraries/frameworks?
It is worth doing the work to optimize or is your time better spent working on some other aspect of the business? (And taking a hit to your revenue as a result)

What parts of scale are going to tank your business (live streaming, video, photo, bandwidth related) and not worth continuing without funding/help

Is what you're planning to scale going to cause you to tank your business because of cost? If it's bandwidth related, and therefore cost related, is it worth it? Do you have an exit strategy or a way to handle it when it becomes too much?

Dealing with backlash/feedback/criticism

Understanding why criticism can be worse or at least feel worse

it's coming from actual people with actual names, maybe names you know if it's a community local to you

It comes from people that don't actually think of you as a person, you're an entity, try not to take it personally

The comments are going to be harsher than reality, they don't think of you as a person, you are the app

Weed out the bad criticism from the constructive criticism
Understand that the consumer usually doesn't even know what they want

You should really rely on them for bug/performance issues, you need to have a clear idea of where you're headed regardless of what they want

If your app gets big enough, there could be other competitors starting rumours trying to take you down, or they may naturally start

Address what you have to, but stay cool, calm, and collected