What to Build in Your App's First Version (And What to Save for Later)

What to Build in Your App's First Version

There is a reliable pattern in app builds that succeed: the first version is embarrassingly simple. There is an equally reliable pattern in app builds that fail: the first version tries to be everything.

Here is the framework for deciding what belongs in v1.

Always in V1

User authentication: Users need to create accounts, sign in, and recover access if they forget their password. This is infrastructure, not a feature — it is always in v1.

The core action: Whatever the one thing is that your app does — the single action that creates value for your user — it must be in v1. This is the whole point of the product. If your app is a habit tracker, habit logging is in v1. If your app is a marketplace, listing and browsing are in v1.

Core data display: Users need to see the results of their actions. A habit tracker must show logged habits. A marketplace must show listings. Without this feedback loop, users cannot verify the app is working.

Basic error states: What happens when something goes wrong? Empty states, connection errors, and loading states all need to exist — even if they are simple.

Often in V1 (Depends on Your Core Action)

Push notifications: If your core loop requires reminding users to come back, notifications belong in v1. If not, they can wait.

Payments: Only if revenue generation is central to the v1 hypothesis. If you are testing whether users find value before testing whether they will pay, defer payments to v2.

User profiles: Basic profiles (name, photo) belong in v1 if they are part of the core action. Full social profiles, public pages, and follower systems are almost always v2.

Search and filtering: If your app has more than ~20 content items, basic search belongs in v1. Advanced filters are usually v2.

Almost Never in V1

Social features: Sharing, following, liking, commenting — these all require an existing user base to be valuable. In v1 you have no user base. Build the solo value proposition first.

Referral programs: You need to understand retention before you invest in acquisition mechanics. Referral programs in v1 are premature optimization.

Admin dashboards: You can manage early data with direct database access and spreadsheets. A full admin panel is almost never needed at v1 scale.

Analytics dashboards for users: Give yourself time to understand what metrics matter before building them into the product.

Integrations: Third-party integrations (Zapier, Slack, calendar sync, CRM connections) are almost always v2 or later. They add significant development complexity and are rarely critical to proving your core hypothesis.

Dark mode: Build one good mode. Dark mode doubles UI QA effort and adds zero user value at v1 stage.

The Test

For every feature candidate, ask: "If this feature does not exist, can we still test whether our core hypothesis is true?"

If the answer is yes, the feature is not in v1. This test is more reliable than any framework or rule of thumb.

Core Value vs. Supporting Features

Before you can decide what goes in v1, you need to separate two kinds of features that founders constantly confuse.

Core value is the one thing your app does that no spreadsheet, group chat, or competitor already does well enough for your user. It is the reason someone opens your app instead of doing nothing. Remove it and there is no product.

Supporting features make the core value easier, faster, or more pleasant to use. They matter — but only because the core value already exists. Remove a supporting feature and the product is worse, not gone.

A simple way to tell them apart: if you described your app to a stranger in one sentence, the core value is the part you cannot leave out. Everything you would only mention in the second or third sentence is a supporting feature.

The mistake is treating both as equally urgent. They are not. In v1, you build the core value to a high standard and the supporting features to a "good enough to not get in the way" standard — or you cut them entirely. Founders who polish supporting features before the core value works are decorating a room nobody has agreed to rent yet.

Why Authentication Belongs in V1 but Social Sharing Usually Does Not

These two features sit on opposite ends of the v1 decision, and understanding why teaches you the whole principle.

Authentication is in v1 because it is the floor the product stands on. Users need to create an account, log back in, and recover access when they forget their password. Without it, you cannot save anyone's data, you cannot tell one user from another, and you cannot measure whether anyone comes back. It is not a feature you are testing — it is the plumbing that lets you test everything else. Modern backend tools like Firebase and Supabase include authentication out of the box, so it costs you little to include and breaks everything to omit.

Social sharing usually waits for v2 because its value depends on something v1 does not have yet: other people. Following, in-app sharing, public profiles, and activity feeds only create value once you have a base of users producing content worth following. On launch day you have none. Building a social graph before you have users is building a party hall before you have invited anyone.

There is a deeper reason to defer it. Social features change what you are testing. If your app only has value when a user's friends are also on it, you can no longer measure whether one person finds the product useful on their own. That single-user value — does one person, alone, get something out of this? — is the cleanest signal of product-market fit you will ever get. Social mechanics blur it. Prove the solo value first, then layer the network effects on top.

Use Jobs to Be Done to Decide

The most useful framework for separating core from supporting features is Jobs to Be Done, popularized by the late Harvard professor Clayton Christensen. Its central idea is simple: customers do not buy products, they "hire" them to make progress on a specific job in their life.

Christensen illustrated it with a fast-food chain trying to sell more milkshakes. Traditional research on flavors and customer demographics went nowhere. The breakthrough came from asking what job customers were hiring the milkshake to do. A large share of shakes were bought early in the morning, by commuters who wanted something to occupy a long, boring drive — one-handed, slow to finish, and filling enough to hold off hunger until lunch. The chain made the shake thicker so it lasted the whole commute. They were not selling dessert. They were selling a better drive to work.

For an app founder, the framework turns every feature decision into one question: does this feature directly help the user finish the job they hired my app to do?

To apply it:

Write the job, not the feature. "Help a freelancer get paid faster" is a job. "Add a payments tab" is a feature. Start from the job.
Identify the job's critical path. What is the shortest sequence of steps that gets the user from "I have this job" to "the job is done"? That path is your v1.
Test every other feature against the job. If a feature does not move the user along that path, it is a supporting feature at best and a distraction at worst. It waits.

The framework cuts through founder bias because it forces you to argue from the user's goal, not from your wish list.

What Instagram Launched With vs. What It Became

Instagram is the clearest documented example of a deliberately narrow v1 — and of how much can be added later once the core works.

The app did not even start as Instagram. Founders Kevin Systrom and Mike Krieger first built Burbn, a location check-in app with many features. It struggled. They noticed users mainly cared about one thing — sharing photos — so they cut almost everything else and rebuilt around that single behavior.

When Instagram launched on 6 October 2010 as an iPhone-only app, it did roughly one job: capture a photo, apply a filter, and share it. The first version had filters, likes, comments, and a simple chronological feed. That was essentially the whole product. The filters mattered because they let ordinary phone photos look good, which removed the main reason people hesitated to post.

Almost everything people now associate with Instagram came later, after the core was proven:

Video arrived in June 2013.
Direct messaging arrived in December 2013.
Stories launched in August 2016.
Shopping features and Reels both arrived in 2020.

None of those were in v1. The founders shipped one job done well, then earned the right to add the rest. Had they tried to launch with stories, messaging, video, and shopping all at once, they would have spent years building before learning whether anyone wanted to share a filtered photo at all.