What Features Should My First App Have?

A property developer came to us with a concierge app for high-rise buildings, a budget already decided, and a list of app features written before our first meeting. They wanted a signature on it. We asked for a proper discovery phase instead, with focus groups and workshops involving the people who actually lived in those buildings. What came back was that the product needed to be far simpler than anyone had pictured. We dropped a lot of the planned features and focused on making the app feel human, rather than replacing systems the building already ran perfectly well.

A first app earns its place by doing one thing properly, long before it does ten things loosely.

It cost less than the original plan and the thing we shipped was better. That's the shape of almost every good conversation we have about a first release. The question people arrive with is what to include. The question that actually helps is what the app is for, and what has to be true for someone to get value out of it on day one.

So this is a practical walk through the features for a first app, in the order we tend to think about them. What has to be there, what can wait, where sign-up gates belong, why onboarding decides your retention, and how to tell a must-have from something that only sounds good in a meeting. Along the way we'll name the projects where we got this right and the ones where we didn't.

The One Job Your App Has to Do

We worked on a grassroots football app where the client kept benchmarking each individual feature against the best single-purpose competitor on the market. Their team management screen was measured against a dedicated team management app. Their booking flow was measured against a dedicated booking app. Each comparison was fair on its own terms, and together they pulled the product in five directions at once.

The real problem wasn't any one of those features. The client was trying to do too much in one product, and there was a reason those features lived in several separate apps elsewhere. Despite a lot of work on our side to make something cohesive and emotionally grounded, we ended up with something overly complex and too verbose, and it didn't serve the audience or the core purpose.

So the first piece of work on any first app is agreeing the single job. Not the five jobs ranked by priority. One sentence that describes what someone opens the app to do, and what good looks like when they've done it.

Everything after that gets measured against the sentence. A feature that helps someone complete the job faster, or with less worry, stays in. A feature that only makes sense if the app is also doing a second job is a signal that you've got two products and a budget for one.

The Features Every First App Actually Needs

Strip away the category-specific stuff and the list of must have app features is shorter than people expect. A skincare routine tracker and a hotel booking app share most of their foundations, and both fail in the same places when those foundations are thin.

App features that earn their place

1. One core action that works end to end, with no dead ends.
2. A way in that doesn't demand everything before the person has seen anything.
3. Navigation with a small number of destinations, labelled in plain words.
4. Account handling and data that people can see, change and delete.
5. Clear feedback for every action, including the ones that fail.
6. A route to a human when something goes wrong.

That's it for version one. Everything else in your backlog is a candidate, and candidates have to argue their way in.

What we find on scoping calls is that teams accept this list and then quietly treat it as the baseline rather than the release. The six items above are the release. Doing a limited number of features really, really well beats doing a lot of things lightly, because a person who has a flat first experience doesn't come back to see whether you've improved. You don't get a second first impression, and no amount of breadth makes up for a core action that feels sluggish or unclear.

Sign-Up Gates: When to Ask and When to Wait

Headspace's opening screen is the cleanest example we point people to. It removes the two things that break trust on a health app straight away. There's no sign-up gate and no diagnostic questionnaire, and there's no "how are you feeling today?" prompt, which presumes an intimacy the person hasn't worked up to yet. It asks for nothing, so there's nothing to resist.

Most first apps can do the same. If someone can experience the core action without an account, let them, and ask for the account at the moment it starts to earn something. Saving a progress, syncing across devices, placing an order. The ask makes sense then because the person has a reason to say yes.

An account request lands well when it protects something the person already has, not when it guards the door.

Sometimes the product genuinely can't work that way. We built an anonymous messaging app where registration had to happen upfront, because identity sat underneath the whole premise. That decision carried a cost we had to pay somewhere else, and we paid it outside the app, which is the next chapter's problem and the one in chapter fifteen.

The test is simple enough. If the gate exists because the product needs it, keep it and plan for the consequences. If it exists because somebody wants the email addresses, move it.

Onboarding and the First Three Days

The first three days decide most of your retention, and the drop in that window is brutal even for strong products. Plenty of people never get that far at all, with around 25 per cent of apps abandoned after a single use, according to Localytics. Onboarding is the only part of the product that gets a crack at that.

We ran a teardown of a meditation app that got the feel right and the sequence wrong. The soft gradients and breathing animations were doing real work, slowing people down before they'd consciously noticed. Then the app asked them to pick a goal. Sleep, stress or focus, chosen before they'd done a single thing in the product. Asking someone to choose a goal in that state of mind adds a decision, and a decision is friction, which raises anxiety rather than giving relief. The app's own promise was calm, and its third screen contradicted it.

Put the decision after the experience. Let someone complete the core action once, then ask them to personalise it. By that point the hesitation has dropped and they're far more receptive to learning how the rest works.

So the better pattern is to teach through use. Show value in the first session, keep the explaining to the moment it's needed, and save preference-setting for day two or three when the person already knows what they're setting preferences for.

Navigation, Search and Finding Things

On that grassroots football project, the client kept telling us the booking process needed to be "more intuitive". We pushed back, explained what we thought was really happening, and in the end did what they asked. We reworked the interactions and the flow. The changes made little to no difference, because the booking process wasn't the problem. The product was carrying too much, and no amount of interaction polish rescues a structure that's trying to hold five jobs at once.

That's the thing to hold onto when navigation feels wrong in testing. Confusing navigation is usually a symptom. Teams reach for tab bars, mega menus and search, when the fix sits one level up in what the app is trying to be.

For a first release, keep to three or four destinations in the main navigation and name them after what people do, not after your internal team structure. A fashion app with Shop, Saved, Orders and Account is clearer than one with Discover, Curated, Edit and Hub.

Search is worth real thought rather than reflex. If your catalogue is small, browsing beats searching and a search bar just advertises that you expect people to get lost. If the catalogue is large, search needs proper investment in synonyms, typo handling and sensible empty states, and half-built search is worse than none.

Notifications, Ratings and Other Interruptions

Three things interrupt people in a first app. Permission prompts, rating prompts and in-app messages. All three get asked for too early, and all three cost more than teams expect when they land badly.

The push notification permission request is the clearest case. Asking on first launch means asking before you've given anyone a reason to say yes, and a no is close to permanent. Wait until there's something worth being told about. A fitness app that asks after someone has set their first session time is asking about a thing the person already cares about.

Rating prompts follow the same logic, with one extra rule. Ask after a success, never after a failure or a wait. Somebody who has just received a delivery confirmation from a food and drink app is in a different emotional state to somebody who has just watched a payment spin for eight seconds.

In-app messages are where restraint pays most. Every banner, tooltip and modal is a small tax on the person's attention, and in a first release you're already asking them to learn something new.

The principle underneath all of this comes back to receptivity. Once the initial anxiety has dropped and someone understands the core of what they're using, they'll take in far more. Interrupt before that and the message bounces off.

Speed, Reliability and the Unglamorous Essentials

Nobody puts load time on a feature list, and it's the feature people feel first. The same goes for what happens when the connection drops, which is the question we get asked most on travel and hotel products.

The way we work through it has two parts. First, find the moments of maximum stress in the journey, because those are the places where a technical failure does real damage. Checking in, finding your way somewhere, pulling up a booking reference, retrieving a ticket. Then apply a dependency test to each feature. Does it need a round trip to the server, or does cached data cover it, and how often does that data actually change?

Passive things like itineraries, saved tickets and maps should be offline-first. Transactional things should fail gracefully or queue.

What matters more than any of that is not buying offline support with quality taken from somewhere else. Offline work is expensive, and spreading the same budget across more features usually produces something lacklustre and lifeless across the board.

So the unglamorous list for a first app is a short one. Fast first load, honest error messages, state that survives a backgrounded app, and graceful behaviour when the network goes. None of it demos well and all of it decides whether people stay.

How to Separate Must-Have from Nice-to-Have

Feature arguments go in circles because everyone's arguing from preference. Giving the argument a shared set of questions moves it along, and it also gives you a record of why something was cut, which matters when the same idea comes back in month four.

Build discipline here pays for itself, because a large share of what gets built never pays back. McKinsey research puts it at 70 per cent of product features failing to deliver the expected business outcome, which lines up with what the concierge app discovery told us. Once residents had talked, most of the planned features stopped looking like must-haves at all.

Write the cut list down with the reason attached, and date it. Features come back, and a one-line note saves you relitigating the same decision three times.

The Features Users Say They Want but Never Use

People are honest in research and bad at predicting their own behaviour. Ask someone whether they'd like a social feed inside a wellness app and most say yes, because the polite answer and the enthusiastic answer are the same answer. Then nobody posts.

The gap shows up in the numbers afterwards, with roughly 60 per cent of app features rarely or never used by Futuristic Bug's reckoning. Every one of those was somebody's good idea.

The apps features that usually go unused

Social and community layers bolted onto a product that isn't social. Deep customisation settings, where people change one thing and never return. Dashboards full of charts that answer questions nobody was asking. Gamification badges with nothing behind them. Chat features that exist because competitors have chat.

The fix is to watch what people do rather than asking what they want. In sessions, give someone a task and see where they go. If a feature only appears when you point at it, that's your answer.

We saw this play out on a well-funded sports club app covering finances, games, schedules and players across a range of sports. The client wanted all of it, and the request list grew from what the team imagined clubs needed rather than from what clubs were observed doing.

When One App Is Really Three Apps

Two of our projects turned out to be several products wearing one icon. On the grassroots football app, the features we were asked to combine already existed across separate apps in the market, and that separation wasn't a failure of imagination on anyone's part. Those products were separate because each one serves a different person in a different moment.

The sports club app had the same shape at a bigger scale. Finance, fixtures, scheduling and player management, across multiple sports, all in release one. We advised launching with a single sport, on a single platform, as an MVP. The client pushed back entirely, through the whole process. They didn't want to launch until everything was ready, and that position set the conditions for scope creep that never stopped growing.

There are a few signals that you've got more than one app on your hands. The user groups have different jobs and barely overlap. The navigation needs more than five top-level destinations to make sense. People describe the product with "and" more than twice. The emotional register changes between sections, with one part needing to feel calm and another needing to feel efficient.

If you can't write one sentence describing what the app does without using "and also", split the scope. Pick the audience with the sharpest need and build for them first.

What Happens When You Skip Discovery on Half the Product

We worked on a dating app built around verified profiles and keeping bots out. The client wanted to skip discovery on the messaging side and put everything into the onboarding process, which was where they felt the product's value lived. We ran discovery on onboarding and built verification properly.

Messaging got built generically, because that's what happens with no discovery behind it. The generic version allowed automated messages and fake messages, which is exactly the behaviour the onboarding had been designed to stop. Even though we'd put so much emphasis on the onboarding and the verification, it didn't stack up with the rest of the product. The whole messaging section had to be rewritten, at roughly £15,000 of extra budget and two months of extra work.

A product can contradict itself when discovery covers one half and not the other.

Coherence lives in the connections between features, so discovery has to cover the interconnected parts rather than only the parts the client finds interesting. Research done at the start also protects against a far more common failure, given that 42 per cent of apps fail having launched without prior market research.

If budget forces a choice, cut scope rather than cutting discovery on part of the scope. A smaller product that holds together beats a larger one arguing with itself.

Budget, Scope and Why All-at-Once Launches Fail

We worked on a football-focused social media app where the client asked for a streamlined MVP and expected a premium finish, on a budget that didn't support both. A lower budget means less flexibility and a focus on getting something launchable into the market quickly. This client wanted the low budget without the limitations that come with it. We had several conversations trying to line up expectations with the money available. We got to a finished product, with compromises on features, because the client chose to spend in areas we'd ranked lower.

What a given budget buys has shifted over the last few years. Design and build rates have risen, app store requirements have grown, and privacy and accessibility work that used to sit at the edges now sits in the core. A number that felt comfortable three years ago buys noticeably less scope today, so the honest conversation at the start is about what comes out, not what goes in.

All-at-once launches fail for a plainer reason. Until real people use the thing, every decision is a guess, and a full product launch is a very expensive way to find out which guesses were wrong. Launching one sport, one platform or one city gives you evidence before the budget has gone.

Warning Signs You Are Building a Vanity Product

Across a fitness and wellness app and the grassroots football product, we watched the same thing happen twice. The founder was certain about what they wanted, usually because it was a problem they'd lived with, and then they set aside the data coming out of the research studies, the focus groups and the surveys. The product stopped being shaped by evidence and started being shaped by preference.

We flagged it early on both. Both projects spent their whole budget in design and build and never reached a full live version.

The early signals are consistent enough to list.

• A drive to perfect the product before anyone outside the team has used it.
• Sign-offs being rolled back so another round of changes can go in.
• Decisions taking weeks, with each one reopening an earlier one.
• Research findings being explained away rather than acted on.
• Competitor features being added because they exist, without a reason tied to your own audience.

Set a launch date before you set the feature list, and treat the date as the fixed thing. Scope flexes, dates shouldn't, because an unlaunched product teaches you nothing.

What Your App Store Listing Has to Carry

On the anonymous messaging app, the upfront registration meant we couldn't drip-feed value once somebody was inside the product. So everything we'd normally explain through use had to be said before the download. We needed to be much clearer upfront, which meant the listing, the screenshots and the description carried the whole story, and we did a lot of work outside the app to make that hold.

That's the position every app is in, really, with a sign-up gate making it sharper. The listing is the first screen of your product, and people decide there.

The order of the first few screenshots matters more than the copy.

1. The core job, shown being completed, with a caption of five or six words.
2. The thing that makes you different from the obvious alternative.
3. Proof that it works, through a real result or real content.
4. The commitment being asked for, stated plainly rather than buried.

Write the listing early, before the build. If the core app features are hard to describe in four screenshots and a short paragraph, the product is carrying too much, and you've found that out while it's still cheap to fix.

Conclusion

The pattern across all of these projects is the same one. Products get into trouble by adding, and they get out of trouble by subtracting. The concierge app got better and cheaper once discovery told us which features to drop. The grassroots football app got worse as it absorbed more jobs, and the interaction fixes we were asked to make couldn't rescue it. The dating app lost £15,000 and two months because one part of the product was built without the thinking that went into the rest.

So the answer to what features for a first app should include is narrower than most roadmaps. One core action that works properly. A way in that asks for as little as possible. Navigation anyone can read. Honest feedback, decent speed, and a route to a person when it breaks. Everything beyond that has to argue for itself against the one job you've written down.

Build that, put it in front of real people, and let what they do decide the next release. It's slower to start and far faster to somewhere good.

If you're scoping a first app and want a second opinion on what stays in, let's talk about your feature list.

Frequently Asked Questions