How Do I Define the Requirements for My Mobile App?

A client came to us with a dating app built on one promise, that every profile was a real, verified person. They asked us to skip discovery on the messaging side and put everything into onboarding instead. So we built onboarding properly, and we built messaging the way messaging usually gets built. The generic version allowed automated messages and fake messages, which is precisely the behaviour the verification work existed to stop. Rewriting that section cost about £15,000 of extra budget and roughly two months of extra work. Nobody had written down the requirement that mattered, which is what happens when you define app requirements for one part of a product and guess at the rest.

A missing requirement doesn't announce itself until someone has already built around it.

Requirements are the part of app development people assume they already have. There's a document, there's a feature list, there's a founder who can describe the thing in detail. And then the build starts and the gaps show up as money. This piece is about how we get from a rough idea to a set of app requirements a team can actually build from, what we look for, where it goes wrong, and what we do differently now because of projects like that one.

What a Requirement Actually Is (and What It Isn't)

A requirement is a plain statement of something the product has to do for a person, in a situation, with a way of telling whether it's been done. "A member can pay their subscription from their phone without ringing the club" is a requirement. "Payment integration" is a solution somebody has already picked, written down before anyone agreed on the problem it solves.

The difference matters because solutions get locked in early and then defended. Once "payment integration" is on the list, the conversation is about which provider, and the question of whether people even want to pay in the app never gets asked.

Three parts that have to be there

• Who it's for, described as a real person in a real moment
• What they're trying to get done, in their words
• How we'll know it worked, in a way two people can agree on

That third part is the one teams leave off, and it's the one that decides whether a project ever finishes. Geneca found that up to 77% of software project respondents don't know how to tell when their project is 'done', which is self-reported, though it matches what we see when a scope conversation goes round for the fourth time. If nobody wrote down what finished looks like, finished becomes a feeling, and feelings move.

Start With the Problem, Not the Feature List

A property developer came to us wanting a concierge app for their high-rise buildings. They arrived with a budget already set and a clear picture of the product in their head, and what they wanted from us was a validation of that picture rather than a proper scoping exercise. We talked them into running a real discovery phase first, with focus groups and user workshops.

What we found was that the product needed to be a lot simpler than they'd imagined. A good number of the features on their list didn't go in. The building already had systems that worked, and residents had no appetite for a phone app that duplicated them. So the focus moved to creating a human connection with the product, the bits a resident actually feels, and the rest fell away. Better product, lower cost, and the saving came out of the feature list rather than the quality.

That only happened because we started with the problem. A feature list is a record of everyone's assumptions, sorted by who spoke loudest in the meeting. The problem is the thing you can test. We'd rather spend three weeks finding out that half the list is unnecessary than spend four months building it and finding out from the analytics.

Why Discovery Beats Validation

Validation asks whether the plan is good. Discovery asks what the plan should be. The two sound similar in a kick-off meeting and they produce very different products, because validation can only confirm or soften what's already on the page, and it has no way of surfacing the thing nobody thought to ask about.

The dating app is the clearest version of this we've been through. All the discovery effort went into onboarding and verification, and it worked. The gap was that messaging got none of it, so the two halves of the product disagreed with each other. One half was built to prove you were real and the other half let a bot talk to you.

Discovery you skip in one part of a product shows up as a contradiction in another, usually after the build.

Product coherence needs discovery across the connected parts, not just the parts the client is most excited about. Devtimate puts it at projects skipping the discovery phase being three to five times more likely to fail or run over budget, with no methodology given, so treat the number loosely. The £15,000 rewrite is the version of it we can account for line by line.

Turning Research Into Written Requirements

Research only becomes app development requirements when somebody writes it down with its source attached. When a stakeholder tells us part of a product feels confusing, the first thing we want to know is where that idea is coming from, because the handling changes completely depending on the answer.

How we define app requirements in writing

1. Name the source, whether that's a feeling in the room, analytics, or user research
2. Check analytics for whether the numbers are being read correctly, since a drop-off can mean three different things
3. Interrogate insider opinion for bias, because people who know the product deeply find flows obvious that new users don't
4. Look at support requests for a repeating theme, then trace the theme back to the screen causing it
5. Write the requirement as a sentence about the user, with the evidence sitting underneath it

That second-to-last step is cheap and most teams ignore it. Support tickets are user research that somebody has already paid for. If the same question arrives twelve times a week, there's a point of confusion in the product and you can usually find it in an afternoon.

Write the evidence next to each requirement. Six months in, when someone asks why a screen works the way it does, you'll have an answer that isn't "because we decided that in March".

The Requirements You Can't See: Context, Connectivity and Constraint

We worked on a travel app used by people on exotic holidays and backpacking trips, and the product expanded into a new type of trip that took users into remote wilderness. The app needed a connection for everything that mattered, map search, saved pins, tickets, itineraries, location times. Out there, opening it got you a "you're not connected" message and nothing else. An absolute disaster, in a place where the app was the only thing you'd brought. Offline capability had to be retrofitted, which costs several times what building it in at the start costs.

Context is the requirement nobody writes down because the room is warm and the wifi works. We also worked on BMW's accident reporting flow, where the user is standing at the roadside having just crashed their car. The first thing the app does is check whether they need emergency services and whether they're somewhere safe. Then it shows an exploded diagram of the car, the kind you see on a rental agreement, and the user taps the areas where photographs are needed. Instead of a typed claim form, they record a voice note, which gets transcribed later when they're calm.

That whole design came from one question about context, which was what the person can realistically do at the scene and what can wait until they're home.

Non-Functional Requirements: Speed, Security, Offline and Scale

Non-functional requirements decide whether anyone stays long enough to meet your features. We split early abandonment into three windows when we audit a product. The first three or four seconds is immediate abandonment, caused by slow loading, sluggish interactions, crashes, freezing, or an app that eats memory. The next minute or two is about onboarding, forced registration, too many tutorial screens, permissions requested with no explanation. After that comes the first three days, where there's nothing pulling anyone back.

None of those get fixed by a feature. They get fixed by writing the requirement in a form you can test.

Test on the oldest phone your users still carry and the worst signal they'll have. Your product behaves very differently there, and that's the version they'll judge.

Requirements That Contradict Each Other

Most difficult projects we've worked on had two requirements pulling against each other that nobody had put side by side. The dating app had verification on one side and open messaging on the other. On paper both were sensible. Together they cancelled out.

We worked on a football-focused social media app where the contradiction was money. The client wanted a streamlined first release, which is a reasonable thing to want, and they had a budget to match it. What they also wanted was a premium experience, the kind that needs time in interaction design, motion, content and polish. A lower budget brings less flexibility and a focus on getting something launchable to market quickly. They wanted the low budget without the limitations that come with it.

Two reasonable requirements can be impossible together, and nobody notices until one of them is built.

We had that conversation with them several times, trying to line up the expectation with the financial reality. The product did get finished, with compromises on features, partly because they put budget into areas we'd have ranked lower. Reading your requirements as a set rather than a list is how you catch this. Put them on one page and look for the pairs that can't both be true.

Prioritising: What Ships First and What Waits

Prioritisation is where app requirements stop being a wish list. The Standish Group's 2015 CHAOS Report found 45% of features in software projects are never used, and that number is worth sitting against your own backlog for a minute. Nearly half the work, built, tested, shipped and ignored.

The order we work in is simple:

1. The one job the product exists to do, described in a sentence
2. The things that job collapses without, like payment, or trust, or being findable
3. The things that make the job feel good rather than merely possible
4. The things on the list because a competitor has them

That fourth group almost always waits, and often disappears. On the concierge app, a large chunk of the original feature list sat in that fourth group without anyone realising, because it had been written by looking at what other buildings offered rather than by asking residents what they wanted from their own front door.

The useful question for anything in the middle is whether the feature helps the user or works against what they said they wanted. Push notifications are the obvious test case. Every one of them has to be timely and relevant to that person, or it's a feature built for the business and charged to the user's patience.

Matching Requirements to Budget and Release Strategy

Simon worked on a well-funded sports club app built to handle finances, games, schedules and players across a range of sports. Our advice from the start was to launch with one sport, on one platform, as an MVP, and grow from there. The client pushed back on all of it, the whole way through. They didn't want to launch with a single sport. They didn't want a single platform first. They didn't want an MVP. They wanted everything, live on day one.

That position is the thing that sets up scope creep, because with no release date that's real, every new idea has somewhere to go. McKinsey and the University of Oxford found IT projects without MVPs run an average of 45% over budget and deliver 56% less value than expected, with the MVP framing coming from how the finding gets reported rather than the paper's own wording. The direction of it is familiar enough.

A budget isn't a number you spend on a fixed list. It's a decision about how many chances you get to be wrong. Phased releases buy you more of those chances, because what you learn from the first group of real users reshapes what you build for the second.

When the Founder's Vision Overrides the Evidence

On two projects, a fitness and wellness app and a grassroots football product, the founders were completely certain about what they wanted. That usually comes from a good place, because it's a problem they have personally and they've lived with it for years. What happened on both was that the data coming out of the research, the focus groups and the surveys got set aside whenever it disagreed with the picture in their head.

What you end up with is a vanity product, shaped by one person's preferences rather than by evidence. The warning signs showed up early in both cases:

• A drive to perfect the product before anyone outside has seen it
• Sign-offs being rolled back so another round of changes can go in
• Decisions taking weeks that should take days
• Research findings described as interesting, then not acted on

We flagged the trajectory on both projects. Both spent their entire budget on design and build and never reached a full live version. That's the real cost of overriding the evidence, which isn't a worse product, it's no product.

If research keeps telling you something you don't want to hear, that's the finding. Being the user is useful. Being the only user is the risk.

How to Document Requirements So a Team Can Build From Them

Documentation fails when it's written for the person who already understands the product. One study on arXiv traced 78% of requirements-related rework to avoidable gaps in shared understanding between stakeholders and development teams, and it's worth chasing the original before leaning on the figure. The shape of it holds up against how rework actually arrives, which is as two people discovering in week nine that they'd pictured different things in week one.

What a usable requirement looks like

Each one gets a short sentence about a person doing something, the evidence behind it, the conditions it has to work under, and the thing that tells you it's done. The conditions line is the one that saves money. "Works offline" sitting under the itinerary requirement on that travel app, written at the start, costs a fraction of retrofitting it after the product has moved into wilderness trips.

Group requirements by user journey rather than by screen or by team. Screens change. A person's reason for opening the app doesn't. Grouping by journey also makes contradictions visible, since verification and messaging sit in the same journey even though they'd land with different developers in different sprints.

And keep it short. A document nobody reads is a document that doesn't exist.

Changing Requirements Without Losing Control of Scope

Requirements change, and they should. Users do something you didn't predict, a competitor shifts, a technical constraint turns out to be softer than you thought. The problem isn't change. It's change that arrives without a decision attached.

On the sports club app, every addition seemed small on its own and reasonable in the room. With no launch date that anyone treated as real, there was nothing for a new idea to be weighed against. That's the mechanism. Scope creep needs an absence to grow into, and the absence is usually a fixed release.

So we handle changes as trades. A new requirement comes in and the question is what it displaces, which thing it's more important than, and what it does to the date. Written down, with the answer. That turns a hallway conversation into a decision somebody owns.

The other half of it is working with the process rather than against it. On the sports club project, the advice was there from the first week and it was ignored for a year. Listening to the team building the thing, and accepting the methodology they're recommending, matters more to whether a product launches than almost any single feature decision you'll make.

Conclusion

Defining app requirements well is mostly about resisting the urge to start with answers. The concierge app got better and cheaper because we ran discovery instead of validation and found out that half the feature list wasn't wanted. The dating app cost an extra £15,000 and two months because one connected part of the product didn't get the same attention as the rest. The travel app had to be rebuilt for offline use because nobody had written down where people would be standing when they opened it.

None of those are exotic failures. They're ordinary gaps between what somebody assumed and what somebody wrote. The work is slow and unglamorous, which is asking who the user is, what they're trying to do, what conditions they're doing it in, and how you'll know it worked. Then writing all of that down in language a developer and a founder read the same way.

Get that right and the build stops being a series of surprises. If you're sizing up a product and want a second opinion on what you've got so far, let's talk about your app requirements.

Frequently Asked Questions