What belongs in a social app MVP, and what can wait

Almost every social product we are asked to scope arrives with a feature list copied from a mature app. The list is not wrong about what the product will eventually need. It is wrong about the order, and the order is the entire question, because a first release is a bet about which unknowns you want to resolve first.

The pattern is consistent enough to name. Founders overinvest in the features they can see in a competitor and underinvest in the systems that competitor built years ago and no longer shows. Ranking, stories and live video are visible. Media pipelines, abuse tooling and graph storage are not, and they are where the schedule actually goes.

This guide sets out what has to work on day one, what can wait without harming the product, and how to phase the build so the expensive unknowns get resolved early. It is written from scoping conversations rather than from theory, and it links out to the relevant mobile app development services only where a decision genuinely needs a team behind it.

The four systems a social MVP cannot launch without

A social product is not a feed. A feed is a view over three things that must exist underneath it: people, content, and the relationships between them. Add the rules that decide what stays up, and you have the whole irreducible core. Every social application, from a niche community of two thousand runners to a general network, has these four, and no social application works without all four.

The test for whether something belongs in this list is simple. Ask what happens on the day the product is live and a real stranger uses it in a way you did not intend. Identity failures mean you cannot tell who did it. Content failures mean the thing they posted does not render. Graph failures mean nobody sees anything. Moderation failures mean the thing they posted is still there tomorrow, and there is now a screenshot of it.

The irreducible core, with what each system actually contains

Identity

Sign up and sign in

Email plus at least one social provider. Passwordless is cheaper to support than password reset flows.

Profile

Display name, handle, avatar, bio. The handle needs a uniqueness rule and a reserved word list from day one.

Account states

Active, suspended, deleted. Deletion must be real and must be testable, because it is a legal obligation in most markets.

Session security

Token refresh, device list, sign out everywhere. The last one is what a compromised user needs at 2am.

Content and media

The post object

One schema covering text, media references, author, timestamps, visibility and state. Changing this later is a migration.

Upload

Direct to object storage with signed URLs, never through your application server.

Transcode

Images to two or three sizes, video to at least one streamable rendition. This is asynchronous work with a queue.

Delivery

A CDN in front of storage, with cache rules that survive a post being deleted.

Social graph

Edge model

Follow (asymmetric) or friend (symmetric, needs a request state machine). Pick one; supporting both doubles the surface.

Blocking

A blocked user must disappear from every surface, not just the profile. This is the query that gets forgotten.

Fan out

On write for small graphs, on read for large ones, hybrid for accounts with many followers.

Discovery

Search by handle plus one contextual suggestion source. An empty graph is the real cold start problem.

Moderation and safety

Report path

On every piece of content and every profile, in two taps, with a reason taxonomy you can act on.

Review queue

An internal tool with actions, notes and an audit trail. A spreadsheet is not this.

Automated screening

A hosted classifier for the categories with legal exposure. Precision matters less than coverage at this stage.

Appeals

A path back for a wrongly removed post, because false positives are certain and unappealable bans lose good users.

Read this as a scope document rather than an architecture diagram. Each row is work that has to be specified, built and tested before launch, and each one has a failure mode that is visible to users on day one.

The feed: why reverse chronological is a real answer at launch

The single most common scoping mistake is to treat a ranked feed as a launch requirement. It is understandable. The feed is the product to a user, and every reference product has a sophisticated one. But ranking is a machine learning problem, and machine learning problems need training data, which at launch you do not have and cannot fake.

A ranking model learns from engagement: what users opened, how long they stayed, what they skipped. On day one there is no engagement history, no baseline to compare against, and no traffic to run an experiment on. A ranker built in that vacuum is not a ranker, it is a set of hand-tuned weights that nobody can evaluate, and it will be thrown away the moment real data arrives.

Reverse chronological, filtered to the accounts a user follows, is a complete and honest feed. It is also the strongest possible diagnostic: if a chronological feed of the accounts a user chose is boring, the problem is that the graph is empty or the content is thin, and a ranker would only have concealed that. Ship the simple feed, watch where it fails, and let the failure specify the ranker.

Which feed should the first release ship?

How much content does a typical user see per session, and where does it come from?

• Users follow a handful of accounts and content volume is low

  Reverse chronological, no ranking, no algorithmic insert

  With low volume the user can see everything, so ranking has nothing to choose between. Effort belongs in helping people find accounts worth following, which is the actual constraint.

• Users follow many accounts and miss content between sessions

  Chronological with a lightweight recency and affinity score

  This is the first point where ranking earns its cost, and a simple two-signal score captures most of the value. It also produces the interaction data a real model will need later.

• Discovery matters more than following, as in a short video product

  A candidate pool with exploration, built as a real system from the start

  If the product's core promise is showing people things they did not ask for, ranking is not a later optimization, it is the product. Scope it as such and expect it to dominate the budget.

Ranking is not a maturity signal. It is a response to a specific problem, and shipping it before you have that problem means tuning against noise.

Feed decisions that age well, and ones that do not

Do this

• Store the feed as a query, not a table, at firstReading the graph at request time is fast enough for early scale and lets you change ranking without a backfill.
• Log every impression from day oneYou cannot recover engagement data retroactively. Logging costs almost nothing now and is the only thing that makes ranking possible later.
• Cap the feed windowFetching the last few days rather than all history keeps the query flat as the content table grows.
• Make the empty state a real screenMost new users see an empty feed first. Treating it as an onboarding surface rather than a null result changes activation.

Not this

• Precomputing feeds before you need toFan out on write means every post writes to thousands of rows, and every ranking change means rebuilding all of them.
• Mixing recommended content in silentlyUsers notice, and it damages trust in a product whose whole premise is that they chose who to hear from.
• Infinite scroll with no stateWithout a stable cursor, users see duplicates and gaps, which reads as a broken product rather than a paging bug.
• Tuning weights by intuitionHand-tuned ranking with no measurement is unfalsifiable. Nobody can tell whether a change helped, so nobody can ever remove it.

Moderation is a product surface, not a filter

Every social product will be used for something its founders did not intend, and the interval between launch and the first serious incident is measured in weeks, not years. This is not a pessimistic view of users. It is arithmetic: a product open to the public is open to everyone, and a small fraction of everyone is a real number as soon as the user count is real.

The reason moderation gets deferred is that it presents as a cost with no visible feature. That framing is wrong in a specific way. Moderation is what makes the content on your platform something people want to look at, which means it is not a tax on the product, it is a component of the thing you are selling. An unmoderated social space does not stay neutral, it degrades, because the users who leave first are the ones who had somewhere else to go.

There is also an asymmetry in when the work can be done. Building a review queue before launch is a contained engineering task. Building one during an incident means doing it while the backlog grows, while the press asks questions, and while the platform stores are reviewing your listing. The same code costs several times more in the second situation.

The minimum viable moderation system, in build order

1. 1

   A report button on everythingDay one

   Every post, comment, profile and message needs a two-tap report path with a small set of reasons that map to actions you can actually take. A free text box alone produces reports nobody can triage.

2. 2

   A queue with an audit trailBefore launch

   An internal screen listing open reports with the content, the reporter's reason, the author's history, and buttons for the decisions you allow. Every action records who took it and when, because you will need to answer that question.

3. 3

   Automated screening on uploadBefore public launch

   A hosted classifier on images and text covering the categories with legal exposure. It runs before content is visible, and anything it flags goes to the queue rather than being silently deleted.

4. 4

   Rate limits and new account frictionBefore public launch

   Most abuse at small scale is volume abuse from fresh accounts. Posting limits that relax with account age stop more harm than any classifier, and cost a day to build.

5. 5

   An appeals pathFirst month

   A way for a user to contest a removal, reaching a human. False positives are guaranteed, and a wrongly banned enthusiastic user is both a support problem and a public one.

6. 6

   Published rulesBefore launch

   A plain-language page saying what is not allowed. Without it, every enforcement decision looks arbitrary, and you have no ground to stand on when one is challenged.

This is roughly two to three sprints of work for a small team, and every step is useful on its own, so it can be interleaved with feature work rather than blocking it.

The media pipeline is where the budget actually goes

If a social product carries photos or video, the media pipeline is usually the largest single piece of infrastructure, and it is almost never the largest line in the initial estimate. The gap comes from thinking of media as a feature (users can post a photo) rather than as a chain of five services that each have to work independently.

The chain is upload, process, store, serve, and expire. Upload means signed URLs direct to object storage, because routing user files through your application server turns every large upload into a request timeout. Process means an asynchronous job that produces the renditions you serve, which needs a queue, retries, and a way for the client to know the work finished. Store means deciding what you keep and in which storage class. Serve means a CDN with cache rules. Expire means the deletion path, which has to reach storage and cache, not just the database row.

The cost profile is also different from feature work in a way that matters to a founder. Features are paid for once. Storage is paid every month, forever, for everything ever uploaded, and it only grows. A product that lets users upload video without a retention policy is signing an open-ended contract on behalf of a company that does not have revenue yet.

Media decisions to make before the first upload ships

• Which renditions do you generate?Two image sizes and one video rendition is usually enough at launch. Every extra rendition multiplies both processing time and storage.
• What is the retention policy?Do uploads live forever, or does unused media move to cold storage after a period? Deciding later means deciding after the bill arrives.
• What happens while processing?The client needs a placeholder state and a completion signal. Without one, a slow transcode looks like a failed post.
• Is the original kept?Keeping originals lets you regenerate renditions when requirements change. It also roughly doubles storage. Both answers are defensible; the undecided answer is not.
• How does deletion reach the CDN?A deleted post whose image is still served from cache is a real incident, especially when the reason for deletion was that the image should not exist.
• What is the upload size limit and who enforces it?Enforced client-side only means it is not enforced. The signed URL policy is where the real limit lives.

Each of these is cheap to decide now and expensive to change once there is user content in the system, because changing any of them means reprocessing everything already stored.

Where a social MVP budget typically lands

Area	Share of build effort	Why it lands there
Media pipeline	20 to 25 percent	Five services, asynchronous, with failure states the client has to render.
Moderation and safety	15 to 20 percent	An internal tool, a classifier integration, rate limiting and an appeals path.
Identity and profiles	10 to 15 percent	Deceptively large once deletion, sessions and account states are real.
Graph and feed	15 to 20 percent	Modest at launch if ranking is deferred, and this is exactly why it should be.
Client application	20 to 25 percent	The visible surface, and the part most estimates assume is the whole job.
Operations and observability	5 to 10 percent	Logging, alerting and the dashboards you need the first time something breaks at 3am.

Proportions from our own scoping work on social and community products, not an industry survey. They vary with content type, but the shape is consistent: the invisible systems take roughly half.

What can wait, and what it costs to defer each one

Deferring is not the same as ignoring. Every deferred feature has a cost of delay and a cost of retrofit, and they are different for each one. The features that are cheap to add later are the ones that sit on top of the core. The features that are expensive to add later are the ones that change the data model, and those should be decided now even if they are built later.

Direct messaging is the clearest example of a feature that looks deferrable and partly is not. Building the inbox later is fine. But messaging changes your obligations around retention, around abuse reporting, and in some jurisdictions around lawful access, and it introduces a delivery guarantee your current architecture may not provide. Decide whether messaging is coming; build it when you like.

Deferral matrix: what shipping later actually costs

	Needed at launch	Changes the data model	Cheap to retrofit
Ranked feedChronological ships instead	No	No	Yes
Direct messagingNew retention and abuse duties	No	Yes	No
Push notificationsNeeds a preference model	No	Partial	Yes
Groups and communitiesA second graph, not a feature	No	Yes	No
Stories or ephemeral postsExpiry on the content object	No	Yes	Partial
Live videoA different infrastructure entirely	No	No	Yes
MonetizationPayments, payouts, tax	No	Yes	No
Content searchAn index alongside the database	No	No	Yes
BlockingFilters every existing query	Yes	Yes	No
Account deletionA legal obligation, not a feature	Yes	Yes	No

Read the last column first. A feature that is cheap to retrofit can be deferred without further thought; one that is expensive to retrofit needs a decision now even if the build waits.

A phased plan that resolves the expensive unknowns first

The purpose of phasing is not to spread work evenly. It is to put the questions you cannot answer from a desk at the front, so that the expensive discoveries happen while the codebase is small enough to change. In a social product the expensive unknowns are almost always the media pipeline under real files and the moderation load under real users.

That leads to a counterintuitive sequence: build the boring infrastructure first and the visible product second. A team that spends its first month on the feed and its last month on uploads will discover its transcoding assumptions were wrong at exactly the point where there is no time left to act on it.

Four phases from empty repository to public launch

1. FoundationsWeeks 1 to 3

   Identity, the post schema, the graph edge model, and a working upload to object storage with one rendition. No client polish at all.

   Done when A user can sign up, follow another user, post a photo, and see it appear, on a real device, from real storage.

2. The uncomfortable systemsWeeks 4 to 7

   The full media pipeline with queues and failure states, the moderation queue, automated screening, rate limits and blocking. Load test uploads with files far larger than you expect.

   Done when A flagged upload reaches a queue, a moderator action removes it everywhere including cache, and a blocked user is invisible on every surface.

3. The productWeeks 8 to 12

   The chronological feed, profiles, onboarding, empty states, discovery, notifications if in scope, and the client work that makes it feel like an application rather than a demo.

   Done when A new user with no follows reaches a useful state without help, measured by watching people who have never seen it.

4. Closed beta and hardeningWeeks 13 to 16

   A real audience under invite, impression logging, observability, the appeals path, published rules, and the operational runbook for the first incident.

   Done when A week passes with real users, real reports and no manual database intervention.

Durations are for a small cross-functional team of four to six people. The exit criteria matter more than the durations: a phase is finished when its question is answered, not when its calendar runs out.

When the graph stops being simple

For most of a social product's early life, the graph is a table of edges and a join, and that is genuinely sufficient. The point at which it stops being sufficient is predictable, and knowing where it is prevents both premature complexity and a late emergency.

The first pressure point is not total users, it is the distribution of follower counts. A network where everyone follows a few dozen accounts stays simple for a long time. A network with even a handful of accounts followed by a large fraction of the user base has a fan out problem immediately, because every post from those accounts touches an enormous number of feeds.

The second pressure point is the filtered query. Blocking, muting, privacy settings and content states each add a condition to the feed query, and they compound. A feed that reads quickly with one filter can become slow with four, and this arrives gradually rather than as an outage, which makes it easy to miss until it is bad.

The graph vocabulary a non technical founder should own

Edge

One relationship between two accounts, such as a follow or a block. The graph is the set of all edges.

Fan out on write

When someone posts, the system immediately writes that post into every follower's feed. Reads are fast, writes are expensive, and popular accounts are the problem.

Fan out on read

Feeds are assembled when requested by querying the graph. Writes are cheap, reads do more work, and this is almost always the right starting point.

Hybrid fan out

On write for typical accounts, on read for accounts with very large followings. What most mature networks converge on.

Cold start

A new user with no connections and therefore nothing to see. Solved with onboarding and discovery, not with ranking.

Asymmetric graph

Following does not require consent, as on a public network. Symmetric graphs need a request and acceptance state machine, which is more work.

These terms come up in every architecture conversation about social products. Knowing them changes the discussion from a briefing into a decision you can participate in.

Frequently asked questions

Scoping a first release well is mostly the discipline of saying what comes later. If you want that discipline applied to your build, work with AgileTech, a software engineering partner in Vietnam that has shipped the unglamorous half of consumer products as well as the visible one.